Hacker News Reader

React definitely continues to innovate.

Functional components and hooks were a huge innovation to class components and significantly improved the ergonomics of the library. That was only a few years ago.

The team is actively working on RSC (react server components) which will have a similarly large impact on react's capabilities.

Frameworks like remix and next will be able to leverage and build on this to create even better systems for building apps.

The whole signals blow up event is weird to me. Seems to be a loud and extremely small minority making a fuss around it.

IMO React continues to dominate over others (Vue, Svelte, Angular, Solid etc) because its just better - it embraces JS (no v-for, ng-for, non JS language) and strictly sticks to the idea that the view is a function of state.

All blow up events come from a loud and extremely small minority. But whether they are making noise or signal, does not depend on number of people!

React continues to dominate others because it meets baseline criteria for a js framework. And has corporate backing while Vue doesn't. Angular 1 was also popular because it was average js framework with google's backing before angular 2.

Implying that React remains popular for purely it's technical merit is utter nonsense. Because if react was really technically better, then no one would have migrated to Vue, solid and svelte or angular for that matter

> All blow up events come from a loud and extremely small minority. But whether they are making noise or signal, does not depend on number of people!

Fair, this instance is 100% noise imo.

We're engineers - we should be able to judge when something is silly.

> React continues to dominate others because it has corporate backing while Vue doesn't. And angular was popular for the same reason before angular 2.

I have never heard anyone in the last few years say react is better because it's backed by FB. I pick it because it embraces JS (unlike Svelte), doesn't reinvent the wheel (ng-for, v-for), and has a track record of maintaining backwards compatibility (unlike Angular re Angular vs Angular 2, hey its google what else should you expect). Class components continue to work 100%. Angular is backed by google - a much bigger company than FB and its nowhere close to as successful.

> Implying that React remains popular for purely it's technical merit is pure nonsense. Because if react was really technically better, then no one would have migrates to Vue, solid and svelte or angular for that matter

Some companies like to experiment, or have very unique challenges for which they find other tools better. I avoid Angular and Svelte - both have made such odd decisions. Some people do just prefer one tool over another! There will never be any set of capable tools where 100% of people select the same one. That's the variation of life.

Per the article's comment on forms and react and the messiness that ensues, well we're engineers. We can't expect a single library to solve every problem. We should be responsible for avoiding bad patterns like throwing from state into react state. It's 100% not necessary and should be kept separate.

You picked it because others before you had already decided and that was based off of the facebook name and backing. No one expected facebook to take such a pr hit over the last few years but ignoring why it become market leader misses the angular breakage event where everyone flocked from Google's framework to facebook's framework.

The reasons for not using other frameworks seems copycat without logic. For example vue uses v-for I don't want to have to learn a handful of obvious tags like v-if or v-else but then choosing react which has adopted jsx something that requires converting standard html and learning more to get you to the same place.

FB's reputation has no bearing on my choosing react vs svelte vs x or y or z.

I continue to pick React for projects because it's better than the alternatives - not because others before me have picked it and I'm just copycatting.

I can understand why some dislike JSX. I happen to think it's a great abstraction that elegantly combines the declarative nature of HTML and the power of JS.

It's always worth noting JSX can and is used in libraries beyond React (hello Vue!) which further demonstrates its composable nature and flexibility.

"Doesn't reinvent the wheel" they literally created a whole new language called JSX, I have 13 years writing JS and I dislike React and JSX is one of the reasons. As far I can tell reason it's picked a lot of times now it's market share, people see that is more popular than the competition so they try to learn it, creating a feedback loop that just makes it more popular.

JSX has been around for 7 or so years... that's a good amount of time. Over half of your 13 years :)

Do you avoid JSX when using Vue or other libraries that support JSX? Are you invoking the library function directly - React.createElement or vue's equivalent instead?

Vue supports JSX, but it is by no means the default. https://vuejs.org/guide/extras/render-function.html

Yes I do, the only language I use for my personal projects is Typescript; I think JSX, .vue, .svelte they are all a mistake, JS is more than enough if you really need to use it to compose html.

    div('#wrapper',
        div('.container',
            span('.big', `It's not that hard`),
            button('.red', {route: home}, 'Home!')
        )
    )

