I humbly disagree. I've never built a highly interactive application with React, only simple sites where the guys before me chose React, so I can't speak to its relative strengths or weaknesses there, but I've found that it doesn't scale down very well to simple sites. For a simple sign-in page, it's easy to just store state in the DOM and use a element to send the credentials, and maybe a little JS for the password show/hide button. But to implement it in React you have to go on a steep learning curve to learn about JSX, hooks, the component lifecycle, building the app for dev, packaging it for prod, and more. Other frameworks, like Vue and Alpine, let you use them "progressively" and you can even do so with a CDN to avoid having to set up npm/vite from the get go. Their intro docs have instructions for how to do so, along with the relevant caveats React claims to be progressive, but since it's JSX it requires a compile step. Its intro docs do not have instructions for using it via CDN. You can make it work if you really want to, but it basically requires shipping the compiler to the client along with the JSX and doing the compilation client-side, which obviously scales so poorly that their docs don't cover it. To recap, my whole point is that React scales very poorly down to simple sites. And since most site are not Facebook or the Spotify web player or Netflix (and even Netflix is moving away from React: x.com/NetflixUIE/status/923374215041912…), I think it's very hard to argue that React is effective or well designed.

This is exactly right. A lot of posts regarding loading times or bundle sizes for frameworks/libraries forget that there are trade-offs when it comes to building an application. The correct way to frame this is: use a slow/clunky/large/etc framework vs. build everything from scratch (which comes with its own costs). Sure, you can optimize parts of your application to speed up the JS portion or even remote it completely [1], but it's not always as simple as "your framework is making your application slow so you should think about ditching it." This article actually ends with a very reasonable conclusion in the section "Are Frameworks Evil?" but I've seen plenty of articles where the author doesn't offer an alternative to some library/framework [2]. [1] twitter.com/netflixuie/status/923374215…... [2] dev.to/gypsydave5/why-you-shouldnt-use…...

Hey, I work on the team at Netflix that gave the talk on React in the signup flow in the tweet. The full talks are available here if people want to watch them: youtube.com/watch?v=V8oTJ8OZ5S0&t=11m30s Thought I'd also provide some more context on some common questions that people have asked. ### Why are you using React to render a landing page? The Netflix landing page is a lot more dynamic than most people think it is. It's our most heavily A/B-tested page in the signup flow, with even some machine learning models being used to customize the messaging and imagery that you get depending on location, whether or not you were a previous Netflix member, device type, and a lot more. Even beyond that, Netflix supports almost 200 countries now, and there's a different combination of localization, legal challenges, and value messaging for each one. We end up sharing a lot of the logic and UI for these A/B testing and localization challenges throughout the signup flow, mainly through React components. The example I always love to give is the component that we have, which to a Netflix customer signing up is literally one or two checkboxes on the UI, but has some of the most complicated logic in the codebase due to the vast number of countries and user states we support. Because of all this, it's more valuable for us to share these common React components across the entire signup process, both the landing page and the rest of the flow, which is a single-page React and Redux application. We've seen a lot of conversion value though in improving the performance of the landing page, especially in countries with slower connections, but we don't also want to re-duplicate a lot of the shared UI logic that we have. The tradeoff that we decided to make is to server-render the landing page using React, but also pre-fetching React / Redux / the code for the rest of the signup flow while on it. This optimizes first load performance, but also optimizes the time to load for the rest of the signup flow, which has a much larger JS bundle size to download since it's a single-page app. ### What's the performance metric that's being used? It's TTI (Time to Interactive), when the user can fully interact with the page. This is different than TTR (Time to Render) for us, when the user can fully view the page. There's more information in the talk about the differences. ### Why not Service Workers or some other pre-loading / caching mechanism? We have been experimenting with it, but it's mainly the lack of some browser support - Safari is the main one. Generally the Netflix signup flow needs to have more legacy browser support than the Netflix member experience. Lots of people sign up on a pretty old browser, but only ever watch Netflix on the native mobile apps or a TV device. ##### Feel free to comment here or tweet at Tony (twitter.com/tedwards947) or me (twitter.com/clarler) if there's any other questions that we can help answer. Though from a lot of experience, 140 characters isn't always enough to provide enough context for JavaScript framework discussions. ;) If these sort of performance and UI challenges seem interesting to you, our team is also hiring for UI engineers and an engineering manager! * Senior Software Engineer (React, Node): jobs.netflix.com/jobs/864767 * Senior Software Engineer (Android): jobs.netflix.com/jobs/864766 * Engineering Manager: jobs.netflix.com/jobs/865119 Cheers!