4 ms·
JSX is just a syntax extension to JS, and it's not even required to create a React app. React "compiler" is in fact a transpiler, which is a very common thing
by gloosx 1y ago
JSX is just a syntax extension to JS, and it's not even required to create a React app.
React "compiler" is in fact a transpiler, which is a very common thing in JS.
>React is full of magic syntax that looks like functions
Full of magic syntax meaning 5 straightforward hooks? Surely they are not true free-form JavaScript, but at least the syntax itself is not turned into a DSL
- sensanaty 1y ago> 5 straightforward hooks `useEffect` is straightforward? Cloudflare recently (like, literally 4 days ago)[1] had a pretty big outage because of the improper use of `useEffect` (surprise, surprise, it was the dependency array), a hook so infamous if you search "When should I use `useEffect`" you'll get approximately 9 trillion hits, with nearly all of them telling you something different, including Dan Abramov himself having to chip in with multiple blog posts telling people to NOT use it because of how much of a dumpster fire of a API it is. [1] https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-12-dashboard-and-api-outage/ https://blog.cloudflare.com/deep-dive-into-cloudflares-sept-...
- gloosx 1y agoWell, that is really embarrassing for Cloudflare... A recursion in a side-effect via dependencies is a rookie mistake, it's hard to imagine it could slip into production with a proper due process. Maybe they should stop vibe-coding and deploying things to production without any tests or review?
- sensanaty 1y agoIf after nearly a decade swarms of people are still making the exact same mistakes with how they use a specific method exposed by the library, then the problem isn't with the hundreds/thousands of people making the mistake, the design of the method is broken. This type of issue simply does not exist in Vue or Svelte even if people abuse watchers (which I've anecdotally noticed tends to happen from React devs writing Vue code). Also I just want to point out again that Dan Abramov had to write an insanely long guide to using useEffect [1]. This piece is around 10k words explaining in-depth how useEffect works. That is insane for one of the fundamental, core methods exposed by a library. [1] https://overreacted.io/a-complete-guide-to-useeffect/ https://overreacted.io/a-complete-guide-to-useeffect/
- deleted 1y ago[deleted]
- gloosx 1y agoYou know for thousands of years people are still stepping on rake, the spikey part. And they get hit in their foreheads. The rake is lever by design, but I wouldn't say the problem is the rake.
- deleted 1y ago[deleted]
- WickyNilliams 1y agoDisagree about it being a rookie mistake. In the simple case, yes. But consider data used by an effect could travel all the way from root to the max depth of your tree with any component along the way modifying it, potentially introducing unstable references. Maybe it worked when you tested. But later someone introduced a new component anywhere between data source and effect which modified the data before passing it on. That component may have used useMemo. So it looks ok, but it over fires. You become reliant on all your ancestors doing the right thing, in every situation, forevermore. One mistake and unstable references cascade everywhere. The surface for introducing errors is huge, esp in a large, complex codebase. And we have no way to guarantee a stable reference.
- gloosx 1y ago>But consider data modified This is why we never modify data but create new data. Data must be immutable. Strictly typed. Always in the form it is expected to be. Otherwise - crash immediatelly. >But later someone introduced This is why we write integration tests. Introducing anything without tests is only guesswork.
- WickyNilliams 1y agoSorry I should have been more precise. I don't mean mutation, but taking the data and producing a new (potentially unstable) reference to pass on. Mutating data in react results in under not over firing. It is practically impossible to have full coverage of all code paths in integration tests, since there is a combinatorial explosion of paths. In a case where you have 3 components each with 3 paths you have 27 unique paths. And no app is that simple in practice. It gets out of hand quickly.
- deleted 1y ago[deleted]
- TomaszZielinski 1y agoAs a rookie with gray hair I completely agree :)
- patates 1y agoJavascript has warts, React has warts, Svelte has warts, Python has warts... It's easy to shoot yourself in the foot in any tech - it's leaky abstractions all the way down after all. useEffect usage needs to die, yes. I don't think it's a case against React, given its age. Otherwise, using React is straightforward. I started coding in it without reading any docs. As someone who used Dojo, prototype, ext.js, jQuery (+UI), Backbone.js, knockout (still has a special place), Mithril, the classic angular, vue (2), svelte, Marko and even Solid (I'm not totally sold on signals), React is the most straightforward by a mile. Is it the most performant? Hell no. Is it the one with the least gotchas/warts? Nope. Concise? A giant no. Batteries included? It depends on what you're looking for... But I can just be productive with it, and it makes sense.
- thedelanyo 1y agoA child who hasn't tasted other mom's food always say, my mom is the best cook in the world. You saying you can be productive in react is just ironic. I just read it as, I can be employable using React.
- patates 1y agoMy brain does this sometimes, sorry :) I meant to say, "I can just be productive immediately in React". Not going to edit though. edit: also about the moms cooking analogy... With many of those libs/frameworks, I have much more experience with than react.
- thedelanyo 1y agoYou like jokes
- TrnsltLife 1y agoWe need to determine which framework is most productive while suffering from Mommy brain.
- sfn42 1y agoBro lists like 8 different moms whose food he has, then says he likes react-moms food, and you make it sound like that's the only thing he's ever had. Did you even read the comment you replied to?
- patates 1y agoNitpick: React compiler is not a transpiler. JSX needs to be transpiled, and that's usually done by TS compiler. React compiler is another optional thing on top that's relatively very recent. https://react.dev/learn/react-compiler/introduction#what-does-react-compiler-do https://react.dev/learn/react-compiler/introduction#what-doe...
- recursive 1y agoAll compilers translate one language to another language. Historically compilers targeted lower-abstraction languages than the source language. "Transpiler" is a compiler whose input and output abstraction levels are similar. The React cinematic universe has a habit of repurposing existing terminology, but they're both transpilers, to the extent that "transpiler" is even a word.
- patates 1y agoYou are absolutely right! (Here I'm roleplaying an AI chat bot which caught red handed hallucinating). It appears that I was wrong about the definition of transpilation. It's a specific term for a compiler that compiles from a high-level language to another high-level language, even when those languages are the same with no DSL and even when the logic is optimized. I stand corrected.
- hajile 1y agoIn JS land, transpile was used to distinguish something like elm->JS from ES6->ES3. One was the same language with different versions and the other was different source languages. Yes, all transpilers are compilers, but not all compilers are transpilers.