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

691–700 of 866 posts

Re: React is winning by default and slowing innovation

#691

Post by agos »

sitzkrieg wrote: post #25
jmcgough wrote: post #6

> React didn’t win purely on technical merit A sentence written by someone who clearly hasn't worked on a large Angular 1.x project.

here here, being involved with porting a huge angular 1 project to the first angular2 RCs (golden dev choice) was the worst frontend project i ever witnessed in my not short career :-)

Same here. I started learning React when the official angular way of migrating gradually didn’t work at all on my code base, while I was able to use a “react in angular” thing to migrate components one by one. Crazy times

Re: React is winning by default and slowing innovation

#692

Post by MrJohz »

nikitaga wrote: post #583
WA wrote: post #553

Earlier quoted context omitted.

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…

> If you don't want that, you gotta bring a wrapper or another reactivity library/framework. Being able to use a different library with a component, instead of the component being tied to React, is the whole point. React isn't 100x more popular because its reactivity system or any other feature is 100x better. Half the reason it's popular is network effects – too many frontend components / libraries are made React-on…

Except the problem with compatibility is almost always the reactivity element, right? Getting, say, Vue's reactivity system to compose properly with Svelte's, or React's with Angular's. And that's not going to work well when Vue is using signals to decide when to rerender a component, React is using its props and state, and Svelte isn't even rerendering components in the first place.

This is especially difficult when you start running into complicated issues like render props in JSX-based frameworks, context for passing state deeply into a component, or slots/children that mean reactivity needs to be threaded through different frameworks.

Re: React is winning by default and slowing innovation

#693

Post by bobbylarrybobby »

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…

On the other hand, how do you write a function in a react component that retains its identity between renders (to pass as a prop to a child and not have the child re-render when it changes)? You can't — you need useCallback. Meanwhile in svelte you just... write a function.

They each have their own quirks. Personally I'd rather write language specific if/else (obvious, can't get it wrong) than have to remember to reactify my functions if I want to avoid subtle performance issues.

Re: React is winning by default and slowing innovation

#694

Post by actinium226 »

beezlewax wrote: post #419
actinium226 wrote: post #379

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…

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

This seems like something that's technically true but not very practical: https://react.dev/reference/react/createElement#creating-an-...

It still doesn't solve the problem of scaling down to simple things. I think this is better illustrated with this codepen I made a while ago to implement a reactive button in React, Vue, Alpine, and vanilla JS: https://codepen.io/nbelakovski/pen/jEOVbyP

I tried to implement the React part without JSX, but I couldn't figure out how to render the function component, and while I was able to render a class component based on the old docs, I couldn't figure out how to use useState with it.

But going back to the codepen, the React and the vanillaJS both look messy, but I would take the vanillaJS over React if it means that I can sprinkle a little JS in my code without having to buy the whole farm that is create-react-app + npm + eslint + vite + all the React stuff I've mentioned.

Re: React is winning by default and slowing innovation

#695

Post by MrJohz »

spankalee wrote: post #685
WA wrote: post #590

Earlier quoted context omitted.

I get your point. I'm fully with you that it makes no sense to use React and write React apps if you can achieve the same without React. I hate the fact that many great frontend components only work with React, especially considering that React didn't properly support Web components for ages, whereas almost every other framework had no problems with them. However, out of the box, Web components don't come with almost…

Lit is not a framework. Lit only helps you make standard web components that you can use anywhere *because they are web components*. You could take a Lit-based web components a rip Lit out and you would still have the same component that you can still use anywhere. Lit is just an implementation detail.

Lit is a framework, that's the whole point of it. Lit is a framework that happens to generate web components, but the goal of Lit is to provide the rendering and state management necessary to actually write those components. That's the framework bit.

If you take a Lit-based web component and rip Lit out, you have dead code that won't work because it's dependent on a framework that you have removed.

You could take a Lit-based web component and replace it with a non-Lit-based web component and that would be fine, because Lit uses web components as its core interface, but Lit itself is still a framework.

Re: React is winning by default and slowing innovation

#696

Post by actinium226 »

kqr wrote: post #443
actinium226 wrote: post #379

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…

You certainly don't need JSX for React, nor a build chain. My ship investor Kelly trainer game[1] is a simple React application in a single HTML file. The initial page load is slow because I experimented with using built-in browser module support to pull in React, but if you change it to serve a pre-built library from a CDN instead then also the initial page load is fast. You can view the source on that page to see h…

You've given this example about how to use React without JSX but actually you're not using React but Preact, which is a different library. Preact, to its credit, actually has instructions for using it without JSX right in their getting started guide: https://preactjs.com/guide/v10/getting-started/#alternatives.... In fact it's the very first paragraph.

React itself buries this information in a reference (https://react.dev/reference/react/createElement#creating-an-...), and the reference doesn't even give a complete example because the example still uses JSX to render the root component.

And I'm not sure if Preact is really a viable alternative to React. If a library I want to use can't work via preact/compat, what then? Do stackoverflow solutions for React problems apply to Preact? I imagine at least some might not. Given these limitations, is there a reason someone would choose Preact over a framework that has its own ecosystem, like Vue for example?

Re: React is winning by default and slowing innovation

#697

Post by ctvo »

It's winning by default because _there is nothing materially better_. React was _materially_ better than Ember, Angular, plain JQuery, etc. at the time.

Front-end engineers have no issues adopting new frameworks. See the common complaints about the speed front-end stacks change vs. say Spring MVC or Rails.

A more interesting examination is what is the impact of agentic AI tools being able to write better, more idiomatic code in React vs. Svelte because there's more of it. The human side is less of a barrier here.

Re: React is winning by default and slowing innovation

#698

Post by osigurdson »

drysart wrote: post #420
mhh__ wrote: post #391

Earlier quoted context omitted.

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…

I'm not an expert, but maybe have a look at this and see if it changes your opinion: https://svelte.dev/blog/virtual-dom-is-pure-overhead.

Re: React is winning by default and slowing innovation

#699

Post by osigurdson »

mhh__ wrote: post #391
osigurdson wrote: post #389

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

I don't think it is an unanswerable question for someone with (say) 20 years of deep javascript experience and understands the history.

Re: React is winning by default and slowing innovation

#700

Post by pcmaffey »

danabramov wrote: post #447
pcmaffey wrote: post #327

There are no alternatives that are 3x better than react. That’s the minimum it will take to change the ecosystem default. React is good enough for most applications. Is that slowing innovation? Vercel’s rsc push is definitely headwinds. But IDK, I see lots of interesting libraries around state mgmt & local-first primitive. I’d like to see more focus on SSG and islands architecture. I think bun 1.3 (bake) will be a he…

RSC is React’s take on SSG and islands architecture (but deeply composable rather than shallowly).

That makes sense. Too bad it was developed in partnership with Vercel. Deep composability seems to serve their needs—it's not a solution the ecosystem was asking for, at least from my perspective.
Post reply on HN