Sprints: React Spike: Rewrite the MDN page header

[davidflanagan]

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

• [x] Wiki pages loaded through the new endpoint (see issue #965) have a React-based header
• [x] The menus in the header do not appear on hover!
• [x] We have synthetic page load data comparing the new header to the old header

[ExE-Boss]

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]

@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]

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

• https://medium.com/@WebReflection/consider-hyperhtml-before-replacing-anything-154a2104d6e3
• https://medium.com/@WebReflection/hyperhtml-a-virtual-dom-alternative-279db455ee0e
• https://medium.com/@WebReflection/lit-html-vs-hyperhtml-vs-lighterhtml-c084abfe1285

---

See also https://github.com/mozilla/dispensary/issues/465

[WebReflection]

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]

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]

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]

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

[thepassle]

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]

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]

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]

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]

@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]

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]

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:

• https://itnext.io/a-wicked-custom-elements-alternative-6d1504b5857f
• https://itnext.io/neverland-the-hyperhtmls-hook-a0c3e11324bb

[pinguxx]

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

[WebReflection]

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]

lighterHTML is to hyperHTML what Deno is to Node.

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

[cferdinandi]

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]

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]

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]

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]

@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]

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]

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]

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]

@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]

How does this affect the accessibility story?

[ExE-Boss]

@kenchris Probably not in a good way, given React’s obsession with using <div>s everywhere.

[justinfagnani]

@davidflanagan would it be possible to update the ADR though, especially the section on web components?

[cferdinandi]

FWIW, React can be accessible. It just has a well-earned reputation for doing so terribly because... defaults and developers?

[WebReflection]

@davidflanagan

And that has to outweigh concerns about the purity of the solution.

Apologies 'cause I'm sure you mean well but this reads to me like:
We're a green company but since we have big plans for this year we're ok if everyone working for us uses 1 car to reach our office daily.

[ExE-Boss]

I have opened https://github.com/mdn/mdn/pull/58 to correct the section about WebComponents and put extra emphasis on the fact that Firefox is using them for the UI now.

[justinfagnani]

@davidflanagan also regarding SSR. Custom elements naturally work with static pages, CMSes, and classically server-rendered pages. This removes a _lot_ of complexity around the server side of the app, and questions about how to mount frameworks components into an otherwise markup (or markdown) driven page.

With web components you can just add them to markup:

<body>
  <mdn-header>
    <h1>MDN web docs</h1>
    <mdn-menu>Technologies</mdn-menu>
    <mdn-menu>References & Guides</mdn-menu>
    <mdn-menu>Feedback</mdn-menu>
  <mdn-header>
  ...
</body>

Modern web component libraries are small enough (~5k for LitELement) and fast enough (faster than React typically) that you basically don't have to care about "deep" SSR with this setup. Aside from adding the scripts that implement the elements, it probably requires little to no changes to your CMS.

[gaearon]

How does this affect the accessibility story?

React lets you create fully accessible apps. If anything, React helps you do that because the component paradigm lets you write pieces of UI that enforce accessibility best practices and avoid regressions.

We have some guidance on that here: https://reactjs.org/docs/accessibility.html

There are many React projects that treat accessibility with the priority it deserves, and help developers achieve better outcomes:

• https://reach.tech/
• https://github.com/downshift-js/downshift
• https://www.npmjs.com/package/eslint-plugin-jsx-a11y

Quoting David:

Case in point: Our pattern library exposes buttons and form fields as reusable components. It requires effort to make an implementation inaccessible. https://www.starbucks.com/developer/pattern-library

Of course there are teams who ignore all of that. Ultimately, whether your app is accessible or not has more to do with the priorities of your team, and even using React won’t help you if you don’t care about your users.

Probably not in a good way, given React’s obsession with using <div>s everywhere.

This FUD is especially interesting because React was (one of?) the first mainstream component libraries that implemented fragments — returning multiple nodes from a component without extra wrapping or need for extra divs.

[ExE-Boss]

Probably not in a good way, given React’s obsession with using <div>s everywhere.

This FUD is especially interesting because React was (one of?) the first mainstream component libraries that implemented fragments — returning multiple nodes from a component without extra wrapping or need for extra divs.

