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

681–690 of 866 posts

Re: React is winning by default and slowing innovation

#681

Post by austin-cheney »

WA wrote: post #661
austin-cheney wrote: post #609

Earlier quoted context omitted.

Here is an example: /lib/dashboard/dashboard_script.ts https://github.com/prettydiff/webserver When you aren’t using framework like components state restoration is a single function that runs only on page load. There is no state explosion and on localhost the SPA fully renders and finishes state restoration in about 105ms from http request.

Thanks, but this is a server-side thing and has nothing to do with client-side DOM manipulation?! Sure, you can put stuff on the server and do HTTP over the wire. It's oftentimes the better solution. But there are apps/tools that are rightfully an SPA (like tldraw or excalidraw for example) and can run local-first and offline in a browser. You build the entire app in JS and you'd need a bit more than vanilla Web comp…

Look at the file path I specified. That file runs only in the browser.

Re: React is winning by default and slowing innovation

#682

Post by austin-cheney »

brazukadev wrote: post #669
austin-cheney wrote: post #609

Earlier quoted context omitted.

Here is an example: /lib/dashboard/dashboard_script.ts https://github.com/prettydiff/webserver When you aren’t using framework like components state restoration is a single function that runs only on page load. There is no state explosion and on localhost the SPA fully renders and finishes state restoration in about 105ms from http request.

Mate, if you are proud and happy to code this way, congratulations. That code is an absolute nightmare tho. Your eyes are trained on it so you think this is as good as an ergonomic framework.

How would you refactor it?

Re: React is winning by default and slowing innovation

#683

Post by spankalee »

chrismorgan wrote: post #534
jdkoeck wrote: post #440

Earlier quoted context omitted.

Alas, that’s a common misconception! You’re confusing properties with attributes. Attributes are set through HTML and are stringly typed, but litjs properties can be any js value. For instance, I have a project with a small web component that displays data from a duckdb wasm connection. The connection object is passed as a property and it works flawlessly.

If you’re using it with something like React, passing attributes is easy, but setting properties is much harder, requiring using the escape hatches—I believe you’ll need useRef and useEffect, and a bit of care because it’s frightfully easy to do the wrong thing.

No, React sets properties by default now. It was one of the last holdouts, but they finally fixed this in 19.

Re: React is winning by default and slowing innovation

#684

Post by spankalee »

WA wrote: post #553
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…

Web components are the opposite of what you say: they are the component interface and specifically not the implementation. You can implement them however you want.

What they offer is interoperability and the ability to use components outside of a framework or with a framework.

And that's why they help solve the ecosystem trap.

Re: React is winning by default and slowing innovation

#685

Post by spankalee »

WA wrote: post #590
nikitaga wrote: post #583

Earlier quoted context omitted.

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

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.

Re: React is winning by default and slowing innovation

#686

Post by spankalee »

WA wrote: post #401
austin-cheney wrote: post #302

Earlier quoted context omitted.

Strong disagree. Web Components are react in different clothing. You don’t need this component-based framework style architecture to write applications for the browser. I promise writing applications for the browsers is not challenging. You don’t need big frameworks or component madness that’s more of the same.

React made reactivity popular. Web components don’t give you reactivity. You still tell the UI how to update based on state changes imperatively and that is annoying as hell. If you want reactivity in web components, you need a wrapper or another framework/small library.

There are plenty of web component helper libraries that give you reactivity. Reactivity is an implementation detail.

Re: React is winning by default and slowing innovation

#687

Post by agos »

squidsoup wrote: post #127
SebastianKra wrote: post #59

Why do these articles keep dismissing the innovations by React itself. The Svelte compiler is revolutionary, but the React compiler is not enough somehow. The React-Team has worked on server components, concurrent rendering, suspense & transitions. They all integrate with each other to allow for some really elegant patterns. While the VDOM overhead does exist, it's not the performance bottleneck. More likely reasons…

You don't even need RSC to fix waterfall fetching, relay solves this problem beautifully.

Only if you already have a graphql backend, otherwise the solution won’t be that easy

Re: React is winning by default and slowing innovation

#688

Post by majora2007 »

javcasas wrote: post #510
friendzis wrote: post #466

Earlier quoted context omitted.

In what way React is anywhere near well designed? Look over quick starts of React and Angular, for example. One is a well structured application , the other is a spaghetti script , all held by magic and conventions. If you recall the (in)famous "PHP: a fractal of bad design", React basically ticks every box in this rant and then some. It's not surprise knowing it's origins, but still. The reasons React has got tracti…

Angular: Where is the code for the component that is used here? Anywhere in the codebase, maybe defined multiple times, depending on module configuration one or another may be used. Good luck finding which one. React: Where is the code for the component that is used here? Either defined in the same file or imported, like any other javascript thing. But React is the crazy one.

In modern day Angular, everything is standalone, so the module issue doesn't apply.

I've been coding in Angular since 2 and I have never had a duplicate component with the same name. Almost every Angular app uses nearly the same folder structure.

Re: React is winning by default and slowing innovation

#689

Post by agos »

davedx wrote: post #501

> Developer time is spent managing re-renders, effect dependencies, and hydration boundaries You might be, I am not! All my react apps for work in the last ten years I’ve spent little time doing this. The occasional useMemo and relatively intelligent splitting of components is all you need. I don’t even know what “hydration boundaries” are; sounds more like a next.js thing than a react thing. Why is everyone pulling…

That’s great for you (though it reads like a brag), but a lot of devs - even seasoned ones - have had to fight against unwanted re renders and the sharp edges of effect, hence the quite common complaints about those

Re: React is winning by default and slowing innovation

#690

Post by sergiotapia »

nicce wrote: post #434
sergiotapia wrote: post #305

Earlier quoted context omitted.

Never heard, "man react is great!" It's always, "we can hire more easily". Unfortunately

> "we can hire more easily". Is this the synonym for cheaper workforce? You always get decent people if you pay enough.

I don't think so. I mean, if your code is Javascript you have 1000 applicants. If your code is Nim, you have maybe 10? That's how the beancounters think about it based on conversations I've had.

So to please the beancounters you need to sell a technical decision so that it's technical merits massively outweigh those 1000 candidates.

Post reply on HN