Live data from Hacker News

React is winning by default and slowing innovation

lorenstew.art

731–740 of 866 posts

Re: React is winning by default and slowing innovation

#731
post #472

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. In Svelte you are writing XML with little JavaScript islands inside it. Instead of if you get `{#if}{:else}{/if}`. Thats not "ergonomic" – thats a mini-language stapled on…

> 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.

Re: React is winning by default and slowing innovation

#732

Earlier quoted context omitted.

Hooks are magic syntax without any doubt. All magic syntax is made up of non-magic parts, that's kinda the point. The way you know it's magic is it shatters the principle of referential identity, which tells you that a variable is itself. It pretends you can use a simpler mental model but you really cannot and must not.

Hooks aren't magic syntax. The problem with hooks has nothing to do with syntax. The problem is that the React crowd has decided to overload the meaning of a term that has had a reasonably solid interpretation (at least in comparison to the React crowd). "React Functional Components" have nothing to do with conventional functional programming. They inherently (intentionally?) violate the spirit of functional programm…

> They are not functional, they are merely functions.

Functional literally means dealing with functions composition.

Free of side effect is not a property of functional programming. Ocaml is functional and has side effects.

Re: React is winning by default and slowing innovation

#733
post #472

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. In Svelte you are writing XML with little JavaScript islands inside it. Instead of if you get `{#if}{:else}{/if}`. Thats not "ergonomic" – thats a mini-language stapled on…

HTMX is the antidote to React and is allowing many green shoots to show through - my favourite is https://harcstack.org … but there are many alternates in many server side languages (disclosure: i am the author)

Re: React is winning by default and slowing innovation

#734
post #515

Earlier quoted context omitted.

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

Nitpick: 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-doe...

All 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.

Re: React is winning by default and slowing innovation

#735
post #649

Earlier quoted context omitted.

If 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…

You 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.

I've spent more hours using rakes than `useEffect()`, but I've only had the problem with one of them.

Re: React is winning by default and slowing innovation

#736

Earlier quoted context omitted.

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.…

I can’t recall a single time where I would want to put JSX in an „if” statement.. In fact I can’t recall a single time where I would want to use JSX in a different context than the return value of a render phase. So from my personal experience the things you mentioned are non-issues in practice. Do you have a different experience?

yes

Re: React is winning by default and slowing innovation

#737
post #428

> Hooks addressed class component pain but introduced new kinds of complexity: dependency arrays, stale closures, and misused effects. Even React’s own docs emphasize restraint: “You Might Not Need an Effect”. Server Components improve time-to-first-byte, but add architectural complexity and new failure modes. There are a lot of valid criticisms of React, but I don't think this is one of them. These problems are not…

Disagree. Hooks took one problem and reshaped it, they didn’t actually solve the problem. With hooks you still need to think about lifecycle, side effects, and state, but the syntax changes. The real solution is overall application design and thinking through architecture, but unfortunately that’s higher effort than “just use hooks bro”.

I'm not sure why you think you're disagreeing as my entire comment was explicitly about how the issues people blame on hooks existed before, but that hooks changed how they were presented/encountered. I literally began it with: "These problems are not really new with hooks. They're actually problems which existed in some form in the class component API."

As the rest of my comment points out, the thing hooks did was make these issues more tractable by reducing the places it was possible to make them. Instead of worrying about which logic is needed between the constructor and over eight lifecycle methods (the number of these was reduced over time of course) for your components, you just have to ask "what does this effect depend on?", "What should it do?", and "how should it clean up after itself?".

This reduces the number of places it's possible for bugs to appear but you can still make them. I believe people blame things on hooks because it forces them to confront those (often extremely subtle and hard to catch until it's too late) bugs earlier by putting them front and center, especially with a lint rule. This is good.

In addition to all that, we also got two major other advantages: sharing of logic/composability and making code using hooks much more minifiable than class components (unlike functions, object properties can't be mangled/shortened by minifiers). Plus we get a vastly improved DX because of fast refresh, which is an excellent bonus.

Re: React is winning by default and slowing innovation

#738
post #472

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. In Svelte you are writing XML with little JavaScript islands inside it. Instead of if you get `{#if}{:else}{/if}`. Thats not "ergonomic" – thats a mini-language stapled on…

HTMX is the antidote to React and is allowing many green shoots to show through - my favourite is https://harcstack.org … but there are many alternates in many server side languages (disclosure: i am the author)

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.

Re: React is winning by default and slowing innovation

#739
post #438

React isn't winning by default. It's been so effective, so well designed that it's lived long enough to become the defacto standard... and the villian. Claiming React is slowing innovation is an absolutely bonkers take when React is essentially the only sane stable choice in a sea of "me too" frameworks and libraries with conflicting and confusing design choices.

Also react in particular in combination with tailwind seems to be easier for LLMs to generate. Probably due to the condensed syntax, no split between code, css and html, plus the color naming scheme of tailwind.

I'm terrible at CSS and have been generating HTML/CSS prototypes with Claude. It really knows how to push out tailwind.

Re: React is winning by default and slowing innovation

#740

Earlier quoted context omitted.

I don't really recommend isomorphic environments, but if it's your cup of tea, Tanstack Start is making a lot of progress. It removes all of the magic and misdirection of Nextjs and just provides a good light alternative.

AFAIK "TanStack" doesn't support RSCs? That's a deal breaker for me. Also the guy named his framework after himself, it can't be good.

What do you get from RSCs that you don't get from creating a proper backend?
Post reply on HN