21 ms·
Understanding React Compiler
- chrsig 2y agoSlightly tangential question: Where is jsx defined, as a language? are there multiple transpiler implementations? is it standardized at all?
- Waterluvian 2y agohttps://facebook.github.io/jsx/ https://facebook.github.io/jsx/ answers some of that.
- mmis1000 2y agoJSX only have syntax defined but not semantics. The equivalent runtime js code is up to the compiler of the framework you are using (And even react itself have two compile modes now).
- meiraleal 2y agoJSX was unique while we didn't have native string interpolation in JS. With Template literals, JSX isn't that special anymore.
- jampekka 2y agoDon't know why you are downvoted (Stockholm syndrome, sunken cost fallacy?), but JSX is a bizarre hack, and there are many less hacky alternatives, like template literal based HTM, function based hyperscript and even const e = createElement.
- a_wild_dandan 2y agoMy guess: It's probably downvoted for being so hilariously wrong that's not worth engaging with. One of those dismissive hot takes commensurately worth dismissing too.
- jampekka 2y agoThese kinds of answers (and downvotes) typically stem from not having any substantive arguments for a held position.
- rvense 2y agoIME "I'll just use createElement" leads to "Oh dear, I have to add another createElement" which leads to "I really don't like reading this code". But of course it's a trade off.
- jampekka 2y agoHow is that different from adding yet another JSX tag which leads to another JSX tag which leads to even worse "I don't like reading this code."? I admit that the parens and braces mess causes significant readability issues (though less than the tag soup). E.g. coffeescript gets rid of this problem very elegantly. But, when coffeescript is discussed, it's "syntax doesn't matter, just use ES6" but when it's JSX, syntax is crucial. It's sunken cost fallacy, Stockholm syndrome and FUD.
- boredtofears 2y agoPersonally I think "tag soup" (or, what I'd call a well structured XML document) is much easier to read than a deeply nested or scattered set of function calls.
- jampekka 2y agoOr you're just used to it. We get quickly used to e.g. our own body odor or halitosis so well that we can't smell it at all.
- boredtofears 2y agoOf course. Isn’t that the case with any code?
- jampekka 2y agoOf course. But I sometimes try to smell some fresh air to check what I've gotten used to.
- rvense 2y ago
- ttfkam 2y agoI'm still laughing about the fact that JSX renders to XHTML, not the HTML5 that browsers actually use. 99% of the time they're the same and parsing occurs as expected. That last 1%, things get weird quick.
- recursive 2y agoJsx doesn't "render to xhtml". Its syntax is similar to XML, but not the same. It's similar to HTML, but not the same. It's similar to XHTML, but not the same. In most react apps it renders to function calls like createElement or _jsx. The reconcile will turn these into DOM objects without any markup representation at all.
- ttfkam 2y agoDo you have to close all of your tags? Yes. Is the markup based on HTML with XML rules like closing tags? Yes. Do you even have to close the tags of your custom components? Yes. When generating your createElement sequence from JSX, does it create or close tags in a different order/hierarchy than what you specified in the JSX? No. Does it emit markup or element creation calls that match the parsing behavior of HTML5? No. Walks like an XHTML duck. Talks like an XHTML duck. It's an XHTML duck despite the JS interop and the lack of DTD preamble.
- recursive 2y agoDoes not have namespaces (in react), CDATA, schemas, and more. And none of this is "rendering".
- deleted 2y ago[deleted]
- ttfkam 2y agoThe "reconcile" (my God do geeks love making what they do sound fancier than it is) does not match the HTML5 parser "reconciliation" spec. The DOM element API "emissions" match the order triggered by the markup parsers. Y'all are tiresome sometimes.
- BalinKing 2y agoI must make a confession: I've honestly never understood why JSX is considered hackier than, say, template literal based HTM (or especially the bespoke pseudo-HTML you find in frameworks like Vue, which has always felt to me like the worst of all worlds). Is there a concrete reason I'm missing, or is it just a matter of taste?
- jampekka 2y agoI think it's having to extend the syntax so dramatically and bring new semantics to the language (actually a new language) and necessicating an extra complilation step for dubious payoff. It makes the language substantially more complicated, with additional corner cases (e.g. className and htmlFor). For what I see as solely matter of (bad) taste (being used to XML syntax for defining elements, and abhorring extra backticks?). The pseudo-HTML is not far from JSX in the hackiness, but at least it's embedded in HTML.
- WorldMaker 2y agoJSX as a syntax itself doesn't require `className` and `htmlFor`, it can support `<div class="example"><label for="someInput">Hello World</label></div>` just fine syntactically, that React API choice is a leak from the standard DOM API which use `className` and `htmlFor` for historic reasons (of bad parsers and stricter keyword parsing in earlier JS standards). In theory by using the DOM names React has less work to do when diffing DOM elements (though how much React actually benefits from it today is an interesting discussion). (Possibly relevant source/proof: my TSX-based library supports the HTML shortcut names just fine, like: `class`: https://github.com/WorldMaker/butterfloat/blob/cb9498354a7fb5954993086877e5bb9cfe781811/static-dom.test.tsx#L23 https://github.com/WorldMaker/butterfloat/blob/cb9498354a7fb... `for`: https://github.com/WorldMaker/butterfloat/blob/cb9498354a7fb5954993086877e5bb9cfe781811/static-dom.test.tsx#L59 https://github.com/WorldMaker/butterfloat/blob/cb9498354a7fb...)
- WorldMaker 2y ago> Where is jsx defined, as a language? https://facebook.github.io/jsx/ https://facebook.github.io/jsx/ is the primary home. > are there multiple transpiler implementations? Yes. Off the top of my head: Babel: https://babeljs.io/docs/babel-plugin-transform-react-jsx https://babeljs.io/docs/babel-plugin-transform-react-jsx Typescript: https://www.typescriptlang.org/docs/handbook/jsx.html https://www.typescriptlang.org/docs/handbook/jsx.html esbuild: https://esbuild.github.io/content-types/#jsx https://esbuild.github.io/content-types/#jsx > is it standardized at all? In terms of well documented, yes. In terms of a TC-39 standard accepted as a part of JS and intended for browsers to consume? No. Unless you count how much it borrows from E4X [0] which was an optional part of the "lost version" of JS that was EcmaScript 4, then "sort of". [0] https://en.wikipedia.org/wiki/ECMAScript_for_XML https://en.wikipedia.org/wiki/ECMAScript_for_XML
- Waterluvian 2y agoThe thing I'm struggling with as I read the official documentation and various blogs is exactly how this changes the developer experience. 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?
- Srfrogs 2y agoAs I understood you will not need to use it anymore since that's automatically it's handled by this new layer. that's one of the const he mention on the blog, will be difficult to debug because that will happen under the hood.
- meiraleal 2y agoFor almost 10 years, the core react developers would repeat incessantly: React is a library, not a framework. 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. I'm wondering if that was actually the reason they pivoted to this Frankstein? The loss of relevance as a frontend library. 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.
- tuyiown 2y ago> advising every Junior Developer to not make the mistake of choosing React I don't like react much, but I surely hope you advise them on ways to organise state management and rendering with good ways to track event listeners.
- naught0 2y agoReact is the premier frontend framework because it is easy to learn, scales ad infinitum, and has reached a critical mass where the library support is second to none. Anyone advising juniors against learning React is shooting them in both feet, not least because of the demand for React developers.
- ttfkam 2y agoLearn JavaScript first, then React. Far too many devs know the React APIs without any context. If you know JS/TS, any framework is learnable. If you don't, your React code will never improve past mediocre and bloated. Strong foundational knowledge in HTML and CSS helps as well. Still amazes me how many folks put onclick handlers on div tags and freak out when margins collapse.
- TonyAlicea10 2y agoFundamentals before frameworks. I've been a tech educator for a decade now, and still see this so much.
- BigJono 2y agoWhat am I missing? You gave two examples: 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? 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. 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. 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.
- ramesh31 2y ago>It looks to me like we're just throwing that all in the bin for absolutely fuck all. Welcome to the last 5 years of React development. React was "finished" with 17, but it's now a zombie project being filled with increasingly absurd feature sets serving as a promotion tool for bored Meta devs.
- meiraleal 2y agoFor me the start of the decline was actually React 16.8 with hooks.
- a_wild_dandan 2y agoNo accounting for taste, I suppose. For me, hooks were when React got amazing.
- ttfkam 2y agoNo accounting for taste, I suppose. For me, class components were absolutely horrid and hooks simply made it less horrid by comparison. I guess anything can seem amazing after you've been stuck in knee-deep mud.
- rhapsodic 2y ago[dead]
- whalesalad 2y agoI 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.
- draw_down 2y ago[dead]
- cageface 2y agoAll the leading frameworks these days include their own compiler. This is just React catching up and eliminating a lot of the tedious and error prone dependency tracking you have to do by hand now with a tool that does it for you.
- _fat_santa 2y agoI would have to respectfully disagree. React Hooks was probably the last "big" update to React and it totally changed how you build an application. The issue with hooks is you had hooks like useEffect that has very clear footguns that most seasoned developers knew but new developers would step on over and over and you also had optimization strategies with useMemo that weren't well known unless you've been around react for a while. Thing is with both of these is they can be automated with a compiler rather than having devs optimize it manually. My code has a ton of useMemo's and those micro optimizations and I estimate I can eliminate about 10k LOC assuming the react compiler does what it's advertised to do.
- PaulHoule 2y agoContrary to what a lot of people say, useMemo is more than a performance optimization. If React decides to create a new instance of a component because it thinks a parameter change happened all the state in that component can get dumped which can have effects like a bunch of selections in a combo box disappearing.
- SebastianKra 2y ago
- rixtox 2y agoI 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. 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. [1]: https://youtu.be/7GcrT0SBSnI https://youtu.be/7GcrT0SBSnI [2]: https://effect.website/ https://effect.website/ [3]: https://frontside.com/effection/ https://frontside.com/effection/
- eiriklv 2y agoIn Rick voice: Well, that just sounds like generators with extra steps..
- namaria 2y agoThis is a Morty line...
- eiriklv 2y agoI feel like redux-saga [0] also belongs on that list of algebraic effects - at least as an honorable mention. [0]: https://redux-saga.js.org/ https://redux-saga.js.org/
- a_wild_dandan 2y agoI 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). 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.
- azangru 2y agoSame would be true for: - Preact (like react, but tiny) - Solid (like react, but tiny and without the stupid re-rendering, or the stupid rules of hooks) - Lit (like react; but tiny, based on the browser-native web components, and with a class-based api) Considering that React has a virtual dom, a separate templating language (jsx), and now also a compiler, I would not call it simple.
- mock-possum 2y agoGod I love Lit. I wish more outfits were running it, templating in ‘lit-html’ is such a good experience.
- smarkov 2y ago> Declaratively describe your UI, React paints it. That's it. No app state management. "that's it" does not paint the full picture. Yes, UI = function(state) is very convenient but the way React implements it inverts the problem. Now instead of having to figure out ways of updating everything you have to go through numerous hoops to get only the things you need to update.
- willsmith72 2y agoNo, you don't. React does.
- vbezhenar 2y agoI used to think that React is awesome, but this has gone too far. They just don't care about JavaScript. 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. 2. They didn't adopt async/await, inventing their own suspend stuff. 3. Now this: they just convert the source language into something else. 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. The stateless render function is good. Emit desired-state, let framework to reconcile current state to desired state. But rest of React is not gold.
- pininja 2y agoIs Preact a fine alternative if all you’re after is JSX and declarative UI?
- Maxatar 2y agoPreact is an excellent alternative to React that keeps things minimal, understandable, and fast.
- threatofrain 2y agoYou must be ready to build a lot yourself. As nontrivial as can be.
- PaulHoule 2y agoOne radical lightweight alternative to React is Svelte https://svelte.dev/ https://svelte.dev/ which is completely dependent on a compiler since it bakes in all of the updating logic at that stage. I haven't done big projects with it but for little projects I have been amazed at the speed and the small size of the bundles.
- robertoandred 2y ago
- robertoandred 2y agoNot sure what everyone is so upset about. Since when is code optimization a bad thing?
- TonyAlicea10 2y agoI’m the author of this blog post, very cool to have it here. 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. 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. You need strong fundamentals to understand how things work.
- willsmith72 2y agoI love how we're all talking about state management. Just use Remix. The database/url is your state. Messy state management in Client-Side react is a problem of the late 2010s
- throwAGIway 2y agoThe app I maintain is a complex analysis tool that lets you build queries, explore data and create aggregate visualizations. The state doesn't even fit into URL, and connecting it to a DB... No thanks, that's be much harder and slower.
- willsmith72 2y agoWhat do you mean build queries and explore data, all on the client? I'm curious
- throwAGIway 2y agoYep, it can potentially download pretty big datasets and then you can explore them entirely client side using Wasm SQLite.
- deleted 2y ago[deleted]
- gepardi 2y agoI’ve worked with React, plenty of years. I haven’t had to touch it in months and don’t want to. Seeing JSX and reading about all the complexity in this post makes me hope I’ll never use React again. BTW I do like JavaScript.