Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React is winning by default and slowing innovation

lorenstew.art

Post reply on HN
Print view View original

61–70 of 866 posts

Re: React is winning by default and slowing innovation

#61

Post by webstrand »

skrebbel wrote: post #36
maelito wrote: post #11

Rewrite the first paragraph replacing "React" by "HTML". React is mostly HTML driven by data. "HTML killed front end innovation". Well that enabled standards to build real use cases on it with a common ground. Before React, the Web world was a mess. In 2025, you have lots of frameworks to explore. React did not kill front end innovation at all, it just became a standard that gives more common understanding to buildin…

> React is mostly HTML driven by data. I wish! Mostly though, React is a terrible mess of hooks with weird rules, suspense, “use client”, pedantic docs, and millions of other idiosyncrasies that have no business being this mainstream. I think most people agree that the core ideas are great. Eg composable components, props, unidirectional data flow etc. There’s a reason that all other reasonably popular frontend frame…

I thought the way React did suspense was pretty elegant?

The component render function is pure, meaning you can re-render component without unwanted side-effects. So on encountering an unresolved promise, halt and throw the promise, then have the runtime catch the promise and re-execute the render when it resolves. I thought this was really an elegant way to introduce an asynchronous dependencies.

Re: React is winning by default and slowing innovation

#62

Post by webstrand »

scotty79 wrote: post #50
skrebbel wrote: post #40

Earlier quoted context omitted.

HN has a button exactly for that!

Which one? Maybe there should be "reply later" button that would keep the spot for your future comment so you don't lose track of it?

I sometimes use "favorite" for that.

Re: React is winning by default and slowing innovation

#63

Post by johnfn »

andy_ppp wrote: post #38
RussianCow wrote: post #29

Earlier quoted context omitted.

This. React was incredibly innovative at a time where the alternatives were some combination of: * Two-way data binding spaghetti * Boilerplate-heavy reactivity * Opaque, framework-specific magic * Manual state updates/transitions React didn't win "by default" (whatever that means), it won because it was better than most of the other options at the time. I agree that, on purely technical grounds, it isn't as strong o…

[flagged]

All framework code has magic in it. But I posit that React uses magic internally so that we can write magic-free code. It's like how the Rust compiler contains unsafe code.

Re: React is winning by default and slowing innovation

#64

Post by rimunroe »

RussianCow wrote: post #60
andy_ppp wrote: post #38

Earlier quoted context omitted.

[flagged]

React was actually pretty simple in the early days. It's gotten significantly more complex because of hooks, suspense, SSR, and other features they've introduced more recently. But I would still take modern React over AngularJS 1 and I think it's far more explicit.

The source code for hooks when they were initially released was actually really straightforward too. It's been many years since I've read through other parts of the source code though.

Re: React is winning by default and slowing innovation

#65

Post by notapenny »

kypro wrote: post #31

React's dominance is genuinely baffling to me, and even more so popularity of Next.js. In my experience React is rarely the best solution and adds a huge amount of complexity which is often completely unnecessary because React is rarely needed. In the early days my very controversial view was that frontend developers tend to be fairly mediocre developers, and this is why a lot of frontend frameworks suck and frontend…

For sure it isn't the perfect solution for everything, and I say that as someone who spends most of their time in either React or Angular now. For application-like development or just sites with tons of interaction it's become as standard as reaching for Spring or PSQL though.

I can't speak to the complexity you've encountered, but for me it's pretty much zero. A button component is just a function. React-Router is good enough and code splitting is pretty much just changing how to import something. Component state is dead-easy to write by just adding a useState hook. Bundlers pretty much handle everything these days so not to much concern about size.

Your view on front-end developers having been mediocre in the past isn't far off though, at least in my experience. I noticed a big difference between the people who wanted to build nice looking pages and the ones that wanted to build applications myself. Even today it amazes me how many people have never unit tested their code, have no idea about layering an application and have poor JS/TS fundamentals. It's gotten a lot better though.

Ultimately it isn't perfect for everything, but for a lot of people it's an easy choice. And for me personally, the tons of other JS frameworks do very little in that area that I'd pick them. I'd rather spend my time working on the product. Lol, maybe its just the default because its the default at this point.

Re: React is winning by default and slowing innovation

#66

Post by ZpJuUuNaQ5 »

>Killing Front End Innovation

Huh, I wish. This is loosely related, but early in my career I worked in a company where one of the projects I was involved in was a relatively large-scale web platform. The system had quite a lot of interactive UI elements, but for some reason we weren't allowed to use any off-the-shelf UI library/framework like React (it was already around for quite some time), despite presenting arguments countless times on why it would be the better solution and save a huge amount of time.

Instead, we had to use a buggy and incomplete UI library that was built within the company, and the results were as you'd expect. Making changes to the UI was agonizing, the library's behavior and API was inconsistent, components were difficult to reuse, and you had to jump through hoops and monkey-patched nonsense to update the UI. On top of that, nobody worked on fixing the library itself, and eventually the system using it grew so large that making any fixes to the library would break the system and would need a massive amount of time to fix or rewrite all the broken components. The saddest thing was that the UI library itself did not actually do anything "innovative", just some things that are available in countless other UI libraries, but worse.

