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

551–560 of 866 posts

Re: React is winning by default and slowing innovation

#551

Post by baxuz »

gloosx wrote: 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…

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

Re: React is winning by default and slowing innovation

#552

Post by ojr »

gloosx wrote: 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…

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.

Re: React is winning by default and slowing innovation

#553

Post by WA »

spankalee wrote: post #157

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…

Web components are an implementation detail. They don't bring anything framework-like to the table. The most important being: reactivity. You have to write DOM manipulations imperatively like you did 15 years ago with jQuery. If you don't want that, you gotta bring a wrapper or another reactivity library/framework.

For many use cases, there's not much difference between writing a Web component or an IIFE (Immediately Invoked Function Expression) that attaches your JS functionality to a div somewhere like we wrote JS without jQuery 15 years ago, although Web components are more elegant. But still, they are mostly packaging.

I say this as someone who likes Web components and who created several ones that are used in production. But just yesterday, when I added a new attribute to one of my Web components and wondered for a moment why the new attribute wouldn't get rendered, I realized that I forgot to add the code that imperatively tells the DOM how to update itself. Which is okay, because this is just a small component and it's pretty lightweight. I'd never use a framework for stuff that can be achieved without much effort in vanilla JS.

My point is: selling Web components as a way out of this trap is disingenuous. They don't offer anything at all that is important for modern frontend dev.

Re: React is winning by default and slowing innovation

#555

Post by patates »

sensanaty wrote: post #526
gloosx wrote: 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

> 5 straightforward hooks `useEffect` is straightforward? Cloudflare recently (like, literally 4 days ago)[1] had a pretty big outage because of the improper use of `useEffect` (surprise, surprise, it was the dependency array), a hook so infamous if you search "When should I use `useEffect`" you'll get approximately 9 trillion hits, with nearly all of them telling you something different, including Dan Abramov himsel…

Javascript has warts, React has warts, Svelte has warts, Python has warts... It's easy to shoot yourself in the foot in any tech - it's leaky abstractions all the way down after all.

useEffect usage needs to die, yes. I don't think it's a case against React, given its age.

Otherwise, using React is straightforward. I started coding in it without reading any docs. As someone who used Dojo, prototype, ext.js, jQuery (+UI), Backbone.js, knockout (still has a special place), Mithril, the classic angular, vue (2), svelte, Marko and even Solid (I'm not totally sold on signals), React is the most straightforward by a mile.

Is it the most performant? Hell no. Is it the one with the least gotchas/warts? Nope. Concise? A giant no. Batteries included? It depends on what you're looking for...

But I can just be productive with it, and it makes sense.

Re: React is winning by default and slowing innovation

#556

Post by raverbashing »

> Meanwhile, frameworks with real innovations struggle for adoption. Svelte compiles away framework overhead. Solid delivers fine-grained reactivity without virtual-DOM tax. Qwik achieves instant startup via resumability.

Yes, very cool

But if you pick any of them you risk running into gotchas that few people know about (and their developers ignore or handwave), into possible lack of documentation, into a lack of ecosystem

Re: React is winning by default and slowing innovation

#557

Post by zarzavat »

_heimdall wrote: post #297
tshaddox wrote: post #87

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.

> I have literally never heard an argument made for react that included merits of the framework itself.

That doesn't mean that those merits don't exist. Most of the new React competitors are just reinventions of HTML templating done client-side. React has been dominant for so long that there's a whole generation of frontend devs who don't remember why it was invented in the first place. Writing loops in HTML? We tried that, it sucks!

It's telling that the "new" frameworks have no ideas other than to revert to ideas that were tried in the past. React is so modern it makes its replacements feel dated.

Re: React is winning by default and slowing innovation

#558

Post by WA »

austin-cheney wrote: post #488
onion2k wrote: post #356

Earlier quoted context omitted.

You don’t need big frameworks or component madness that’s more of the same. You don't, but in any sufficiently complex app you'll end up writing a sort of 'mini framework' of your own as you abstract all the things that crop up more than a few times. That framework might be really nice at the start but it'll get more and more hacky as the project continues, especially if you're constrained by resources. Eventually yo…

This has never been true for me. I never end up writing any kind of internal framework. Instead I write libraries that solve specific problems and achieve code reuse, which are really either functions or data storage objects restricted to their own files. At least, that’s how I think about code universally, libraries, but specifically in the browser this comes up less because the problem space is much smaller. Really…

What code are you using to reactively render state? Or do you write all DOM manipulations manually and just accept the problem of state explosion?

Re: React is winning by default and slowing innovation

#559

Post by lelanthran »

mhitza wrote: post #83

The javascript people should stop innovating for a couple of years. To much innovation that lead nowhere. How many ways can one build a web javascript project? Browser people should pick up slack and start developing sane components for the web. How about a backend-supporting combobox, or a standardized date picker across browsers? Then we wouldn't need to constantly innovate how we manage the state of those fundamen…

> How about a backend-supporting combobox,

Interesting. How would this specification look, in context of browser standards?

> a standardized date picker across browsers

Not possible for the majority of use cases. Too much variation in what the date is used for and how the display must be constrained.

For example the lack of constraining the dates makes it unusable in most contexts (flights, hotels, meetings, etc).

Then those constraints need to interact with other elements on the page, like a checkbox for "weekends only" or similar.

Even without constraints, sometimes you want the user to go next/previous by years, sometimes by hours, etc

Date picking is just not general enough to have as a single component.

Post reply on HN