I used to think that React is awesome, but this has gone too far. They just don't care about JavaScript.<p>1. They introduced hooks which must be called in the same order for every execution. You can't put hook inside `if`. Hooks are based on magic. This is terrible design.<p>2. They didn't adopt async/await, inventing their own suspend stuff.<p>3. Now this: they just convert the source language into something else.<p>The JSX idea is gold: introduce XML-like template syntax into the language to avoid need for foreign template language. Make XML templates valid at startup and even with proper types for TypeScript. This is very important advancement compared to text templates which are used everywhere else.<p>The stateless render function is good. Emit desired-state, let framework to reconcile current state to desired state.<p>But rest of React is not gold.
I love React. It feels foundational somehow. It's also vindicating after toiling for years on bloated frameworks. Declaratively describe your UI, React paints it. That's it. No app state management. No routing. No learning yet another templating system (which inevitably morphs into a shitty programming language). Just full JS(X optional). No grokking convoluted, bespoke abstractions. It's clean, narrowly scoped, and as simple as possible (but not simpler).<p>Having recently worked on two legacy apps -- one ASP.NET, one Angular -- it made me deeply appreciate React and how far UI tech has come. Phenomenal work from the React team on more optimizations via this compiler. Good article too.
I haven't used React in about 6 years - used to be pretty heavily involved with it across web and native. These days I truly feel like ecosystem has lost its mind and the developers are just bikeshedding the most esoteric and unhinged choices possible.
I think React would get better developer experience and performance if they adopt language coroutine feature to implement direct style algebraic effect. In fact the React Fiber system is already an implementation of algebraic effect.[1] However, it’s “suspending” a routine by raising an exception. Thus unwinding all the call stack, therefore, it needs to re-run that same routine on resume. This is the core reason why they have a performance issue and why they created the compiler to cache values on reruns.<p>JavaScript has language level coroutine features like async/await or yield/yield* and we have seen libraries using these features to implement direct style algebraic effect. For example Effect[2] and Effection[3]. You don’t need to memoize things if the language runtime can suspend and resume your functions instead of throwing exceptions and rerun them.<p>[1]: <a href="https://youtu.be/7GcrT0SBSnI" rel="nofollow">https://youtu.be/7GcrT0SBSnI</a><p>[2]: <a href="https://effect.website/" rel="nofollow">https://effect.website/</a><p>[3]: <a href="https://frontside.com/effection/" rel="nofollow">https://frontside.com/effection/</a>
What am I missing? You gave two examples:<p>The first is replacing useMemo with some inline code that does the same thing, so, as far as I can tell that literally saves just one function call to useMemo but none of the actual work it does? How could that possibly have a performance impact?<p>The second is de-inlining (or whatever the proper word is) map(x => foo(x)) to save function definitions on each loop. I don't understand why a "React compiler" would be able to do this if a JS JIT compiler can't, what guarantee does it have that a JS compiler doesn't? This should be done by V8 or not at all.<p>Even though you have a whole paragraph on the cognitive load of an extra compilation step at the end of your post, which is bang on, IMO you don't even come CLOSE to explaining why this trade off is worth it.<p>I've been telling people for nine years that React is the best of the declarative DOM libraries because it has a simple line-for-line transform instead of a big complicated compilation step. It looks to me like we're just throwing that all in the bin for absolutely fuck all.
The thing I'm struggling with as I read the official documentation and various blogs is exactly how this changes the <i>developer experience</i>. Do I get to remove `React.memo` and `useMemo` and never use them again? Is their use still useful for other cases? What do I have to think about when writing components so that I get this automagical memoization in some cases?
I love how we're all talking about state management.<p>Just use Remix. The database/url is your state.<p>Messy state management in Client-Side react is a problem of the late 2010s
I’m the author of this blog post, very cool to have it here.<p>One thing I didn’t say in the post: I’m very much a fundamentals-first kind of dev. I teach fundamentals in my courses.<p>I don’t think you should use tools like frameworks or transpilers/compilers without understanding how they work, because debugging is always better when you know what the tool is doing for you, and it makes it easier to use the tool. React is a particularly leaky abstraction that benefits from understanding it under-the-hood.<p>You need strong fundamentals to understand how things work.
I’ve worked with React, plenty of years. I haven’t had to touch it in months and don’t want to.<p>Seeing JSX and reading about all the complexity in this post makes me hope I’ll never use React again.<p>BTW I do like JavaScript.
For almost 10 years, the core react developers would repeat incessantly: React is a library, not a framework.<p>In the past 2 or 3 years, they just "gave" up, turned it into the biggest most bloated framework in the frontend area while the official Web APIs in the browsers evolved so much that React is actually completely useless and now it is completely useless with a compiler.<p>I'm wondering if that was actually the reason they pivoted to this Frankstein? The loss of relevance as a frontend library.<p>Anyway, I jumped off the bandwagon and don't have a say in this fight anymore. But I'm doing my part advising every Junior Developer to not make the mistake of choosing React today.