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.