Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I don't miss React: a story about using the platform

jackfranklin.co.uk

Post reply on HN
Print view View original

221–230 of 279 posts

Re: Why I don't miss React: a story about using the platform

#221

Post by ricardobeat »

5Qn8mNbc2FNCiVV wrote: post #77
ricardobeat wrote: post #67

Earlier quoted context omitted.

> If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let's not kid ourselves This is a classic red-herring argument from developers who have not built anything complex with vanilla js. You can build rich interactions with or without a framework, you’re just making different trade-offs (conventions, learning curve, flexibility, tooling). There is a much larger…

Using web components makes your forms instantly inaccessible without JS. Browser APIs evolved over time and albeit most are pretty good nowadays, a lot of stuff is still bad in HTML world and frameworks like these solve that painpoint. The framework still allows usage of FormData and whatnot, there's even a new framework ontop of React now that aims for form handling without any JS at all in the browser so there are…

I’m not sure I can even make out what argument you’re trying to make, but let’s go.

Nowhere in the article the author claims web components is a great choice for everything. He works on DevTools, which is not a website, and 100% js already. Seems like a perfectly ok choice.

> be annoyed to write a lot of imperative code to add a modal

I’ve recently added a modal system to a react app using react-aria-modal, and no kidding, it took over 1000 lines of code* to get it working, following their guide to the letter. Later, out of frustration, I reimplemented the same feature using Svelte (which lets you get much closer to plain JS and HTML), with the same features and aria support, in a couple of hours and 10x less code.

> it's inevitable that you write a poor-mans version of React… it came from the real needs and desires of developers

React uses a very specific architecture of VDOM, stateful components, hooks etc. There are plenty of alternatives, including well developed “poor-man’s versions” like Preact, hyperapp or SolidJS.

It seems you’re under the impression React is some kind of universal solution to all frontend apps, developed by “the people”. It’s just a framework, developed at facebook, born from the evolution of their existing server component system. It works, feels nice for small apps, I use it along with a million other people, but it’s not a panacea, and it’s sad that a lot of people simply dismiss everything else before they’ve had a chance to actually understand the trade-offs.

* id say it’s imperative code too - calling hooks in the correct order, passing data from one to another, telling react what the dependencies are, updating and transforming values

Re: Why I don't miss React: a story about using the platform

#222

Post by nazka »

cyral wrote: post #39
nawgz wrote: post #23

Earlier quoted context omitted.

I wrote my own React components using D3 to do the underlying math but setting up my own DOM rendering. It's ok, my thoughts Pros: * I have generic "zoom/pan" implemented. I did this by making a generic ChartContainer with 5 zones - top, right, bottom, left, content - and you specify just the size of the non-content zones (if displaying them at all) and otherwise it behaves responsively (i.e. CSS style on the contain…

I also went this route and used d3 for the math but my own hand-made SVGs for the rendering so that the DOM is all in "react land". You may want to check out this library: https://airbnb.io/visx/ They converted a ton of d3 features into proper React components

Awesome library. I used it back when it was named Vx with react-spring and d3. You can’t beat this combo.

Re: Why I don't miss React: a story about using the platform

#224

Post by roopawl »

Bellend wrote: post #74
roopawl wrote: post #65

Earlier quoted context omitted.

Mirrors my experience exactly. Used polymer, angular, react and lit element. I’ve been able to rely on react for almost a decade. The others have just been mistakes

You don't understand the context since Polymer and Lit Element do not solve the same problem space as Angular and React aim to solve.

This is very small thinking. The context is to produce value for a user on a web platform. I’m well aware of the APIs and limitations for each of these.

Re: Why I don't miss React: a story about using the platform

#225

Post by mhoad »

croes wrote: post #175
steve_adams_86 wrote: post #146

Earlier quoted context omitted.

Honestly I bet a significant portion of the code I have maintained (and even some I’ve written) was reinventing a wheel someone didn’t know existed. Not even out of a desire to solve a problem, but simply not realizing it was done already. I suspect people still reach for jquery for similar reasons. They know it makes complicated stuff work, it’s reliable, they don’t need to think about the specifics of the problems…

The same will happen to react. React will become a victim of its success, because the more it is used the more likely its concepts will be integrated directly into the browser or ECMAScript

