Live data from Hacker News

React is winning by default and slowing innovation

lorenstew.art

411–420 of 866 posts

Re: React is winning by default and slowing innovation

#411
I use a discussion board that has migrated from React to uber-React. Now the system has become completely hostile to saving local pages. Now any local copy when opened locally shows (then blanks completely) all visible content and mutters helplessly "Perhaps you followed an invalid link?"

But even more hostile is a discussion forum has replaced embedded message post times with just useless plain "x ago" text and the actual timestamps for each has been hidden as React "props" magically shown by mouseover events by "class". Like "I'll show a picture of a timestamp if you really wanna see one."

An HTML-only copy is more than useless when it used to contain messages and times. A "Web, complete..." copy has message text in there but it blanks everything, sounds like the kind of bug someone would have fixed in a minute if they cared.

And they don't it seems. Like web architecture involves toppling furniture at random and too bad if you trip over something. Love it or leave.

Is this a React thing or an attention-to-detail thing? When I cannot easily save pages locally, I'll go elsewhere.

PS: It "looks" as beautiful as ever. A tad slower maybe.

Re: React is winning by default and slowing innovation

#412
post #407

One consideration that that is missing: how familiar are LLMs with this technology? And from this point of view the app has sailed, I’m afraid we are stuck with the frameworks that are available today for eternity, for better or worse. And maybe that is not such a bad thing. I don’t do full stack programming in my day job, but I have this crazy idea that if I ever have a startup idea, I want to be able to code an MVP…

>how familiar are LLMs with this technology?

Evil people claim the technology has been promoted entirely for the sake of clearing the ways for LLMs, as it makes more sense from the "perspective" of an ANN than from the perspective of any given human developer.

In a biased Turing test like that, of course the LLM is going to be more proficient than a junior. The junior is slowed down by their vestigial expectation that these very popular tools by very large groups of very smart people actually make sense.

Re: React is winning by default and slowing innovation

#413
Genuinely wondering, as someone who is not a web developer: is React the reason why most websites are so heavy and slow?

As in: is it the default because it makes developers more productive, but at the cost of slowing innovation that would make websites less heavy and slow? Or is "innovation" here completely independent from the performance?

Re: React is winning by default and slowing innovation

#414

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'm wholly convinced that only people who have never tried to use web components for anything serious, and/or have basically no experience with web dev, are the only ones will make this argument.

For example, a guy I know online who is an argumentative, boring backend dev that regularly has really bad and uninformed takes on things he has very limited experience with, he recently said he prefers web components. For all intents and purposes, he had ~0 web development experience.

Re: React is winning by default and slowing innovation

#415

I feel this with every fiber of my being. I used to do a TON of front-end work, some of it quite cutting edge, delivering highly performant user experiences in the browser that had previously been only thought possible in a native app. Back in like 2009-2015. I was deeply connected with the web standards fundamentals and how to leverage them mostly directly. I detoured into heavier focus on backend work for quite a w…

>You still get JSX

Give me S-expressions instead. How else am I supposed to prove to frontend developers that I didn't make those up

Re: React is winning by default and slowing innovation

#416

In the age of AI, it's all about popularity contest unfortunately. More people use it, more data points, more training data to feed, better AI response, more people use it. Svelte shot itself in the foot with runes and other incompatible (but minor) syntax changes. Bad timing. Because now whenever I ask any AI, they will suggest old syntax that doesn't compile.

>Because now whenever I ask any AI, they will suggest old syntax that doesn't compile.

That's an AI problem, not a Svelte program. This happens for any lib which happens to change, not just front-end contenders. (and oh do they change, especially niche vendor sdks!)

Re: React is winning by default and slowing innovation

#418

Earlier quoted context omitted.

I humbly disagree. I've never built a highly interactive application with React, only simple sites where the guys before me chose React, so I can't speak to its relative strengths or weaknesses there, but I've found that it doesn't scale down very well to simple sites. For a simple sign-in page, it's easy to just store state in the DOM and use a element to send the credentials, and maybe a little JS for the password…

Innovation is not really measured in terms of how well something "scales down".

See: multi MB downloads to display a few forms in a browser. Software that can’t work well with literal GBs of memory (some of it being a full browser runtime for some desktop forms). Games that run bad thanks to UE5 coming preloaded with footguns that ensure almost every developer will ship games that run poorly. Operating systems that run worse than a decade ago for even the parts that are functionally the same (e.g. a file explorer or start menu).

I sure love the smell of Wirth’s law in the morning - smells like my PC melting.

Re: React is winning by default and slowing innovation

#419

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.

I humbly disagree. I've never built a highly interactive application with React, only simple sites where the guys before me chose React, so I can't speak to its relative strengths or weaknesses there, but I've found that it doesn't scale down very well to simple sites. For a simple sign-in page, it's easy to just store state in the DOM and use a element to send the credentials, and maybe a little JS for the password…

You can use React without jsx by the way. The syntax isn't great but it is doable.

Re: React is winning by default and slowing innovation

#420
post #391

>> virtual DOM was a clever solution for 2013’s problems I'm not a front end expert but, I'm wondering, did anything really change since 2013 that renders the virtual DOM unnecessary? Or was it always unnecessary and people just eventually figured that out?

Browsers are much better now, whether it was ever necessary I suppose is like asking how deep a submarine can go in the sense that the post- react frameworks didn't exist

Browser are much better, but directly manipulating the DOM is still extremely slow compared to manipulating Javascript objects; and perhaps even more now than a decade ago it's fraught with performance traps that differ from browser to browser and even between successive versions of the same browser.

That hasn't changed in the past decade, and it's not going to change in the next decade either because the DOM has to make certain API guarantees that simply can't be optimized away. It'd take a significant change in how the DOM API works to even get close to achieve performance parity with a virtual DOM. (Like being able to tell the DOM to completely defer layout until you tell it that it's okay to continue.)

It's simply much more reliably performant to have all your DOM touching be done in a single batch during a virtual DOM diff resolution than it is to touch it and update it piecemeal as your application's components all mutate their own elements on their own schedules.

Post reply on HN