Live data from Hacker News

React is winning by default and slowing innovation

lorenstew.art

291–300 of 866 posts

Re: React is winning by default and slowing innovation

#291

Earlier quoted context omitted.

Frankly it's incredible what any of these frameworks have been able to accomplish given the bonkers platform they have to work on. HTML, CSS, and JS made sense back when the web was primarily text with some simple forms. It's a dog shit foundation to build highly interactive apps on. The whole thing needs to be thrown out and rebuilt.

Webapps were a mistake :(

The frustrating part is that the idea is incredible. Everyone has this piece of software on their computer that lets them run anything as long as there is a server to talk to. I love it. I don't want to have to download a thousand apps, especially not for shopping or banking. Just using a web interface is awesome.

Unfortunately we decided the correct way to provide the functionality was by layering bonkers ass abstractions on top of a system meant to largely display static text and images. In the year 2025 there is absolutely no reason we shouldn't have a unified coding language that allows you to render things in a web browser in a sane way.

At the very least we should have seen a substantial expansion of what HTML is capable of, closer to what HTMX is doing now, with a better way to style everything then fucking CSS. People complain about JavaScript but for my money CSS is the greatest sin.

Re: React is winning by default and slowing innovation

#294
post #102

React is winning because its really good. Even if the cost is an extra few milliseconds of render time and few extra hours of dev time figuring out things like hook dependencies. If React starts taking a backseat, it'll be because its no longer really good. And, to be fair: I've started to see this happen. Next & Vercel have totally taken over the React world, and they've proven to make quite poor architectural decis…

I'm not sure I'd say that React's DX is actually that great. I've watched C++ developers come over from using QT and the learning curve is massive. Plus almost all the bugs come from dealing with React's renders.

I think React by default is weird because most things don't actually need that degree of reactivity. Like, if most of the time only one thing is displaying or updating a value React just adds a lot of headache. And the amount of useEffect I see? (By necessity mind you) with the need for linters in order to figure out if you missed something in a dependency list.. I just think it's the wrong model for most projects

Re: React is winning by default and slowing innovation

#295

Earlier quoted context omitted.

“Most” react apps needing “seconds” definitely needs some citation or evidence. Even in fairly heavy and laggy react apps, it’s still usually network latency, waterfall requests, ad/tracking bloatware, large asset sizes, and the usual old classics that cause perceptible slowness in my experience.

In my humble (backender) opinion, if it's hard to use a tool right, that counts as a cons, and that must be accounted for when choosing which tool to use.

It's hard to build non-trivial web UI with any technology—React is just what's familiar. If Angular had won (god forbid) we'd be seeing all the same articles written about how bad Angular is.

Re: React is winning by default and slowing innovation

#296

Earlier quoted context omitted.

Agreed, Web Components don't require any framework and you can achieve everything you can achieve with React (including reactivity via attributeChangedCallback), the learning curve for Web Components is actually much less steep than React when you consider from the perspective of someone starting from scratch. Furthermore, Web Components enforce good patterns; like the fact that you can only pass strings as attribute…

> the fact that you can only pass strings as attributes This isn't true at all though. It's a lie started in the early days by React engineers that just won't die, unfortunately. Web components are objects and they can have properties and accessors like any object. The vast majority of declarative template systems like React, Lit, Vue, Angular, Svelte, Solid, etc., will declaratively set properties - which can carry…

That approach passes values in JS rather than the DOM, right? I read the go comment as talking specifically about DOM attributes which can only be strings (well, you can have boolean attributes as well).

Web components can be passed objects in JS, but its news to me if that is available in HTML.

Re: React is winning by default and slowing innovation

#297

This is mostly just a complaint about how good React is. It's so good that it's difficult for the technical benefits of alternatives to outweigh the social benefits of choosing React. Note that this is neither a major compliment to React's technical merits nor a criticism of React's competitors. In fact, I don't even disagree with the author on some of his claims, such as: > React is no longer winning by technical me…

I have been a part of quite a few tech stack decisions at various companies and startups. I have literally never heard an argument made for react that included merits of the framework itself. The decision was always based on a combination for familiarity, ability to hire for eng roles, and the ecosystem.

Re: React is winning by default and slowing innovation

#298

Web components are the way out of this trap. Every single framework that isn't React should be wholeheartedly supporting web components to make sure that they have access to a viable ecosystem of components and utilities without having to bootstrap an entire competitor to React and it's ecosystem. While a lot of people view web components as competitors to frameworks, they don't really have to be. The just define an…

I moved my entire business off React and now I don’t have to worry about tinkerers at Meta deciding to reinvent React every 2 years and tricking everyone by keeping the name again and again. Web components are fantastic. They are the real future.

https://i.imgur.com/7ITZb7d.jpeg

Aren't web components a pain in the ass to use?

Re: React is winning by default and slowing innovation

#299

Web components are the way out of this trap. Every single framework that isn't React should be wholeheartedly supporting web components to make sure that they have access to a viable ecosystem of components and utilities without having to bootstrap an entire competitor to React and it's ecosystem. While a lot of people view web components as competitors to frameworks, they don't really have to be. The just define an…

>"While a lot of people view web components as competitors to frameworks, they don't really have to be. The just define an interface between component implementations and browsers so enable interop and reliable composition."

I avoid frameworks like a plague. Plain JS, web components and some good domain specific libs are more than enough to cover all my needs

Re: React is winning by default and slowing innovation

#300

Earlier quoted context omitted.

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

I don't know if I'd consider that the reactive callback because there's no change in state if I only put the `console.log` in `onChange`. The point of the reactive callback is to be invoked on a change in state and in this case, that is the component function would you agree?

In Vue, for example, when I set up a `watch`, the change in state only invokes the callback that is wired to the state. In React, the entire component function is invoked again on a change of state.

Post reply on HN