Ok, this isn’t really a fault of React per se, but the fault of React based projects I’ve seen out in the wild.

[gaearon]

Ok, this isn’t really a fault of React per se, but the fault of React based projects I’ve seen out in the wild.

You could say the same about jQuery projects or, really, anything that’s popular. I don’t see how developers ignoring a11y is relevant to MDN. Presumably, MDN developers care? :-)

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 (div all the things) and simplifies inline style per element, on the #1 stop to learn about Web Standards.

“div all the things” is a strawman argument that has nothing to do with React — as you can see from https://github.com/mdn/sprints/issues/967#issuecomment-463290568. Repeating it doesn’t make it any more true or advance your argument.

You can use React without JSX, which some Mozilla projects happily did. For example, the highly successful (as far as I know) Firefox debugger rewrite in React. HTM is a nice syntax sugar for that which uses tagged literals instead of JSX. So that’s an option too. React is pretty flexible.

---

All in all, I’m not here to advocate for React. Just wanted to highlight some common misconceptions and mention that we’d be happy to answer questions about React if you have any. Cheers. MDN is a great resource, and I hope whatever choice you decide on will make it ever better.

[gaearon]

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.

This argument is also repeated in this thread. I want to point out that “Inspect element” works perfectly fine in React apps. React produces regular DOM nodes, and that’s what you see in the inspector.

There do exist approaches that favor the user (e.g. minification of CSS class names) over the casual developer and tinkerer. They might make sense for some consumer apps, but I think those would be a worse tradeoff for MDN, and wouldn’t recommend them.

If MDN were to use React, I think it would be ideal if the DOM output was clean and easy to inspect by hand. That’s easy to accomplish with React — just as easy as with Vue or another popular UI library. Like I mentioned, it might in fact be easier in React thanks to having a way to avoid wrapper divs.

React doesn’t put any junk in the DOM — just the nodes you return from your components. Talking about “virtual DOM” is a meaningless distraction in this discussion. It’s all regular DOM in the end.

[matthewp]

Hi @davidflanagan, I appreciate your willingness to hear feedback here.

I think one thing that is not being discussed here is the value that comes from dog-fooding web standards as a company that builds a web browser. You'll not be able to improve web APIs if you don't use them. Yes, React of course uses web APIs but they are for the most part abstracted from you.

One thing I always admired about Mozilla, thinking back to the Boot 2 Gecko days, is how everything they worked on cycled back to improving the web platform. It would be a shame if Mozilla starts using heavy abstractions that prevents them from doing that.

[gaearon]

@matthewp

I agree this could be a compelling argument against React in case of MDN.

Much of React’s success, in my opinion, comes from its heavy usage at FB, and FB’s heavy usage of _FB itself_ for work. When we break something, we usually notice very soon because the updates are rolled out to employees first, and if crucial tools like messenger, workplace, and internal tasks stop working, we have to fix them. We also can’t push APIs that don’t work very well onto the product teams, as they won’t want to use them. That makes it more difficult to evolve React, but the result ends up much better than if we just used our own ideas and judgement alone.

So in that sense, it might make sense for MDN to be dogfooding the web APIs it teaches. This can work assuming the MDN team has some influence over the browser and standards work at Mozilla. I don’t know whether that is the case.

[bennypowers]

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.

Any developer that understands react components can write components with lit-elements. The concepts are totally congruent.

In fact it's easier to write styles in shadow dom than it is to use css-in-js.

[WebReflection]

@gaearon

You can use React without JSX, which some Mozilla projects happily did. For example, the highly successful (as far as I know) Firefox debugger rewrite in React. HTM is a nice syntax sugar for that which uses tagged literals instead of JSX. So that’s an option too. React is pretty flexible.

If you don't use JSX but use HTM, which needs a mandatory transpilation for production, it's the same, that's not the platform.

Moreover, HTM uses same non standard syntax for feature parity with JSX, and the fact HTM uses template literals simply shows the power of the platform, where projects like hyperHTML or lit-html mastered the template literals technique in a way that makes HTM look like a double indirection of what the platform could do already.

Beside all this, we all come from an era where looking at the source code of a page would lead to a learning experience.

React and every other framework that takes the standard away from the implementation makes learning from source code impossible.

MDN is all about learning, and lighterhtml, as well as hyperHTML or lit-html, would reflect their templates as they are on the live, inspectable, source of the page.

Same would go for Custom Elements too.

In a site famous for letting devs and new comers learn from the platform, I think it's unacceptable to use hard abstractions that would make learning from the source super hard.

[Jefftopia]

From the doc

But the lack of tools, ecosystem, and developer community makes this a non-starter for now.

In the future maybe we'll be able to use Web Components for small components, and tie them together into larger components with React.

The above rationale suffers from risking the absence of web-standards being a _self-fulfilling_ prophecy.

It is absolutely unacceptable that an _open_, web-standards-delivering company opt for highly proprietary, opinionated framework from a morally questionable company in lieu of trailblazing the standards you are tasked with delivering and evangelizing.

Not a great tooling? Not a great community? Have some skin in the game and help create it. I would _love_ to see more open standards. MDN's planned adoption of React is a step _back_.

[robrez]

There are valid criticisms like subpar support for custom elements

That's a bit like saying there's subpar support for _library/framework x_ until you add the requisite javascript libraries, isn't it? Custom elements, at least, do not need any requisite libraries in most cases. For the remaining cases, the fallback lightweight polyfills are done quite well.

It sure is nice to be able to do things like this and have them work:

    document.body.appendChild(document.createElement("hello-world"))

It seems like framework/"library" authors ought to eventually look at their specific component models as a different-flavored base-class for making native custom elements.

Kind regards

[davidflanagan]

The MDN team made our decision about React last sprint. This sprint we're trying to figure out how we're going to put that into practice. This github issue was intended to be the place where I tracked some of my work this sprint. If you want to understand it in context, you should probably also look at issue #965, issue #966, issue #968 and issue #969. (Though I would appreciate it if you would not carry this conversation over into those issues.)

You all are welcome to continue debating React vs Web Components here, if you want. But know that I've muted email notifications and I don't plan to respond to most of the comments.

The decision to use React was made for the pragmatic reason that we believe that our tiny team will be best able to move quickly and deliver features to our users with React. There are many good things about Web Components. But given the ambitious goals that the MDN team is tasked with this year, they are not the right choice for us.

[veikkoeeva]

Looking at the linked issues and https://github.com/mdn/mdn/pull/53/files#diff-992ca475abeb0c101165f19ff62d37e7R136 about Flow

• Half the MDN frontend team already has experience with Flow, but no one on the team has experience with TypeScript
• More Mozilla projects use Flow than use TypeScript. The projects using TypeScript seem to be smaller and newer
• Flow is more like a linter that checks types and strips type annotations leaving standard JavaScript.
  TypeScript is more like a compiler for a new language. If we were to choose TypeScript we'd also
  have to decide which of its non-standard language extensions we will use and which we will not allow.
• Fundamentally, it seems wrong to me for Mozilla (the spiritual home of JavaScript) to be starting projects using a language that includes non-standard (and not on a standards track) extensions to JavaScript. As Brendan Eich says "Always bet on JavaScript".

This looks like being the wider context.

[WebReflection]

Hey @davidflanagan that snoozed his own thread:

• #968 doesn't need React
• #969 needs a change in your servers (time + money)
• You can test both #965 and #966 in your localhost

Recently MDN is showing some bigger than usual banner, rightly asking for contributions, and I've always been keen to that, when it comes to projects that matters (ArchLinux, GNOME, and Mozilla are indeed in my usual payed contributions portfolio).

Since I don't get to even be listened to in here, I am not willing to contribute to this madness, neither as a content editor.

Feel free to revoke my rights, and I wish you best luck with all this 👋

[Jefftopia]

@veikkoeeva Ironic that Custom Elements weren't chosen because the community is too small and tech too new/unfamiliar, but the team chooses Flow. A rather inconsistent line of reasoning.

using a language that includes non-standard (and not on a standards track) extensions to JavaScript.

Is a case for Custom Elements, not React. It sounds like there are some React kool-aid drinkers over at MDN, and that this is about someone's favorite toy instead of an objective conversation.