Maybe this is less obvious if you’re deep in the React ecosystem and nothing else but I’d argue that React is already in early stages of a death spiral for a few reasons.

These mostly come down to

1. It’s no longer the fastest, in fact it’s barely competitive speed wise with many things that have come after it.

2. It’s architectured in such a way that it is fundamentally misaligned with the rest of many web standards (I.e the DOM) which made a lot of sense when it was released but is now a major liability.

3. It now has to ship around a lot of code that now lives natively inside the browser and is now rather bloated as a result compared to newer iterations such as Lit as mentioned in the article.

Personally, I think it’s fatal in the sense that they have painted themselves into a very specific corner with no obvious engineering solution to get them back on the standards path. Its problems as a result aren’t really fixable without major architectural changes that would fundamentally change the project. On top of that they are only going to get actively worse over time as more things get moved into the browser and they are still stuck shipping a bunch of JS code to do the same thing. In short they are on a bad long term path with no clear off ramp.

I wouldn’t start a major project in React in 2022 for something I wanted to be around in 5 years from now as a result.

Re: Why I don't miss React: a story about using the platform

#226

Post by mhoad »

Bellend wrote: post #27
TAKEMYMONEY wrote: post #14

> Was this slightly more work than using a library from npm? > I'd definitely recommend using a library for this, and we settled on lit-html (link to library from npm) This article is mostly about switching from React to Lit. You can use modern web APIs (like FormData) with React, FormData's not a replacement for state management. You can use Web Components with React, the way Fluent UI does ( https://docs.microsoft.…

Anyone know what is going on with lit-? Their TypeScript starter is painfully bloated and outdated and never seems to keep pace. I actually ended up looking at microsoft/fast for my use case but that seems to be stale in some way. I kind of feel that given the "simplicity" of a single class wrapping custom elements, everything is pretty boring. Note: I cannot do better.

npm init @open-wc is a really nice starting point for Lit also mentioned here https://lit.dev/docs/tools/starter-kits/

Re: Why I don't miss React: a story about using the platform

#227

Post by youngtaff »

_pdp_ wrote: post #8

If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let's not kid ourselves. This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much. In fact, I would even say that if this is not a core part of your product, you are simply wasting time and resources. There is a huge amount of man-hours pour…

Jack builds Chrome DevTools, that's a really rich app and seems to work pretty well

Re: Why I don't miss React: a story about using the platform

#228

Post by cube00 »

protocontrol wrote: post #192
semiquaver wrote: post #127

Earlier quoted context omitted.

Yes, they are usable without polyfills in any modern browser. The general idea is that you can register new element types whose behavior is defined in JavaScript classes. They interact with the rest of the DOM in the same way other HTML elements do: by emitting and handling events. They can also maintain a “shadow DOM” with its own HTML subtree and CSS scope, so that you can make complex elements whose internal state…

Hi. Sorry I couldn't parse that without a specific example. In which typical use cases should I create new element types?

Whenever you'd usually create a new component in React.

Re: Why I don't miss React: a story about using the platform

#229

Post by mhoad »

zelly wrote: post #49

The problem with Web Components is it's slower than React or other vDOM implementations. Also everything is a string. To re-render, you have to manipulate the innerHTML--usually replacing the string every update. To pass a prop to a component in a modular way, you have to pass a string attribute (e.g. something like ). Even though v8 is extremely fast at string operations, it's just not a good practice and doesn't sc…

I’m not sure what you’re referring to here honestly but React is substantially behind web components in terms of every performance metric I can think of.

Boot up, runtime, micro benchmarks and at scale.

Re: Why I don't miss React: a story about using the platform

#230

Post by mhoad »

protocontrol wrote: post #192
semiquaver wrote: post #127

Earlier quoted context omitted.

Yes, they are usable without polyfills in any modern browser. The general idea is that you can register new element types whose behavior is defined in JavaScript classes. They interact with the rest of the DOM in the same way other HTML elements do: by emitting and handling events. They can also maintain a “shadow DOM” with its own HTML subtree and CSS scope, so that you can make complex elements whose internal state…

Hi. Sorry I couldn't parse that without a specific example. In which typical use cases should I create new element types?

This might be a good introduction from the Lit team themselves to see what this looks like in practice https://youtu.be/QBa1_QQnRcs
Post reply on HN