Fair, this instance is 100% noise imo.

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

We also should be responsible for avoiding bad patterns like what this article calls out - throwing from state into react state. It's 100% not necessary.

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.