Sure, maybe it was my technical incompetence and poor decisions, but on the other hand, even then, I knew JS/TS quite well and wasn't one of those people who swear by a particular framework and know nothing else. I worked on other web-based projects before with various technologies and never had that many problems.

Re: React is winning by default and slowing innovation

#67

Post by pverheggen »

CharlieDigital wrote: post #49
maelito wrote: post #11

Rewrite the first paragraph replacing "React" by "HTML". React is mostly HTML driven by data. "HTML killed front end innovation". Well that enabled standards to build real use cases on it with a common ground. Before React, the Web world was a mess. In 2025, you have lots of frameworks to explore. React did not kill front end innovation at all, it just became a standard that gives more common understanding to buildin…

Actually, React's problem is that it's the inverse of how HTML and JavaScript works in terms of how to handle callbacks. Of the major UI frameworks, it is the only one with this quality (Vue, Svelte, Angular, Solid, etc. use signals). This inverted behavior is the cause of most of the pain and footguns in React and React Hooks because the way state behaves in a React component is not the way state behaves in any othe…

Technically in React, the reactive callback is still the event handler. It's a two-step process where your event handler is evaluated first, then re-evaluates the component tree which changed as a result of the handler. In your JSFiddle example, if you modify `onChange` to print a console log instead of setting state, you'll see that it doesn't run the component function again.

So really, the key difference between React and Vue is that your function component is not the setup, it's the template.

Re: React is winning by default and slowing innovation

#68

Post by AstroBen »

andy_ppp wrote: post #38
RussianCow wrote: post #29

Earlier quoted context omitted.

This. React was incredibly innovative at a time where the alternatives were some combination of: * Two-way data binding spaghetti * Boilerplate-heavy reactivity * Opaque, framework-specific magic * Manual state updates/transitions React didn't win "by default" (whatever that means), it won because it was better than most of the other options at the time. I agree that, on purely technical grounds, it isn't as strong o…

[flagged]

Yeah, that's where the complexity is supposed to be

Re: React is winning by default and slowing innovation

#69

Post by skrebbel »

rimunroe wrote: post #58
skrebbel wrote: post #36

Earlier quoted context omitted.

> React is mostly HTML driven by data. I wish! Mostly though, React is a terrible mess of hooks with weird rules, suspense, “use client”, pedantic docs, and millions of other idiosyncrasies that have no business being this mainstream. I think most people agree that the core ideas are great. Eg composable components, props, unidirectional data flow etc. There’s a reason that all other reasonably popular frontend frame…

> pedantic docs Are you referring to something in particular here? I've had my issues with the docs in the past, but I don't think I'd describe any of them being related to pedantry.

Yeah stuff like useEffect which is supposedly a function that "lets you synchronize a component with an external system" [0]

So eg when you want to focus an input, how do you do that? That's the input itself right, that's my core UI, that's not synchronizing, it's not an external system so I'm not supposed to use useEffect for that, right? That'd be bad, no?

Turns out I do need useEffect, and in fact it's the only way, barring using 3rd party hooks or components that, themselves, use useEffect for this. And the idea is (I assume?) that the DOM is the external system! This absolutely bonkers! The DOM is my app! That's not an external system at all. It's as non-external as things can get and I'm not synchronizing anything, I'm focusing an input.

This entire "external system" story isn't at all about what useEffect is, it's not what it does, it's merely what the React designers have decided you should use it for.

useEffect lets you run side effects. That's it, that's all there is to it. But they rewrote the docs with total beginners in mind, and put them so full of dos and donts that they forgot to explain what stuff actually does. Gaaah.

And half the documentation is like this. It dances around the actual behavior, never really explicitly saying what things do or how they work, with huge rants about what I ought to do and no info, except maaayybe hidden in some expando, about how things actually work and why.

[0] https://react.dev/reference/react/useEffect

Re: React is winning by default and slowing innovation

#70

Post by rimunroe »

skrebbel wrote: post #69
rimunroe wrote: post #58

Earlier quoted context omitted.

> pedantic docs Are you referring to something in particular here? I've had my issues with the docs in the past, but I don't think I'd describe any of them being related to pedantry.

Yeah stuff like useEffect which is supposedly a function that "lets you synchronize a component with an external system" [0] So eg when you want to focus an input, how do you do that? That's the input itself right, that's my core UI, that's not synchronizing, it's not an external system so I'm not supposed to use useEffect for that, right? That'd be bad, no? Turns out I do need useEffect, and in fact it's the only wa…

What's the condition in which you're trying to focus that input? Usually you're doing that in response to some sort of user action, in which case the time to handle that is within an event handler.

> And the idea is (I assume?) that the DOM is the external system! This absolutely bonkers! The DOM is my app!

External systems usually means stuff like an event system, network requests, or something else not managed directly by React. Unless you're reaching outside the area of the DOM React is managing, you can usually do this in event handlers or (for spookier cases) ref callbacks. There are certainly exceptions, but it's often an architectural smell.

Further down in the docs you'll see[0]:

> Effects are an “escape hatch”: you use them when you need to “step outside React” and when there is no better built-in solution for your use case.

[0] https://react.dev/reference/react/useEffect#wrapping-effects...

Post reply on HN