Skip to content
This repository has been archived by the owner on Jan 24, 2024. It is now read-only.

React Spike: Rewrite the MDN page header #967

Closed
3 tasks done
davidflanagan opened this issue Feb 6, 2019 · 85 comments
Closed
3 tasks done

React Spike: Rewrite the MDN page header #967

davidflanagan opened this issue Feb 6, 2019 · 85 comments
Assignees

Comments

@davidflanagan
Copy link

davidflanagan commented Feb 6, 2019

User story

As an MDN developer, I want to rewrite the MDN page header using React, so I can gain experience using React for a non-trivial page component, and so that I can reduce our the dependencies on jquery.

(Also, as an MDN user, I don't want the menus at the top of ever MDN page to appear every time I move my mouse pointer near them.)

See https://bugzilla.mozilla.org/show_bug.cgi?id=1525719

This issue is intended to be tacked after issue #965 and issue #966.

The goals of this work are:

  • to do a non-trivial chunk of React coding, to help ensure that the toolchain we're using is suitable

  • to prototype a positive UX improvement for the site (fixing the menus so they require a click to display)

  • (stretch goal) to see whether we can remove the jquery dependency from the main.js file that is loaded into every page - this would also mean replacing the footer and other parts of the wiki page with React-based alternatives.

Acceptance criteria

@davidflanagan davidflanagan added this to the Fantasia (S2 Q1 2019) milestone Feb 6, 2019
@davidflanagan davidflanagan self-assigned this Feb 6, 2019
@ExE-Boss
Copy link

ExE-Boss commented Feb 9, 2019

Why does everything seem to need to be written using React these days?

It honestly feels like trying to fit a square peg into a round hole to me at this point.


In other words, I don’t feel like adding React to MDN would be much help, and might instead make things harder to maintain.

@davidflanagan
Copy link
Author

@ExE-Boss: some of our reasoning for using React is captured in this ADR: https://github.com/mdn/mdn/blob/master/ADRs/001-use-react.md

In my experience, React makes front-end development easier. We anticipate having to do a lot of it in 2019, so trying to move to React now will increase our development velocity for the rest of the year, we hope.

@ExE-Boss
Copy link

ExE-Boss commented Feb 11, 2019

I would also like to point toward hyperHTML, which I didn’t see mentioned on the page.


See also mozilla/dispensary#465

@WebReflection
Copy link

FWIW, W3C Respec has been using hyperHTML for more than a year:
https://github.com/w3c/respec/blob/develop/package.json#L92

And ABP ships with HyperHTMLElement and hyperHTML to roughly 100M users, targeting FF, Chrome, Opera, and Edge 👋

@marcoscaceres
Copy link

Just my 2c, as someone involved with browsers and standards for the last ~13 years. Libraries come and go, and generally all libraries/frameworks have a lifespan of about 5 years (there was some data published by GitHub about this, I believe, that made a pretty compelling case). In evaluating a solution, be sure to consider the library dying out or becoming a maintenance burden after 5 years (e.g., everyone trying to get off jQuery onto Web Components).

In the case of ReSpec, we chose HyperHTML because it's "so close to the metal", super thin and - it's extremely standards conforming and a library that can be used without build tools, and could easily be used for another 10 years with no problem.

Before choosing React, or any library, please consider if the MDN project will be around in 10-20 years (I believe it will be) - so these technology choices REALLY matter. Please choose wisely.

@voxpelli
Copy link

If you feel the need to do something with the header in JS, then I would opt for a WebComponent based approach and, if using React, wrap the React in https://github.com/rstacruz/remount to make it a WebComponent.

That way the rest of the site don't have to care whether it's React, LitElement, vanilla WebComponent or whatever and you can independently update and/or replace component implementations independently from one another without any of them having any other public API than the webcomponent they are exposed as.

We're taking this approach at our sites as we recognize that some highly dynamic parts would benefit from something like React, but we don't want to require React on page loads with no such highly dynamic parts and don't want to couple all of our code to a single library.

Combining such a structure with something like Webpack and code splitting enables standard webcomponent based interfaces, sharing of libraries between webcomponents as well as loading of heavy libraries only whenever a webcomponent requiring that library is used.

@oswee
Copy link

oswee commented Feb 13, 2019

WHYYY!? Why React!? Why not web standards!? Why not Web Components? It's a shame.

@thepassle
Copy link

Web Components/Polymer
Web components will eventually be the standard component system for the web, and in that sense they seem like the best choice for Mozilla. But they are not yet well supported by browsers other than Chrome, and so we would have to adopt the Polymer framework.

This is simply untrue and somewhat disappointing reasoning; web components are supported by all major browsers*. The Polymer Library has been put in maintenance mode, but there's a wealth of web component libraries out there now, LitElement, Ionic, etc.

If we didn't have such ambitous goals for 2019 and weren't expecting to work with contractors on those goals, I would want to seriously consider using Web Components because they seem like the best solution for the open web. But the lack of tools, ecosystem, and developer community makes this a non-starter for now.

I agree that the web component ecosystem isn't as large as React's, however we've been doing a bunch of work to improve this situation and make things easier for developers on any scale: www.open-wc.org

I feel like it's a little disappointing, especially from MDN, to not go with web standards. I do hope you reconsider.

  • Edge when they switch to chromium

@web-padawan
Copy link

Looking at the MDN header, there is a perfect use case for <mdn-submenu> Web Component.
It currently does not work with "disable javascript" feature, so there won't be any regression.

You could avoid using Shadow DOM for such a small thing, and only use Custom Elements part of the standard, same as GitHub does (which would make a lot of sense for this particular case).

@oslego
Copy link

oslego commented Feb 13, 2019

As representatives of Mozilla, standing for and promoting the use of open web standards, we should be more diligent about our choice of technology. It comes under increased scrutiny and it sets an example to the people we intend to educate on the importance of open web standards.

It's not that React is bad. We use it elsewhere on other properties as mentioned here. But for MDN itself, choosing to overlook Web Components, which as commenters above point out has widespread support, impacts our message.

This React rewrite looks like an experiment for now. Which is good. Learning is good. But I echo @marcoscaceres' thoughts and sincerely hope you'll consider carefully the implications not just the how when approaching the MDN rewrite.

Regardless of the technology used now, it will be eventually rewritten in the future. Frameworks come and go. Being closer to the web platform matters more in the long term.

@bennypowers
Copy link

I'm a huge fan of MDN, and vigorously support your work.

In addition to all the above:

Inherent Benefits of WC Over React
All the reasons that the Firefox browser-chrome team is reimplementing UI in web components apply here. Why limit yourself to the performance of react.js?

Pedagogy
When users read MDN, and they open the inspector, let them see idiomatic web code, not what JSX and VDOM diffs compile to.

Developer Experience
All the cited DX benefits of using React are available in web components-based libraries, and there are many to choose from, whether you go with Google's lit-element or with community libraries like hybrids or hyperHTML.

So we all agree that components that render DOM as a pure function of state are a great way to develop. So, the best resource on the web platform should do that with the web platform.

React Approach Hostile to Web Standards, Thus Inappropriate for Mozilla
React fails more https://custom-elements-everywhere.com/ tests than any other framework. React's ethos is very much against the use of Web Components and the platform in general, at the moment.

React's approach very much aligns with the view that the web platform is a problem to be worked around and abstracted over. In the "react way", the browser is merely a compile target - one of many among native apps, etc. I don't think Mozilla should be encouraging that view by encouraging the use of React.

Lastly, it strikes me (personally) a little funny for Mozilla to investing so heavily in Facebook's tech stack.

React is a fine library, but using it on MDN just strikes me as odd.

@justinfagnani
Copy link

justinfagnani commented Feb 13, 2019

@davidflanagan I think it's perfectly fine to choose React for a project, so I don't want this comment to seem only anti-React or only pro-Web Components, but I noticed in the ADR some incorrect information around Web Components, and it would be a shame if a decision was based on false background.

Specifically:

Web Components/Polymer

Web components will eventually be the standard component system for the web, and in that sense they seem like the best choice for Mozilla. But they are not yet well supported by browsers other than Chrome, and so we would have to adopt the Polymer framework.

Unfortunately, this whole paragraph is basically untrue. It seems like it was written based on information from 2 years ago.

Web Components (<template>, Custom Elements, and Shadow DOM) are supported in Chrome (and all Chromium browsers like Opera, Android, and Samsung), Safari, and Firefox. Safari has had support for almost 2 years, and Firefox since 63. Firefox is porting it's actual UI from XUL to Web Components as we speak.

Also, Polymer is far from the only option for writing web components. Stencil (from Ionic) and SkateJS (which can use Preact, React, or lit-html to author components) are two popular libraries. Angular, Vue, and Svelte are working on Web Component output. The Polymer Project itself just released LitElement, which is a very React-style approach to writing web components, but without any proprietary JS syntax extensions or required build steps. I encourage you to check it out if you like the React experience and are even the slightest bit interested in Web Components in the future.

If we didn't have such ambitous goals for 2019 and weren't expecting to work with contractors on those goals, I would want to seriously consider using Web Components because they seem like the best solution for the open web. But the lack of tools, ecosystem, and developer community makes this a non-starter for now.

What tool support are you looking for? Projects like LitElement have great tool support because they're just JavaScript libraries. There's no special syntax or build requirements, so they work with all the existing tools like Webpack, Rollup, Parcel, Babel, ESLint, TypeScript, Workbox, etc...

Older versions of Polymer used HTML Imports instead of JavaScript modules, and therefore had to have custom tools or plugins. This hasn't been the case since Polymer 3.0 though, and Polymer is also now compatible with all the standard ecosystem tools.

I really hope that the ADR can be corrected to reflect the actual state of Web Components, and that the decision here, even if it's to move forward with React, can be based on accurate information. I'm glad to help in any way that I can.

@bennypowers
Copy link

I'm glad to help in any way that I can.

Ditto. I'm ready and willing to help implement with lit-element or another modern web component library.

@ExE-Boss
Copy link

ExE-Boss commented Feb 13, 2019

I would personally prefer to use hyperHTML or lighterHTML since they have a few extra features that lit‑html lacks, which my code depends on.

Also:

@pinguxx
Copy link

pinguxx commented Feb 13, 2019

I can help with code using hyperHTML i think is the best route

@WebReflection
Copy link

WebReflection commented Feb 13, 2019

Since we're proposing standards based alternatives, and since the React choice looks to me somehow rather motivated by boredom of using just standards, here my counter list:

  • wickedElements, repo and post, are 100% standard based, resembling the Custom Elements API, working down to IE9 and all other Desktop/Mobile browsers, all through an innovative paradigm and all in 2KB library that requires zero polyfills
  • Neverland, repo and post, is like developing with React and hooks without needing any compiler step
  • lighterhtml, repo and post, is a simplified hyperHTML like primitive that can be used with any kind of custom hooks, including haunted, which is already compatible with both lit-html and hyperHTML, augmentor to create your own custom hooks, or TNG-Hooks from, IIRC, your former colleague Kyle Simpson
  • HyperHTMLElement which ships with ABP in production, and it's consumed by million users daily, and it's been stable for a long time (same as hyperHTML, they both came out prod ready more than a year ago)

All these variations based on Web standards, and delivering just those, are the attempt of a long standing Web standards promoter as I am, so that surrounding hype can easily lower when you see you can achieve great results simply respecting, and using as much as possible, the Open Web Platform, the one Mozilla should have as part of its mission.

Please do not ever ditch the platform on a site that promotes it.

Thank you.

P.S. obviously happy to help as I can if it's needed 👋

@ExE-Boss
Copy link

ExE-Boss commented Feb 13, 2019

lighterHTML is to hyperHTML what Deno is to Node.

Also, there’s a PR for adding React as a dependency to Kuma now: mdn/kuma#5250 😞 (please don’t spam comments on that PR, as that would be unprofessional)

@cferdinandi
Copy link

React makes front-end development easier.

Ease of experience for developers should not trump the experience of end-users. The added code-weight, complexity, and chance for things to fail are strong reasons to serve up as much in good old HTML as possible. Maybe a SSG augmented with some light JS?

@cferdinandi
Copy link

I should add, I'm all for ripping out jQuery from things. But these days, some progressive enhancement, native JavaScript, and polyfills (automated, even, from polyfill.io) do a lot.

@gaearon
Copy link

gaearon commented Feb 13, 2019

I won’t comment on the rest of this thread. But the notion that React is somehow antithetical to standards is very misinformed.

We’re thrilled to collaborate with vendors on specifications that advance the future of the web. That includes ongoing work on user interface responsiveness, display locking, main thread scheduling, and other initiatives like virtual scrolling APIs. Some of these collaborations are currently driven by Chrome but we’ve worked with Mozilla, Apple, and Microsoft too on the topics where they were interested in our input. Having worked on React, we’ve accumulated some experience that we are excited to share with the broader web community.

There are valid criticisms like subpar support for custom elements, but again, it is not due to a lack of care. Rather, there are many unsolved questions that even the community actively using web components today can’t reach agreement on. (Related to heuristics for properties/attributes and server rendering.) We take API changes in React seriously so we want to ensure that if we change the behavior, we won’t have to change it again in a few years. I hope that you can empathize with such approach. You’re welcome to contribute to the discussion about specific issues on the React issue tracker.

We care about moving the web forward, and not just React alone. We don’t always agree about which specific standards or techniques will help folks create better user experiences for the web. That is a source of much tension in some communities. But don’t mistake disagreements with a lack of enthusiasm. React is firmly built on the web platform and standards, and will continue to be.

@justinfagnani
Copy link

Rather, there are many unsolved questions that even the web components community can’t reach agreement on. (Related to heuristics for properties/attributes and server rendering.)

That's one way to put it. Another way is that we can't get agreement on heuristics because heuristics are bad and it would be great if users could just specify whether they're setting an attribute, property or event handler in JSX. Framing this as the web components communities failure to agree is misleading, IMO.

@benfurfie
Copy link

benfurfie commented Feb 13, 2019

@gaearon I don't think any of the above is criticising React or is necessarily misinformed. It's simply pointing out that it isn't required in this instance. It's like using a steel-mill hammer to knock a thumb-tack into putty. Sure, it'll work – and it might be the most poweful hammer in the world – but it's overkill.

Tools like React (and your own tool, Redux) are great, but there is a creeping tide of people using tools like it in places that it simply isn't required, or appropriate. A big part of this is down to people working on projects it isn't required on feeling like they're being left behind, rather than recognising they are working on projects that don't need it, as well as people working with the tool irresponsibly praising it without noting where it is appropriate to use it.

Sites like MDN are a standard bearer for technologies that are used on content-focused websites like itself. If we start adding React for reasons related exclusively to the development experience, then we risk sending the message people should be using React – or other similar tools that are intended to solve problems complex web apps suffer from – for other content-focused websites.

@davidflanagan
Copy link
Author

Thanks for the constructive comments everyone. I'm glad to hear that web components are more viable today than I realized. I'd love to have the opportunity to work with web components. But that is not an option for MDN.

The MDN engineering team is very small, but we have ambitious goals for 2019. (These goals are not yet ready to share here, so you'll just have to trust me on this.) We're expect to be doing a lot of front-end work this year, and also expect that we're going to have to hire contractors to help with this. There are likely to be an order of magnitude more webdevs with top-notch React skills than we would be able to find for web-components based solution.

It is not like we've just made the decision to switch to Flash! Nor are we announcing that we're going to start using closed-source solutions for our front-end work. Instead, we're picking a technology that we believe will allow us to most quickly deliver features to our users. And that has to outweigh concerns about the purity of the solution.

The particular user story that this thread is one of the things I'm working on this month. A kind of proof of concept, to see if I can determine the performance impact of replacing the jquery library with react, and to figure out whether we're going to have to jump straight to server-side rendering before we ship anything React-based. If it turns out to be an utter failure, then we'll reassess.

The point here is to improve our user's experience with MDN. We're not going to let MDN turn into a big bloated thing. Your trust would be appreciated.

@ExE-Boss
Copy link

Sites like MDN are a standard bearer for technologies that are used on content-focused websites like itself. If we start adding React for reasons related exclusively to the development experience, then we risk sending the message people should be using React – or other similar tools that are intended to solve problems complex web apps suffer from – for other content-focused websites.

I agree with this, and I also want to add that MDN is a website specifically for web developers, and by being made using standards, it's currently very easy to just right‑click and select “Inspect element” and have it just work without needing to install a 3rd party DevTools extension for the browser to be able to understand React’s VDOM.

@cferdinandi
Copy link

Hi @davidflanagan - thanks for the thoughtful response!

We're not going to let MDN turn into a big bloated thing. Your trust would be appreciated.

Apologies if this felt like a criticism of you personally. Rather, it's a comment on React as a platform itself. I trust you to do the right thing, but React is a big beast with a mountain of front-end baggage attached.

As a side note, starting this thread with "so I can gain experience using React" probably gave people the impression the motivation here was for learning purposes rather than for any meaningful gain to MDN as a platform.

Thanks for adding more details.

@WebReflection
Copy link

WebReflection commented Feb 13, 2019

@gaearon for a second, imagine this wasn't about React, and the TL;DR version of this story is:

We're refactoring a working "vanilla" jQuery to bring in a framework that needs mandatory transpilation step due to non standard syntax (JSX, not Babel which aim is to fix standard gaps), a framework that easily ditches semantics and simplifies inline style per element, on the #1 stop to learn about Web Standards.

How would that feel to you?

@kenchris
Copy link

How does this affect the accessibility story?

@jesstelford
Copy link

I'm really happy to see the MDN team making decisions and documenting their process in public ♥️

It's really disappointing to see the pile-on in this thread about their decisions 💔

I wish success to the MDN team, and look forward to seeing what 2019 brings (it sounds exciting 🤩).

⚛️

@jamiebuilds
Copy link

jamiebuilds commented Feb 15, 2019

MANY OF THE PEOPLE IN THIS THREAD SHOULD BE ASHAMED OF THEMSELVES

The MDN team has built the single greatest resource on the web for web developers. Thousands if not tens of thousands of hours of work have gone into building it. And this is somehow not enough for you? Screw you.

The MDN team can do whatever [redacted] they want and we should all [redacted] while they do it. We should offer every ounce of support our sorry asses can possibly muster for any effort by the MDN team to make their lives easier. And we should leave it to them to decide what they think will make their lives easier.

That is all, [redacted] if you disagree.

@WebReflection
Copy link

WebReflection commented Feb 15, 2019

before this thread gets deleted thanks to people incapable of respecting any netiquette, I'd like to say this last thought on this matter.

Imagine Brendan Eich using TypeScript so that nobody would keep betting on JS.

The message that the No. 1 resource for Web development is ditching the same Web technologies it advocates, would be as disastrous as that, implicitly claiming a defeat for the Web, hence a seppuku in the long term for the platform nobody would care much anymore.

When MDN used jQuery to create anything, the Web was in an objectively poorer state.
Choosing in 2019 frameworks after all the innovation and effort put in browsers alignment with standards, doesn't sound rewarding for all the people that contributed with the MDN content that explains all these new amazing opportunities to develop through Open Standards.

I don't even care if MDN would use any of the libraries out there, quite the opposite, I actually would love to see it embracing raw Custom Elements like never done before, so please think about the heavy repercussion this decision would have.

This is not about React per se being a bad tool, this is about every Web Standards advocate that would indeed feel ashamed at pointing at a resource that didn't use its own product.

If using frameworks is instead seen as mandatory due big plans, then please stick on this header: "whatever you'll learn here won't be useful on the real world unless you are a React core developer" so that people can change site and learn something more useful instead for their own career sake.

Thanks for considering improving the message.

@jamiekyle-eb
Copy link

jamiekyle-eb commented Feb 15, 2019

Imagine Brendan Eich using TypeScript so that nobody would keep betting on JS.

Literally search "brendaneich typescript" and you can see him advocating TypeScript again and again. He also helped spec WebAssembly and modified "always bet on JavaScript" to "always bet on JavaScript/WASM"

This whole argument is just is entirely inauthentic.

@WebReflection
Copy link

WebReflection commented Feb 15, 2019

@jamiekyle-eb

Literally search "brendaneich typescript" and you can see him advocating TypeScript again and again.

Here, meet the mighty Brave browser and see they use JavaScript.

He also helped spec WebAssembly and modified "always bet on JavaScript" to "always bet on JavaScript/WASM"

I have helped with other specs for JS, not sure I understand your point there ... WASM is also not code for developers to learn or write, so again, what is this reply about?

This whole argument is just incomprehensibly stupid

Your attitude full of insults and bullying is, instead, super smart and mature.

Andrea just has been salty about React for years because ...

I've worked at Facebook with the team that published React later on. I know React before you could know it existed. If you'll ever be interested in knowing why, at its debut, I hated React, I'd be happy to explain it to you, but differently from the React tribe, I've never made it personal, and I'd never shame anyone or anything in public.

... because he'd prefer people use his stupid libraries.

And again, premium for the genius of the day goes to you, right?

My libraries are so stupid that unlocked Custom Elements for Google AMP, StencilJS, AFramework, among others, and unveiled the hidden power of keyed DOM through template literals.

Every single library I've written was to promote the usage of the platform for every skeptical thinking the platform wasn't fun, wasn't capable, or wasn't ready.

Glad other projects followed up, see lit-html, as example, and glad not everyone is as immature and irrespecutful like the last two developers from the React community.

Best Regards. I wish there would be also some moderator in here.


P.S. just to clarify how much I hate React as the React community imply, this is from my Neverland debut post (previously linked, no need to spam).

screen shot 2019-02-15 at 10 42 45

@montogeek
Copy link

@WebReflection Please don't say this:

The attitude of the React community full of insults and bullying is, instead, super mature.

That person always have a bad attitude at everything and it is not a representation of the React community.

@WebReflection
Copy link

@montogeek I have pointed at a whole twitter thread started from a Facebook employee full of even worse attitude and bullying than the one you found in here.
Their representatives should lead the way not only from a technical point, but from an ethical one.
If there were a moderator, those two message would be either edited or removed.
I'll correct that sentence regardless, but the feeling remains.

@blikblum
Copy link

In context of backend html rendering using Python I could propose this possible solution for this:

Really? All of this to output basically a content site?

Even if considering only client side, React without its ecosystem is not very useful. So i would not be surprised if MDN will depending on redux, react-router, a third party datetime/search component etc

David has 18 months experience with it; Schalk was already learning it.

The learning curve to using web components is pretty flat, since is just standard JS class with a few callback hooks, everything else can/should be accomplished with native web platform, so i don't see React proficiency as a strong argument

All in all just like to highlight a recent article on Mozilla Hacks, by @potch, calling developers to unleash the power of web components:

Custom Elements have already been used to make it easier to build VR content on the web, spawned multiple UI toolkits, and much more. Despite the long standardization process, the emerging promise of Web Components puts more power in the hand of creators. Now that the technology is available in browsers, the future of Web Components is in your hands. What will you build?

If web components are not suitable to a primarily content site, with a few dynamic interactions it should be for my complex app?

If web components are so hard to be proficient in (more than a non standard, own world library) should i really invest in it?

So, Mozilla does not believe in what they write?

In my opinion, none of the above statements about web components are true but sadly this is the message Mozilla is passing to web developers with this decision

@jgmac1106
Copy link

jgmac1106 commented Feb 15, 2019 via email

@ExE-Boss
Copy link

@WebReflection

I've worked at Facebook with the team that published React later on. I know React before you could know it existed. If you'll ever be interested in knowing why, at its debut, I hated React, I'd be happy to explain it to you, but differently from the React tribe, I've never made it personal, and I'd never shame anyone or anything in public.

I’m interested in hearing about it, but you probably should make it a post on your blog, rather than a comment here.

@jamiebuilds
Copy link

Someone want to help me find Brendan Eich on this list? https://github.com/brave/brave-browser/graphs/contributors

Also apparently Brendan Eich thinks we should all use C++ because apparently the code other people write is more indicative than his own words https://github.com/brave/brave-core

@jmswisher
Copy link
Contributor

Can we have a discussion about the pros and cons of the approach to design without devolving into personal attacks? I would recommend either closing this issue or removing the posts that violate our CoC.

As a reminder, the Code of Conduct for this repo references the general Mozilla Community Participation Guidelines (CPG) and the specific Developer Etiquette Guidelines (DEG).

The CPG includes the following:

Direct but Professional
We are likely to have some discussions about if and when criticism is respectful and when it’s not. We must be able to speak directly when we disagree and when we think we need to improve. We cannot withhold hard truths. Doing so respectfully is hard, doing so when others don’t seem to be listening is harder, and hearing such comments when one is the recipient can be even harder still. We need to be honest and direct, as well as respectful.

Understand Different Perspectives
Our goal should not be to “win” every disagreement or argument. A more productive goal is to be open to ideas that make our own ideas better. Strive to be an example for inclusive thinking. “Winning” is when different perspectives make our work richer and stronger.

Personal Attacks
Conflicts will inevitably arise, but frustration should never turn into a personal attack. It is not okay to insult, demean or belittle others. Attacking someone for their opinions, beliefs and ideas is not acceptable. It is important to speak directly when we disagree and when we think we need to improve, but such discussions must be conducted respectfully and professionally, remaining focused on the issue at hand.

The DEG also recommends "No whining about decisions" (though in a different context).

@WebReflection
Copy link

WebReflection commented Feb 15, 2019

@jmswisher thanks for the concise reminder and summary.

If I can clarify anything, at least from my side, is that decisions have been taken not in the public, and this is the first public place to communicate our concerns about such decision, made over an outdated, and misinformed, ADR document.

Mozilla employees have of course the right to do whatever they want, but if they choose a direction that somehow fails to represent what's MDN is about, it's not really whining, rather hoping there's still a remote possibility to change such decision.

Since the main developer that should be interested in working, and hearing, in the open, is purposely ignoring this thread, I guess we can close this to avoid further irrespecutful comments 👋

@blikblum
Copy link

Since the main developer that should be interested in working, and hearing, in the open, is purposely ignoring this thread

This is the saddest part of all of this.

Again i'll take some words from Mozilla, this time from Mitchell Baker in an email asking for support:

People are asking, "The internet is broken, what can I do?" An important part of the answer is, build a relationship with Mozilla.

Make it as deep as you want. Sign up, ask your friends and family to sign up, donate. You should have a relationship with Mozilla. That’s where you can improve the internet as you improve your own experience on the internet.

We must demand better of the internet. And we must grow the number of people joining together with us to demand better of the internet.

So here i'm, trying to make a relationship with Mozilla and help, in my understanding, create a better web, free of non standard stuff. Just to be ignored.

@kvnxush
Copy link

kvnxush commented Feb 15, 2019

This entire thread is hilarious. If you're THAT mad about what framework they use to make their website, you can always just use w3schools instead 🙂

@WebReflection
Copy link

Can we please close this thread to avoid previous kind of irrelevant comments that would pointlessly notify everyone?
Thank you.

@davidflanagan
Copy link
Author

davidflanagan commented Feb 16, 2019

Its Friday afternoon. I'm going to try to bring some closure to this thread without, I hope, stirring up more controversy. And then I'm going to try to put this behind me and get back to work next week.

  1. This mdn/sprints repo is the MDN's team alternative to Trello and similar tools. As its name suggests, it is how we plan our work. Instead of creating cards on a private Trello board to track our user stories, we create issues in this repo. So we're working in the open, and anyone who wants to look over our shoulders can, but this repo is not really a place where we typically engage in debate or discussion about the user stories.

  2. I tried to mute email notifications for this github thread and I also said that I didn't promise to read all of the comments. I see that many of you feel that this was insulting on my part, and I understand why that makes me look like a jerk. It was a mistake, and I apologize. As it turns out the joke was on me: I was never really able to mute notifications because I kept getting tagged by name and github started sending emails again. At this point, I think I have read more than 80% of the comments here. I have been tempted to respond to some of your comments individually, but fear of creating more controversy has stopped me. Please do try to see this from my perspective: imagine yourself at work, at the start of a new sprint, and out of the blue someone on Twitter links to one of the Trello cards assigned to you, and then dozens of people start offering you unsolicited opinions on how to complete your task. What do you do? Do you spend a day responding to the comments, or do you try to ignore the noise and carry on with your duly assigned work?

  3. The decision to use React was properly made by the core contributors to the mozilla/Kuma repo. Currently that set of core contributors is the set of Mozilla employees who are paid to work on it. We do have occasional volunteer contributions, but we do not really have an active volunteer community around the Kuma server that drives MDN. (You all may not believe this, but I actually believe that using React for our frontend code may lower the barrier to entry for this project and increase our ability to attract volunteers.) My point is that the React decision was appropriately made by the engineers who are actively working on the project. It was never our goal to achieve consensus on this decision, nor would any kind of consensus be possible. I recognize that many of you are very passionate about web standards and about MDN, and I'm honored to be part of a project that inspires such passion. But your passion is not the same as working daily on a project (and having your annual review tied to the success or failure of the project!)

  4. The decision to use React had not been communicated yet outside of the MDN team. We were not hiding it; we just hadn't attempted to announce it in any way yet. This is because we don't have anything to show yet. My work this month is to try to figure out how we are going to use React. This particular user story that we're all commenting on happens to be about the site header and menus, but only because I'm using that as a non-trivial proof-of-concept. The work this month is intended to remain on our staging servers and not be deployed to production. So while you may have been taken by surprise by this decision it is not because we were trying to be sneaky about it: there's just nothing there yet.

  5. I used the decision about React as a test case for a new ADR (Architectural Decision Record) process for recording our decisions and the reasoning behind them. We're trying the process out and doing it in the open by default. It may nor may not work and we may or may not get any more ADRs checked in to the mdn/mdn repo. I'm hoping to make it a really lightweight process to encourage my teammates to make records of their decisions. My hope is that our ADRs will be a publicly readable record of our decisions. But if we find that we have to word them really carefully to avoid public controversy, then I expect that they'll turn out to be more trouble than they are worth and we'll drop them. When I wrote the ADR about React, I apparently misread the shadow dom v1 adoption stats on caniuse.com and stated that browser support for web components was lower than it actually is. I've corrected this in a superseding ADR. (It is still a pull request, but should land in the mdn/mdn repo soon.) The decision to use React still stands, but the section about web components is updated.

  6. The majority of the commenters on this thread seem to dislike React. For the record, though, let's be clear that React is open-source and that React is a tool for producing websites that are built from the web standards of HTML, CSS and JavaScript. Yes, there are intermediate steps (jsx) that are not web standards, but the end product–the MDN website–is still based on standards. Its not like we're using Flash for our drop-down menus and an ActiveX plugin to display documentation in MS Word format! I'm guessing that many of you disagree, but I feel that a developers choice of tools–including frameworks–is a matter of taste. You may love vscode, but you're never going to get me to give up my emacs. And I may love React, but I'm not going to try to tell you that you should use it on your projects. Please don't judge me and my team on the tools we use, but on the quality of the websites we produce.

  7. I love web components. I had the opportunity to use them just a little bit as the FirefoxOS project was wrapping up years ago. And I look forward to using them again some day. But: I spent 18 months using React at Khan Academy and found it to be a huge productivity boost. There is a reason that so many developers use React: it, and the mature ecosystem of tools around it, works really, really well for rapid frontend development. This may sound harsh, but if you haven't used React on a midsize (like MDN) or larger website, I don't believe that you are qualified to judge our decision. And if you haven't worked as a frontend developer in an environment where you've got product managers and user researchers and marketing teams asking you weekly to add features and A/B tests and banners to the website, then you're also not qualified to judge this decision, either. As I've said elsewhere in this thread, we're expecting to be asked to do a lot of frontend work on MDN in 2019, and it is our judgement that using React will maximize our chances of being able to complete that work. This is in part because it will make our core team (of 2 FE engineers) most effective. But also, by choosing the framework that is dominant today, we maximize our chances to find volunteers, contractors and consulting shops to help us when we need it. We haven't released a 2019 roadmap, and I can't talk about our plans right now in any more detail than that we expect to be doing a lot of frontend work. And so this also means that if you're not part of the core MDN team today you don't have enough context to understand our decision.

  8. I hear your concerns about code bloat, tag soup and accessibility. Please remember that we are experienced professionals and we understand how to avoid those problems. (And as Dan Abramov pointed out earlier in the thread, there is a lot of FUD that blames React for those problems, when the fault really lies in lazy development practices.) We're not going to adopt React and then deliver web pages that are big and slow to load. I've also heard a number of you pointing out that UX trumps DX. I agree. But we've got a lot of UX to deliver this year, and we need all the DX help we can get from our tools. If React is the framework that is going to allow us to achieve our goals, then React is what we're going to use. And I've heard a number of you mourning the demise of view source. (I kind of agree, but I don't have any data to know whether anyone actually learns web development that way anymore, or if we're all just kind of nostalgic.) If we end up doing significant server side rendering of our React components, then much of the HTML source will still be viewable via view source. But even without SSR, React produces perfectly standard HTML and CSS, that is viewable (much more usefully than a static view source view) through developer tools.

  9. Many of you have said that a website about web standards really ought to practice what it preaches and should use those web standards itself. I've already rejected the claim that there is something immoral or impure about React–it is a developer tool for producing websites based on standard HTML, CSS and JavaScript. But I get it: it would be really cool if the MDN website could push the envelope and be a public demonstration of web components (and other cutting edge technologies like service workers, for example). And if this was a personal project without a tight schedule, or if Mozilla was able to dedicate more paid employees to the job, then maybe that would be possible. I would honestly like to do that. But MDN's mission is to document web standards, not to demonstrate or dogfood them. Like any organization we've got a hierarchy and a planning process. We've got OKRs ("Objectives and Key Results") that guide our work for the year. And "Lead by example by adopting web components" is simply not one of our key results this year. If I thought it was the best way to achieve the results that are on our list, I would do it in a heartbeat.

  10. Fundamentally, I'm asking you all to trust us. We're hoping to do great things this year with MDN, and I think that the vast majority of our users will love what we do. Thank you for reading this far, and thank you for your passion about web standards and MDN.

Respectfully,

David Flanagan

@WebReflection
Copy link

WebReflection commented Feb 16, 2019

@davidflanagan ( just to be sure you'll read this 😄 ) I won't go answering point after point 'cause you have the rights to spend a peaceful weekend, and put this week behind, but I still think the message this will send will have bad repercussion for the Web development in the long term.

I've worked in 20 years from small, to medium and big projects (including FB and Twitter), and with the plethora of tools available these days, I don't buy this productivity boost you are mentioning, simply because if you need indirections to represent the Web after all, you're putting an extra layer on top, not one less.

Regardless, I do agree tools, including programming languages, are a matter of personal taste, so that selling these as "the only way to scale and develop medium size Web projects" should rather be kept underlined as highly subjective too.

In any case, I do really appreciate your time to properly address most comments and better describe what is this repository about (I work in the Open daily too, I can't imagine handling threads like this while we make decisions for our product specs) so, in few words, thank you.

@AlekzZz
Copy link

AlekzZz commented Feb 20, 2019

A lot of ppl suggesting web components are missing the point, let devs choose the tech they want to keep them engaged and productive specially when web components are extremely dreadful to work with, at the end of the day the tech doesn't matter, what matters is the end result, and if the team is happy and have a choice of the tech stack, they should write it in whatever they like.

@blikblum
Copy link

let devs choose the tech they want to keep them engaged and productive

Some MDN devs are still learning React (this info was deleted in OP), so being productive is not certain

web components are extremely dreadful to work with

This is opinion, many find React to be dreadful and think web components are " the tech they want to keep them engaged and productive"

the tech doesn't matter

This is debatable, see above comments, but will not counter argument (again)

what matters is the end result

Very true. Given the nature of project (and defined objectives) React seems not appropriate, with some caveats waiting for the devs. Let's see what we will get in a few months

@AlekzZz
Copy link

AlekzZz commented Feb 21, 2019

@blikblum An engaged developer is always more productive and a motivated team put more effort and hours into the project while having more fun. The fact MDM guys are still learning react is also what driving the whole thing, to use opportunities to learn new tech in practical environment.

I work for google and 3 month's ago for the first time in years I was given an opportunity to select tech stack for a pilot project, never seen the team so driven and excited before, the tech stack was GO+React.

btw just FYI the way opinions work is that everything I say is my opinion, no need to select one particular statement :)

@blikblum
Copy link

@AlekzZz no problems with React or Angular or Backbone or nothing at all, specially for projects starting from the ground with few upfront constraints.

In my opinion, with the declared objectives (feel free to read above), the number of challenges integrating React will be no negligent. But leading with those challenges is part of learning process.

As you said, what matters is the end product, so let's see in a few months were this will end.

@tobz-nz
Copy link

tobz-nz commented Feb 21, 2019

Wait... is this whole conversation about just making the sub-nav in the header open on click instead of hover? Seems like a couple of lines(literally just toggle some class names) of vanilla js would do that easily. Why would you bring in a any framework to do that? I feel like I've missed something.

@afr114
Copy link

afr114 commented Feb 21, 2019

@davidflanagan One thing you'll find rewriting the header is there is going to be some tricky logic dealing with React synthetic click/keyboard events and actual DOM events clashing a bit when you click on a React drop down element and a non react element. Happy to help if you get to that point.

@jgmac1106
Copy link

jgmac1106 commented Feb 21, 2019 via email

@Sinewyk
Copy link

Sinewyk commented Feb 22, 2019

Random advice from a random dev 😎 : I've always struggled with chosing the right technology. But then sometimes you just have to go in and do the job.

But if you are consistent, you can just remove the fear of bad choices knowing you have something like jscodeshift (sorry haters, it's another facebook library) and change everything with peace of mind. Edit the transform, run it, check results, git checkout, rinse & repeat until happy.

Just go with whatever you want, be consistent, and you can, if you want it, just shift everything if you aren't happy with the result. Go from mocha to jest, jest to mocha, react to mithril, mithril to snabbdom, react to hyperhtml, rxjs to mostjs, jquery.ajax to superagent, pattern to pattern.

If there's a pattern, you can find & transform it. Go nuts :shipit:

This concept of coding editing code for me changed my life as a developer. I truly hope it becomes available, in one form or another, in all available languages.

TL;DR: Go nuts with react, jscodeshift has your back if you change your mind.

@davidflanagan
Copy link
Author

This is working on the staging server, which is as far as we're planning on taking it for now, so I'm closing the issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests