search

mdn / sprints

Archived: MDN Web Docs issues are tracked in the content repository.
https://github.com/mdn/content
Creative Commons Zero v1.0 Universal
150 stars 142 forks source link

React Spike: Rewrite the MDN page header #967

Closed davidflanagan closed 5 years ago

davidflanagan commented 5 years ago

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:

Acceptance criteria

ExE-Boss commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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

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

WebReflection commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

thepassle commented 5 years ago

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.

web-padawan commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

WebReflection commented 5 years ago

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:

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

How does this affect the accessibility story?

ExE-Boss commented 5 years ago

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

justinfagnani commented 5 years ago

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

cferdinandi commented 5 years ago

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

WebReflection commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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:

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Hey @davidflanagan that snoozed his own thread:

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.