If the decision was based on a mix of standards compliance, tooling, community, performance, it seems that Angular would have been the way to go, not React + Flow (Sure, Angular is less popular than React, but it is by no means small or niche).

At least Angular can _output_ Custom Elements too. This would give the team the flexibility to "move quickly" while being positioned to adapt to web standards later.

[ematipico]

The decision to use React was made for the pragmatic reason that we believe that our tiny team will be best able to move quickly and deliver features to our users with React.

As a user, I would like see Mozilla that uses web standards to promote web standards.

As a developer, I would like see Mozilla and their developers using web standards and promote them. I don't need to see the nth React project.

[web-padawan]

Mozilla has been quite active in advocating the diversity among browser vendors when Edge announced moving to Chromium.

Please compare this with the current case when MDN developers are going with the mainstream framework and do not advocate the diversity anymore.

I have to admit that React has wide adoption for reasons. But now, thanks to such opinionated decisions, it is at risk of becoming a "standard de facto".

[jalcine]

As a developer that pushes for selfdogfooding, the use of React will be antithetical to Mozilla providing a place for documentation and demonstration of Web technologies. It'd actually help the act if instead the site was done with WebComponents directly and add potential examples of how React can be used _in the documentation_ (not in the source thereof). Thankfully, the site is an open Wiki of likes so we can extend what we needed.

We should see React as an _extension_ of what the browser has to offer; not as an authoritative representation thereof.

---

Slight syndication + rehashing over at my site.

[unclechu]

