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

Pick a frontend framework #762

Closed davidflanagan closed 5 years ago

davidflanagan commented 5 years ago

We need to pick a frontend framework for use in Kuma. React seems like the obvious choice, but we should do a bit of research before deciding for sure.

Factors we should consider:

User Story

As a Kuma developer, anticipating the need to implement many non-document features for Kuma, I want to adopt a frontend framework (React or similar) to increase my productivity in 2019.

Acceptance Criteria

jwhitlock commented 5 years ago

I'd like to add some more metrics to judge a framework with:

I don't consider these blockers, but I'd prefer frameworks and architectures that have a good story around these issues.

davidflanagan commented 5 years ago

I spent some time looking at repos in the mozilla github organization and scanning their package.json files.

Some of our oldest website (www.mozilla.org, developer.mozilla.org, support.mozilla.org) are django apps from the jquery era that do not use a frontend framework.

But we also have many React-based sites:

This is not a comprehensive survey, but I did not see any sites at all using Vue, Angular or other React competitors. Even if there are a few of those, it appears that they are completely outnumbered by React-based sites.

davidflanagan commented 5 years ago 
* Can the content be accessed with JS disabled?

React does support server-side rendering. I not super clear on just how it works. I believe that it is usually intended as a perf boost, not a way to support the no script crowd. (I kind of thought that people gave up on websites without javascript a couple of years ago). John points out that we already require JavaScript for logging in so if we're going to try to preserve some kind of legacy site that works without JavaScript it will only be for non-logged in users, which simplifies things.

* Can a strong Content Security Policy be enforced?

This seems completely orthogonal to me, but I don't know much about CSP, and maybe I'm missing something. @jwhitlock: could you clarify your concern on this?

* What is the expected impact on users with low bandwidth and less capable devices?

Sites that use frameworks are always going to be more bloated than those that don't. Hopefully things like doing client-side navigation once a user has loade the site will more than make up for any increase in the initial load time.

I don't think that React is any worse in this regard than its competitors. For development speed I think we need a framework. One bright side to using a really popular framework like React is that the tricks to making everything perform well will be well-known.

jwhitlock commented 5 years ago
  • Can a strong Content Security Policy be enforced?

This seems completely orthogonal to me, but I don't know much about CSP, and maybe I'm missing something. @jwhitlock: could you clarify your concern on this?

I'm assuming we'll host the JavaScript and other assets for the framework, or load them from a trusted source. Either is fine with a strong policy. The issue is if eval is required, or inline JS and CSS blocks. This would require us to use unsafe-inline, and reduce protection from injected JS.

tkadlec commented 5 years ago

Hopefully things like doing client-side navigation once a user has loaded the site will more than make up for any increase in the initial load time.

This will be important to keep an eye on. I did a lot of work this past year with companies who built something in React and, upon launch, realized they had serious performance issues to resolve. I know @atopal had discovered early in our performance work last year that there was a definite relationship between performance on some less-capable devices and they way they interact with MDN. React (or any similar framework) does carry the risk of straining those CPU's further if we're not careful.

If you're going down the React route, in addition to prioritizing server-side rendering the content for A) better performance and B) better resilience, it's also worth considering using Preact (https://preactjs.com/) instead of React. Preact is mostly a drop-in replacement (some sites can get away with a simple line or two config change) with the same surface-level API that is a fraction of the size.

davidflanagan commented 5 years ago

I looked at preact. It appears that React 16 has closed the rendering performance gap, and so now the difference is just in the size of the required libraries. I'm guessing that our bundle size will grow big enough that the ~25kb (?) difference won't matter much. But it is good to know that we have the option to switch to preact.

@tkadlec: if we take as a starting point that we need to adopt some kind of substantial front-end framework is there something you'd recommend over React/preact?

schalkneethling commented 5 years ago

it's also worth considering using Preact (preactjs.com) instead of React.

I looked at preact. It appears that React 16 has closed the rendering performance gap, and so now the difference is just in the size of the required libraries.

Agreed. From what I have heard, the main focus of the React team is the performance at this point. React is mostly fully baked at this stage, and improving things such as over performance and accessibility is where the main work is required. The overall bundle size is also something that is going to change (downward).

With that said, I agree that looking into some server-side rendering makes sense(I believe this is done using Nodejs?). There is also the possibility of loading components on demand, and focus the initial load on that which is critical to the user.

schalkneethling commented 5 years ago

I did a small experiment using React to write the Codepen based interactive example and using Parcel as the build tool. Nothing earth-shattering, but interesting I reckon:

https://github.com/schalkneethling/iex-pen

davidflanagan commented 5 years ago

Nice!

schalkneethling commented 5 years ago

I am going to build a small component today to experiment with styled components(https://www.styled-components.com/). I am thinking of building the banner component on the landing page perhaps. Will post a link to the repo once I am done.

schalkneethling commented 5 years ago

Ooooh, we can get hashed files easy with Webpack: https://gist.github.com/schalkneethling/48fa4f2ba22b2fa1bcfde0dffee83c95

davidflanagan commented 5 years ago

Parcel does that too, doesn't it?

schalkneethling commented 5 years ago

Parcel does that too, doesn't it?

It probably does yeah. I just thought it is really neat and wanted to share ;)

davidflanagan commented 5 years ago

I've written up a proposed ADR here: https://github.com/mdn/mdn/pull/52

jwhitlock commented 5 years ago

ADR 001, "Use React for the MDN Frontend", is merged.