You should give Clojurescript a serious look. You can use that approach, but the resulting code is... well, readable.

There is nothing readable about JSX, "<" will always mean minus-than and ">" will always be greater-than.

I actually like JSX a lot, but I'm baffled when people act like the very thin DSL used by svelte is any more unapproachable than JSX, or like JSX is somehow more javascript when it's a mish-mash of extended HTML (don't forget to use key as needed, and className), React components, and JS (expressions only, not statements... and weird-looking ones at that)

> don't forget to use key as needed, and className

Those are part of React, not JSX itself. Compare Vue's use of JSX, for example, which just uses `class` and `for` instead of `className` and `htmlFor`.

React just went for JS naming of the attributes instead of html naming of the attributes. Reasonable, if annoying, choice.

False, for a lot of attributes you have to use the HTML naming of the attributes, so is not consistent, for example to use aria-label you have to write it exactly like that (not ariaLabel as when using JS)

aria-* and data-* apparently are the exception

More on that: https://stackoverflow.com/questions/52398380/why-react-wai-a...

I recoil from svelte and such because when I see someone trying to invent an ad hoc language inside html attributes I get flashbacks to "transcluding" "directives" of Angular 2.

JSX is a simple transformation of nested JavaScript functions, but the custom DSLs used by other frameworks is string templating, which is kind of an inversion of how JSX works. JSX also has extremely good support in just about every editor and it supports TypeScript, which is not true of every DSL.

JSX isn't a new language, it's syntactic sugar for React.createElement() or whatever other pragma you prefer (like the Preact or Vue equivalents).

Call it what you want, still is the worst kind of syntatic sugar, the one that forces me to use a transpiler but its full of footguns, like being unable to use "class" for the "class" attribute and I have to use className instead, or the one that has no syntax sugar for conditionals so instead you write horrible stuff like {isValid && isApproved && foobar && <div>...}

If you're going to call something a footgun, make sure it's an actual footgun and not simply using a different naming convention than the one you want. You want the HTML name while React uses the Javascript name.

https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...

https://developer.mozilla.org/en-US/docs/Web/API/HTMLLabelEl...

It is a foogun because is only for a few specificic attributes (class) that it uses this specific convention, for other attributes it uses the normal HTML attributes, for example in JavaScript to add aria labels you do stuff like "ariaLabel" when using react you have to write "aria-label" instead.

If you look at library popularity more broadly, you’ll find over longer periods of time only those people enjoy working with actually continue to grow regardless of previous momentum. People really do move on if it doesn’t work well enough for them.

Take React form libraries for example [1], redux-form used to be the most popular by far, was followed up by react-final-form from the same authors so people naturally flocked to that. But that is now clearly seeing a decline as react-hook-form, a library that started from zero, is a lot more pleasant to use.

[1] https://npmtrends.com/final-form-vs-formik-vs-react-final-fo... (set to 5 years)

AngularJS and Angular (what you referred to as Angular 1 and 2) are completely different frameworks. It’s a branding issue, not a technical one. Angular, from version 2 to 15 in the past 8 years, has been completely backwards compatible, and even stayed on the same paradigms. Angular code from 8 years ago looks almost the same as modern code. Which is much more stable than react’s codebase.

>It’s a branding issue, not a technical one.

I mean, for a single version bump (Google called it Angular 2.0) to render not only the code not migrate-able, but the entire paradigms on which the framework was based on is basically unheard of in an enterprise-targeting framework.

That’s an egg-on-face technical fail.

AngularJS and Angular are really the same product. Angular 1 turned into Angular 2 turned into Angular 15. That’s far from different frameworks, even if in between versions you’re essentially learning a new framework.

Vue is more akin to the old way of doing things with static templates (Jinja, Mustache, Erb, PHP), just with a dynamic twist.

React is not perfect, it's bloated, but the reason it took off is that it brought something new to the table as a general and programmatic way to construct UIs. Being a child of Facebook helped it achieve dominance but considering that before React we had angular (shudder) and jquery, React's success was well earned.

React will be replaced when something actually better comes along. The current contenders seem to want to return us to the technology of the past, it didn't work then and it doesn't work now.

Everyone is going back to "past technologies" like SSR, being old tech does not mean obsolete, send html directly to the browser in most cases is better than render them in the client, I think the better approach in theory is the island architecture that I saw on Fresh/deno and Qwik, both feels more like how we used to work in the past, minimal JS send to the client and more HTML send from the server.

SSR never faded and has always been an important requirement. Especially if you wrote SEO sensitive SPA's. We are not going back to SSR but are able to combine both SSR and SPA's more easily, as is indeed the case with dynamic islands and for instance React Server Components.

Not sure if you've worked with Vue 3's "composition API", but it is very different from Vue 2's "options API".

The composition API is bliss.

What's more important with Vue and fine-grained reactivity is that it is very forgiving of mistakes and poor practices that in React would cause much more significant side effects and performance issues.

Vue in general has been a godsend to me at least. When I was in college, we used AngularJS for web development courses at the time. My first job had me working with Qt and Tkinter. When I finally had the chance to do web development again, my team chose Vue and it was so easy to pick up from my AngularJS background.

My current team is using Vue 3 with the Composition API and it is way more forgiving with mistakes than the Options API. I've helped transition 3 developers so far to Vue 3 and they all love what Vue has to offer when compared to React.

Functional components were introduced in 2015. It’s a little worrying if that’s your first example of how React definitely continues to innovate.

React isn’t moving fast. React server components were announced two years ago and are still not available.

That said, as a low-level library it should not move fast; it should make sound design decisions while maintaining compatibility. It’s completely open to frameworks with more opinions and friendlier DX to be built on top of it.

>Functional components and hooks were a huge innovation to class components and significantly improved the ergonomics of the library.

I see this said a lot with particular regard to hooks, and to this day I just can't buy in.

For whatever problems class components have, they enforce a general layout of the component in a way that hooks don't. Reading some codebases that are all in on hooks feels like the wild west and is frankly nightmare-ish to untangle.

> (Vue, Svelte, Angular, Solid etc)

> it embraces JS (no v-for, ng-for, non JS language) and strictly sticks to the idea that the view is a function of state.

So does Solid No?

Are you saying that React is bad because a Junior Developer cannot bother to think about caching or at least open introductory materials before using a framework? If that's the kind of problems you deal with, that makes React one of the greatest framework ever.

The purpose of a good framework is to make developers productive, regardless of their level of expertise.

A junior dev isn't going to be build as fast or as clean as a more experienced dev, but a good framework promotes speed and provides guardrails to prevent mistakes.

To that end my experience with React -- same as the author's -- is that React does not have this characteristic and provides many ways to shoot yourself in the foot.

It's more like React is the MFC to HTML5's Win32. A not very good API with a near monopoly that people spend lots of time wallpapering over with ever more elaborate frameworks that end up being used only for distribution reasons.

It’s a pretty great API, I’d say! The alternatives also have their own warts.

That's a novel take. What justifies Win32's claim to greatness in your eyes? Do you mean by the standard of the time, or even today?

Admittedly I haven't worked on a large multi team react project before but I thought the whole point was that Facebook found React scaled well with teams (vs the state of the art at the time)

Not only can you componentise your UI code, but you can componentise your UI system meaning teams can develop independently of each other...

That's not what I see and hear though. People complain often about how complex things become with React and simple things take a long time to set up or develop, compared to rendering a simple template on the server side.

Usually people are not FB and people often do not have the same kind of strict development rules or enforced discipline, nor are they as many people as FB. Maybe the FB tool is not right for them.

Where React usually gets complicated is when non-trivial state gets involved.

Once you have state that needs to span your application and prop-drilling becomes too much of a drag, the misalignment between React's "pretend we're going to redraw everything" and "I'm only changing this one field in my state" causes most of the issues with React.

Calling React the next IBM is giving React way more credit than it's worth. Sure, basic knowledge of React will land you a frontend dev job pretty much anywhere in the world. However most of that work will be maintenance. If anything React is the new PHP.

Bad analogy. PHP will remain relevant long after React is dead and just a bad memory of the past.