12 ms·

React isn’t just "winning by default" It's winning because at the core it's just JavaScript function composition. A component is a function, conditionals are `i

• thedelanyo 1y ago
  Sure this is js <> // React code here <>
  • zarzavat 1y ago
    react.createElement(react.Fragment, /* React code here */)
• nsonha 1y ago
  > winning because at the core it's just JavaScript function composition and now it's failing for the same exact reason, a pseudo "just js function" dsl (hooks) and all the magics enabled by special "compilers" and toolchain.
• mike_hearn 1y ago
  So JSX is pure Javascript and not, say, a dialect of XML embedded in JS? Because it sure looks like the former even though it compiles to the latter. React isn't Javascript. It's a franken-language that looks superficially like a mix of JavaScript and XML whilst following the rules of neither. That's why there is such a thing as a React compiler - a good sign that you're not writing JS, which doesn't have compilers. The other hint should be all the new rules you have to follow. React is full of magic syntax that looks like functions, but e.g. you can't call them inside an if statement, or you have to redundantly declare the 'dependencies' (variables you read) and so on. The semantics of React code are very different to imperative straight line code.
  • zero_shift 1y ago
    > So JSX is pure Javascript and not, say, a dialect of XML embedded in JS? It would be best to think of it as syntax sugar for create Element() function calls. You enter JSX with angle tags and insert expressions in braces > React is full of magic syntax that looks like functions, but e.g. you can't call them inside an if statement, or you have to redundantly declare the 'dependencies' (variables you read) and so on That's not magic syntax. That's just functions that must be processed in regular order between render ticks. It's not a difficult exercise to write a "plain JS" function that works that way. If you've worked much with closures you can visualise how that would play out.
    • burnerzzzzz 1y ago
      > It would be best to think of it as syntax sugar for create Element() function calls Thats what makes it a new language. C is just sugar on top of assembly. Its so strange that jsx needs a buildstep, but misses ton of obvious ergonomics that one could have added. Why className instead of class? With a buildstep, it would surely be possible to determine if class was a keyword or not based on context
      • zero_shift 1y ago
        > Thats what makes it a new language. C is just sugar on top of assembly. I think that's a bad example. C isn't a sugar for assembly: For example what assembly code does a function prototype desugar into? Sugars have 1:1 mappings with host code Maybe you're just being rhetorical about the spectrum of macros, sugars, and languages, though. (In my opinion, a better target for that criticism, in JS land, is the Jest test framework, because of all the reordering magic it does that break fundamental ES semantics) > Why className instead of class? This hasn't been a constraint since... I want to say React 18, six or seven years ago? I might be misremembering the history but I think that was only a problem in the Early Days when there was paranoia about whether JSX needed to be conservative with reserved keywords
      • rafaelmn 1y ago
        Syntax sugar is language syntax that improves a common pattern from the language (making it sweater). jsx, async/await - things that just abstract common patterns.
• WickyNilliams 1y ago
  Hooks are very much not normal functions though. They are a new "colour" of function much like async functions - they can only be called in components or other hooks, they cannot be called conditionally, cannot be called in loops etc. The so-called "rules of hooks" (To get ahead of the common objection: of course it's still JavaScript by virtue of being implemented in JavaScript. But so are Svelte, Vue et all)
  • gloosx 1y ago
    Surely they are not normal JavaScript functions, but at least the syntax itself is not turned into a DSL like we see it in Svelte or Vue. That is the main difference.
    • WickyNilliams 1y ago
      Yeah I get it. I don't think the "Just JavaScript" label can be applied to react anymore. It held in a class-based world. But it's not true post hooks. I always hated templating languages > Greenspun's {{rules.length | ordinal}} rule: > Any sufficiently complicated templating language contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of the host language But after working with Vue for a 18 months and expecting to hate it, I actually very much enjoyed it. The biggest downside is strictly one component per file. Edit: in case I've come across as some kind of react hater, I was an early adopter and still use it professionally to this day
      • sensanaty 1y ago
        > Any sufficiently complicated templating language contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of the host language Agreed, and Vue does it right exactly because they don't let you do complex things in the template. You can use ternaries in a pinch, but `computed`s exist so there isn't even a reason to do stuff like that. There's like... 10? directives that you can use and they are extremely obvious as to what they're doing, and the handlebar syntax itself is extremely limited and doesn't let you do any crazy stuff with it.
• KuhlMensch 1y ago
  Hard agree. I've used xml directives before, all the way back to Macromedia Flex (which I believe borrowed form something in the Java space, which probably borrowed from something else). I'll likely NEVER use anything that doesn't let me run JSX. My personal preference is for complexity at the start of the render pipeline (e.g. in state) or at the end (e.g, in JSX). So I personally dislike complex hooks composition, but I can live with it. (My) teams seem to like it. I'd rather have boilerplate of redux, or redux sagas - or a S.O.L.I.D framework + scaffolding tools, and turn the composition of logic part of my brain off. But the context switch to maintaining scaffolding tools is perhaps a bit of a jump. As an aside: I'm shocked to see Yeoman largely diminished in activity, and Hygen (https://github.com/jondot/hygen https://github.com/jondot/hygen) not getting anywhere near enough love as it deserves etc. Perhaps there is some, first-class macro or meta programming or combination of the two that is missing. Or maybe its hard to invest in tools you can't necessarily take from job to job - as scaffolding tools are capturing opinion.
  • mexicocitinluez 1y ago
    When I first saw JSX, I immediately thought I'd hate it. Then I jumped boat to React after years with AngularJs/Angular 2+ after hooks and functional components came in and to this day I still enjoy writing React. And I love JSx.
• sensanaty 1y ago
  Sorry, but I'll take Vue's or Svelte's (I prefer Vue's) DSLs over shit like `className` or sticking complex rendering logic in the HTML/template with unreadable `.map`s or God forbid nested ternaries, which is not a rare sight in React codebases. For my brain, seeing a bunch of `v-for`s is a lot clearer as to what's going to ultimately render than seeing a bunch of `map`s is going to render. Also calling it "just JavaScript" might've been true in the Class component days, but in this frankenstein "functional" component paradigm we're at today it's far from the truth. I mean, it's not even a JS file, it's a JSX file for starters. At the end of the day the whole JSX vs HTML-DSL thing comes down to a personal preference, and I doubt it's had much to contribute in terms of the success of the various frameworks. I know plenty of people working with React that despise JSX, and I know plenty of people working happily with Vue or Svelte that hate the DSL for templates.
• simianwords 1y ago
  Clear difference between a library approach and a framework approach. react looks like a library but svelte and tbh angular also look like a framework. As devs we are more comfortable with libraries unless framework offers enough value.
• baxuz 1y ago
  > It's winning because at the core it's just JavaScript function composition. Except it's not. It has a bunch of footguns and implicit behaviours that make no sense unless you're well-versed in the internals of React. See: https://macwright.com/2024/09/19/the-extra-rules-of-hooks https://macwright.com/2024/09/19/the-extra-rules-of-hooks https://www.schiener.io/2024-03-03/react-closures https://www.schiener.io/2024-03-03/react-closures And JSX by itself is already a DSL, which drastically changes how it works based on the pragma used. JSX for SolidJS, Preact, Inferno or any other framework has completely different internals.
• ojr 1y ago
  Thats why it won over the more popular Angular 1 at the time. Angular was introducing directives as a new way to handle dependencies, React chose to stay close to the new ES6 syntax with imports, of course I was going to chose the language that was closer to ES6. I have a feeling React will be closer to the EcmaScript/Javascript standard than Svelte in the future as well ES7/ES8/ES9. Also React Native and React is very easy with LLMs. I am able to build cross platform apps with feature parity which is important because some of us need to make programs for the most popular form factor, mobile, instead of a desktop website.
• magnio 1y ago
  Man, I am glad I don't have to work with any developers for whom having to write "className" (which has been in the DOM standard since 2000) over "class" is a deal-breaker.
  • WorldMaker 1y ago
    To be fair though, that's not a JSX restriction, that's a React choice. (In my own JSX-based library, I allow `class="thing"` and `for="some-id"` just fine as simple synonyms of className and htmlFor.)
• mvdtnz 1y ago
  I feel like you must have learned JavaScript and React concurrently to have a belief like this.
  • gloosx 1y ago
    Nah, I started with vanilla, then jQuery, then finally learned React.
• vbezhenar 1y ago
  It looks like simple JavaScript. However hooks are magic, so it's no longer simple JavaScript with simple mental model. It's completely different language.
• mattgreenrocks 1y ago
  Please. Let’s get real about the biggest issue with Svelte/Vue/Solid: it wasn’t written by Meta, and had no chance at the clout game that is essential for mindshare. (Not saying React is bad, just that DSLs impeding adoption rings hollow in light of Tailwind/JSX.)
  • paulryanrogers 1y ago
    Doesn't Meta also use Vue?
    • mattgreenrocks 1y ago
      It’s about marketing, not internal use.
      • deleted 1y ago
        [deleted]
• faangguyindia 1y ago
  off topic but react code is hard for LLM to edit for some reason compared to other like VueJS
  • WorldMaker 1y ago
    I've found the opposite: LLMs have trained on so much React that they want to spit it out even in places where that doesn't make sense. It's been useful when working with my own JSX-based library that React output is often an okay first pass, and LLMs did help me iron out a few common React "idiom" compatibility needs that were missing.
• motorest 1y ago
  > React isn’t just "winning by default" It's winning because at the core it's just JavaScript function composition. A component is a function, conditionals are `if (...) { ... } else { ... }`, loops are `map()`. JSX is just sugar for function calls. I agree with JSX, and function components are nice, but React is most definitely not just function composition. Hooks add state and introduce life cycle events that take components way beyond stateless territory, to the point that it would be far easier to reason about them if they were class components with properties and decorators and handlers invocable through inversion of control.
  • cjonas 1y ago
    So basically react class components? It definitely was not easier in those days. When your just using vanilla react, I've never had a problem with hooks being that hard to reason about. Once you add in SSR, routers, query caching frameworks, etc the "lifecycle & state" starts to get confusing. This is mostly a problem with the additional complexity of these frameworks (nextjs, tanstack) and not react at its core. Building an app with just react (and maybe redux) feels so simple and natural once you learn the paradigm.
    • the_gipsy 1y ago
      But you cannot really develop anything meaningful without adding frameworks. I guess redux solves both "state" and "messages" at once, that's good. But what you work with then is not "vanilla react" at all. I don't even think "vanilla react" can really exist, beyond toy examples. You either use frameworks or write them yourself (worse).
      • cjonas 1y ago
        > But you cannot really develop anything meaningful without adding frameworks. You can develop extremely powerful web-apps using just React + Redux. Once you need to start dealing with SSR for SEO & server side caching, data preloading, hydration, etc... things get complex. But honestly that's because those concepts are inherently complex and that complexity can only be reduced so far. Another problem is they get baked into these framework as the "default" and often over utilized when they aren't actually needed.
• theknarf 1y ago
  Both SolidJs and Qwik keeps the JSX syntax!
• jmull 1y ago
  ...At a logical level,
• bobbylarrybobby 1y ago
  On the other hand, how do you write a function in a react component that retains its identity between renders (to pass as a prop to a child and not have the child re-render when it changes)? You can't — you need useCallback. Meanwhile in svelte you just... write a function. They each have their own quirks. Personally I'd rather write language specific if/else (obvious, can't get it wrong) than have to remember to reactify my functions if I want to avoid subtle performance issues.
• hbrn 1y ago
  > React feels natural because it never asks you to stop writing JavaScript I want to increment some counter on the webpage. Which approach feels natural? increment = () => { this.setState((prevState) => ({ count: prevState.count + 1 })); }; const increment = () => setCount((count) => count + 1); function increment() { count += 1; } No one wakes up saying "please let me mutate simple state with function calls".
  • b_e_n_t_o_n 1y ago
    The third example is missing the data binding that you get automatically with React. It should look more like this: function increment() { count += 1; dispatchEvent(new CustomEvent( "count-incremented", { detail: { count } } )); } I think I prefer not having to manage events all over the place.
    • hbrn 1y ago
      Third example was supposed to be Svelte. Vue also isn't too far: function increment() { count.value += 1 } In 2025, React state management is complete shitshow compared to Svelte and Vue. How in the world people are claiming "React is just Javascript" is beyond me.
  • 3nt3 1y ago
    Haskell devs do ;)
• JimmaDaRustla 1y ago
  I don't understand how this comment is the top, because it makes no sense. No one writing markup says "Damn, I wish I could write this inline with my javascript." Have you even seen a react component before? People writing javascript containing the markup which, in turn, contains more inline javascript statements for conditional rendering. No logical person would argue "this is better than {#if}{:else}{/if}".
• azangru 1y ago
  > React isn’t just "winning by default" It's winning because at the core it's just JavaScript function composition. This might be just a rationalization. React might be "winning" (whatever that means), because it was the first proper component-based library, when its competitors (Backbone, Angular, Ember) were large, slow, and clumsy, and still struggling with the concept. Plus, developers back then were easily impressed by the word "Facebook", which meant a large tech company that probably knew what it was doing, and served as a guarantee of good quality. So it had a tremendous head start and good marketing. If Vue, Svelte, Solid, or Lit were there first, who knows if React would be "winning" now.
• librasteve 1y ago
  HTMX is the antidote to React and is allowing many green shoots to show through - my favourite is https://harcstack.org https://harcstack.org … but there are many alternates in many server side languages (disclosure: i am the author)
  • CooCooCaCha 1y ago
    Looking at the example on the front page, I don’t see how you can look at that and think it’s better than react.
    • librasteve 1y ago
      I think that HTMX is better than React. I think that writing in my server side language of choice (Raku as it happens - ymmv) is better than TypeScript. If you want to write HTMX / HTML in a componenty and functional way then HARC stack gives you that for Raku. I grant that Raku is a step change if you haven't seen it before and that there are some awkwardnesses in the example that could be ironed out. You may prefer PyHAT, FastHTML (Python), HARM (Rust), GOTTH (Golang) and so on...
      • progmetaldev 1y ago
        I have been taking a deep-dive into Lit recently, because the CMS I use (Umbraco) has built their BackOffice (CMS management interface) in it. It has been fairly easy to grok, other than learning the CMS specific libraries. With that said, HTMX feels like the progressive enhancement solution I wish I had back when I was doing so with jQuery (and Prototype.JS even before that). I appreciate your solution, and definitely want to take a deeper look in the future. For applications, I still tend to use ASP.NET (Core, whatever you want to call the current open-source version of .NET). HTMX seems like a perfect solution to progressively enhance an application, while your library does far more for controlling how library code is written in JavaScript than a gigantic mess of jQuery scripts with shared state.
• stack_framer 1y ago
  > conditionals are `if (...) { ... } else { ... }` As long as you're not invoking a hook in those if/else blocks!