@davidflanagan If you're going to rewrite MDN using React I assume it's going to require enabled JS to render any content so it would make it impossible to obtain any content as a static data which is sad by my opinion. It can be solved by Server-Side Rendering (SSR). If you haven't planned implementing SSR by yourselves I'm offering my help with that (since I'm experienced with that) as a volunteer. I could afford some time to at least produce a backbone for SSR. Feel free to contact me if it would be a good idea.

[davidflanagan]

Thanks for offering @unclechu. One of our goals this sprint is to at least try SSR. I have not set that up before, and would welcome some pointers. To start, however, we're going to have a little bit of react inside of jinja templates, and I don't know whether SSR can work in that situation.

Once https://github.com/mozilla/kuma/pull/5254 lands there will be something concrete to try rendering on the server, if you want to take a stab at it!

[Tbhesswebber]

I think that this is some really great discussion, but people are having a hard time separating their experiences and heresy from fact about "the other side". "Div everything" is as standard for developers as seeing <some-component> in the DOM is semantic. Neither side is "right" and both React and Web Standards are as likely to change in three years as the other.

At the end of the day, none of us should care what MDN uses - we should care that the devs who have put so much effort into building a resource that has massively contributed to our own education and will continue to do so on a daily basis are productive and happy.

I will, however, leave this here for people to pontificate upon... 2018 State of JS (web components, in general, are under the "Other" page...)

[ExE-Boss]

@davidflanagan

To start, however, we're going to have a little bit of react inside of jinja templates, and I don't know whether SSR can work in that situation.

React doesn’t work all that well with Jinja and other non‑JavaScript SSR solutions well from my experience.

This is because there’s no React for Python, and React works using its VDOM, whereas Jinja2 and similar assume that they’ll be outputing pure DOM, which is a bit difficult to wire with React.

But if you really want to use React, I at least recommend using https://github.com/rstacruz/remount, which creates a React environment inside a Custom Element, so that React doesn’t leak into non‑React scope, which is a possibility.

Plus, custom elements already work with Jinja2, given that they behave like normal HTML tags, except that they have at least one - in their tag name.

[unclechu]

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

1. Writing a process in node.js (with React SSR stuff inside) which reads something like JSON-commands from __stdin__ and returns to __stdout__ rendered html code using React SSR;
2. Starting that process from Python as child-process permanently;
3. Asking from Python main process to render something from node.js process and reading result from stdout.

Also it would be better to run few SSR workers and balance requests between them. Maybe there's some python lib to serve such queues? Or as an alternative we could run SSR processes (workers) as a local-hosted HTTP-servers and balance them with local nginx-proxy, and from main Python process request renders via HTTP. But of course using HTTP layers adds some overhead and forces us to control SSR-workers apart from main Python process.

[antmak]

React makes front-end development easier.

We need to make user experience easier, not development.

[vipickering]

In particular the statement here(highlighted in bold) made me sad.

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.

While I respect your decision (you understand your needs/constraints better than I do) I find it sad that web standards are being over looked for custom frameworks.

This means you are doing the same thing other companies are doing and overlooking Web components for React; Systematically alienating the standard for a custom tech which becomes self-perpetuating. If we don't use these technologies at scale we dont uncover the problems and learn how to fix them. Every time a large entity in a privallaged position chooses custom tech over the standard it takes us one step closer to a non-standardised world.

[jgmac1106]

MDN is going to React???? The day you can't hit "View Soucre" and see human readable data on Mozilla web documents will be the day the Manifesto truly becomes meaningless

I'm not angry really sad. MDN is supposed to be the model of web standards.

Mozilla employees are like frameworks they come and go but HTML is forever. Choosing a framework because a team knows it wrong.

You need to be hit "view source" and read not see a much of scripts. Greg McVerry. I know folks say well MDN code will be available in the repo. In my browser window when I hit view source, if the mission is equity and access....sayign "here's the repo" is not the same. Mozilla teachers throguh source code not frontend frameworks

As a contributor to MoFo and MoCo I have seen this story play out and always looked to MoCo and MDN with the commitment to HTML first as a north star

MoFo would be all about the latest and greatest framework trying this and that making resources harder and harder to remix (they very essence of what being open means) while MoCo always held firm. Always stayed committed to an open human readable web.

I worry those days are over

Look at MoFos track record of developing software and platforms literally every single one is gone and failed. Look at anything Mozilla has done in HTML. It is still there. Forever

Every existing product built on REACT is a MoFo project and almost every single one is marked for sunsetting and deletion.....

We have enough data to know this is a failed path. Like every time we tried.

Go read the top reason for choosing React:

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

Choosing to abandon the open web because one person on staff knows it is a bad idea. Employees will not last longer than HTML.

Web components will eventually be the standard component system for the web,

NO! Web components ARE a standard and an OPEN standard. They only survive in the face of corporate greed when Mozilla stands up.

The MDN has ambitious goals for 12019 that we can't share.

When did Mozilla lose its attitude to open? This shift to React and away from the open we reflects a turn away from open contributors and a disdain for Mozillians who want to contribute. We are just seeing another example of Mozilla turning our back on the Manifesto.

I mean @davidflanagan MUTED HIS OWN THREAD basically saying we don't care what the community thinks. We are Mozilla we make software FOR open source contributors but we no longer have any desire TO BUILD with open source criteria.

I know the team feels JQuery and javascript present limited choices fro complicated UI (so use less), and I won't hype web components more than they are. , I struggle with front end design as well battle every, but I made a promise to the open web. Mozilla should do the same.

We need to work together but r to make it better using open standards in a web first way, will always support MDN...but just hope I can still click "view source" and not see gobbily gook

[jesstelford]

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]

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]

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]

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]

@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).

[montogeek]

@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]

@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]

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]

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.

On Fri, Feb 15, 2019 at 8:04 AM Luiz Américo [e-mail]
wrote:

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
https://hacks.mozilla.org/2018/11/the-power-of-web-components/, by
@potch https://github.com/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

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mdn/sprints/issues/967#issuecomment-464043715, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AKC-pksCLYL1ZvfIRE8QFMSNB-XUBuXYks5vNrBbgaJpZM4amRE9
.

[ExE-Boss]

@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]

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]

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]

@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]

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]

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]

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

[davidflanagan]

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]

@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]

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]

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]

@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]

@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]

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]

@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]

Wow never thought about the learning perspective and letting people
contribute, whether paid or volunteer, to also build in a way to support
their goals.

Important point to consider.

On Thu, Feb 21, 2019, 1:25 PM afr114 [e-mail] wrote:

@davidflanagan https://github.com/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.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/mdn/sprints/issues/967#issuecomment-466110591, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AKC-pvhTHJwO6vGGktoI19ZJO6LdnQqiks5vPuSQgaJpZM4amRE9
.

[Sinewyk]

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]

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.