Hacker News Reader

React 16 is about 5 KB uncompressed, it’s a tiny agnostic library that does very little and can be used to render to anything from a DOM to a native GUI to a dot matrix LCD screen (https://github.com/doodlewind/react-ssd1306/blob/master/docs...). Together with React-DOM it is about 100 KB, 30 KB gzipped (DOM library is bulky in part because it needs to support all of the default HTML and SVG elements). It’s not supposed to be amazing at anything except what it does, build complex or simple stuff it is up to you.

But of course nobody uses just those and instead bring megabytes of dependencies.

It may interest you to know that React was first used in production in 2011 and the library was subsequently open-sourced in 2013.

As far as programming tools go I don't think we can call it a fad anymore.

I disagree. Every time something is hyped that extends the time it can be called a fad*. React gets hyped up freshly again with every announcement from Vercel**.

* well maybe a collection of fads rather than a fad in itself

** I say this lovingly, it's similar to the magic of Steve Jobs and Apple. That said Vercel wouldn't interest me that much at this point if it was React-only. But the DX works for many different sorts of projects.

For there to be a bubble, it has to be pierced. We haven't seen that with React. We did see that with Angular. I think the reason why the bubble did burst with Angular is because it made many opinions about things, and the more opinions you make, the fewer people in aggregate are going to agree with your total outlook. It's easy to convince people of 1 thing, and less easy to convince people of N things. React being less opinionated and not a batteries-included option means it won't be going away for awhile.

> React being less opinionated and not a batteries-included option means it won't be going away for awhile.

That's what they love to say, but it has never seemed that way to me. One way data flow seems to be a huge opinion.

Also dangerouslySetInnerHTML, htmlFor, className, etc, etc.

That last one was handled by the community, partly coming from Facebook, with stuff like GraphQL, but now they've gone more with batteries included route even on their website by suggesting to use a big framework: https://react.dev/learn/start-a-new-react-project

Also their opinions don't align with those of a lot of the community. A lot of glitches stem from controlled components.

"In most cases, we recommend using controlled components to implement forms" https://legacy.reactjs.org/docs/uncontrolled-components.html ( which they might have finally changed their position on https://react.dev/reference/react-dom/components/input#contr... )

"React Hook Form embraces uncontrolled components but is also compatible with controlled components." https://react-hook-form.com/advanced-usage/#Controlledmixedw...

A more fruitful way to think about the degree of opinionated would be to compare to alternatives. If "className" versus "class" is too much 'opinion' maybe vanilla JS is best for your eclectic taste. Also, you'd absolutely find stuff like Angular to be maddening in its degree of opinionatedness.

It isn't just the framework that's opinionated, it's the people behind it. An example is their website where they don't mention create-react-app at all here: https://react.dev/learn/start-a-new-react-project They could have added it so as not to confuse someone who had heard about create-react-app and understandably expected to see it on a page called "start a new react project" but they prefer to blot it from memory...

Is the discussion about frameworks or just React? They seem to be treated as interchangeable but React's foundations are not shared among other frameworks.

It's really about hype. I think React is good but overrated.

Edit: I thought about it some more and the problem is that in order to see adoption, frameworks need to convince devs that they need something. With Vue what you have is reactive() and ref(). So they're convincing a lot of devs that they need MobX. Where in reality most devs don't need React's useState one-way bindings and they don't need MobX-like reactive objects either, nor do you need Signals from Solid. That said, if you prefer one of these, go for it!

Ergonomics of binding events and setting attributes/properties/styles is useful and I like how Lit, snabbdom, and Svelte provide ergonomics without one of these state management paradigms.

React is perfectly hyped, the introduction and complete absorption of flux architecture proves this. It's changed how we even write vanilla javascript. Most of the lessons we're talking about right now about questioning whether we even need state management paradigms to such a degree would not have happened without React.

So if a problem exists about this scenario, it isn't about React, but how teams decide on tools. And unfortunately, most teams that aren't building their own solutions, go with the tool that has the largest "safest" community, not the one that accurately solves their issue.

That's not how I remember it. People were thinking a great deal about state management with Backbone, Angular.js, and Knockout.js. It intensified with React. I wonder what would have happened with Angular.js if not for React...

> No, it's not exhausted - people and businesses pushing heavyweight frameworks stand to lose out, and trying to silence the debate would help them.

What do you think about frameworks like Leptos that take the best of both worlds?

> progressively-enhanced single-page apps that are rendered on the server and then hydrated on the client, enhancing your <a> and <form> navigations and mutations seamlessly when WASM is available.

https://docs.rs/leptos/latest/leptos/

I think they're pretty neat, and that Svelte is one.

"I used this technique in my own emoji-picker-element. If you’re already using Svelte in your project, then you can import 'emoji-picker-element/svelte' and get a version that doesn’t bundle its own framework, ensuring de-duplication. This saves a paltry 1.4 kB out of 13.9 kB total (compressed), but hey, it’s there. (Potentially I could make this the default behavior, but I like the bundled version for the benefit of folks who use <script> tags instead of bundlers. Maybe something like Skypack could make this simpler in the future.)"

https://nolanlawson.com/2021/08/01/why-its-okay-for-web-comp...

Thing is I actually like coding in Vanilla JS, at least some of the time.

There are smaller SPAs like preact or mithril. One could similarly argue that why should you have to use Django to show a user hello world?

It really doesn’t matter. Master your tool and most of the supposed downsides can be avoided.

I have a lot of respect for mithril, they created a tiny vdom that works really well. Though you don't always need one.

https://svelte.dev/blog/virtual-dom-is-pure-overhead

I have played thousands of bullet chess games on Lichees and is and was very snappy and used to be based on Mithril so it's very battle tested in a literal sense.

https://bestofjs.org/projects?tags=vdom

FWIW I disagree that something like virtual DOM can be pure overhead. It is useful to have virtual just about anything. Virtual filesystems for instance.

It’s good when you want interactivity that’s technically straightforward but in high volume.

It doesn’t work for code editors because they need very close interaction with the DOM, whereas React provides an abstraction layer that covers the common cases.

It works but clearly it's not needed, and to me I don't see a whole lot of innovation from a computer science standpoint because the most complex js projects don't use it.

Well something is needed. The alternative is:

1. Building apps with manual mutations (which is what we did before in the jQuery era). This involves a lot of boilerplate code, and it is hard to ensure that the UI state stays in sync with the app state properly.

2. Re-render the world on every state change. This works and allows you write simple code that is react-like in that it is pure transformation of app state into UI state, but it's slow and quickly runs into performance issues even in small apps.

1 still makes sense in the most performance sensitive scenarios. And 2 can work for the very simplest apps. But React and similar frameworks are great for everything in between.

> I don't see a whole lot of innovation from a computer science standpoint because the most complex js projects don't use it.

That seems silly. You could make the same argument for something like SQL. The most complex data manipulations won't use it. But it's still useful for the 90% that aren't that complex.