> JSX is a gotcha-riddled kludge to clumsily shoehorn HTML into a JavaScript function return.
Oh boy, now that’s some flame-bait. I don’t like JSX, and like the Author also prefer Vue over React, but I know a lot of people simply dislike other frameworks *because* they don’t have JSX (or, as is the case with Vue, it’s theoretically possible but no one uses it).
> I know a lot of people simply dislike other frameworks because they don’t have JSX (or, as is the case with Vue, it’s theoretically possible but no one uses it).
Count me in that camp. My take is that while JSX isn't perfect, it's less of a cludge (and much more flexible because it compiles down to JS) than the templating languages that other frameworks use. I'd love it if they'd add just a little bit more sugar to JSX though. Support for JS-style comments would be top of my list.
Mine doesn’t work very well in JSX blocks. Partly because I don’t think there is any way to insert a comment inside a JSX tag (to comment out an attribute).
Yep, I've recently used Vue instead of React and I hate the magical templating system. Slots, magical rules for variable scoping etc. The templating is IMO way worse than JSX.
I don't care for React one bit, but IMO JSX is the highlight of React. Everything else in React is pretty much just OK at best (and some not even that), and the development of React itself has been extremely slow with very relevant few features.
+1 As someone who never runs into problems with JSX, I have definitely wondered if the criticisms against JSX/React are from people trying to use it in ways that are explicitly counter to its core philosophy.
The great part about JSX is some random new framework doesn't need a VS Code plugin to get syntax highlighting, and type checking Just Works.
I can accept a template language for a major framework where I can count on decent developer tooling, but it's a hard turn-off when evaluating niche frameworks.
Definitely not. They’ve always been explicitly implementation-agnostic (literally specified as not having any semantics). An increasingly popular JSX transform (used by Solid) has very different semantics. JSX semantics are more like an s-expression than anything else. Code as data, you can do anything with it you like. I use it to make art and render that to meta links on my personal site. You can use it to render CLIs, or even JSON responses on a server.
Not necessarily - bunch of languages have adopted JSX with slightly or substantially different component semantics from React (for example Vue, Solid, Forgo, Crank).
A Crank component (which is an async generator) feels very different from a React component. Likewise for a Forgo component, which uses closures for state and doesn't have automatic rerenders. Solid doesn't have components in the traditional sense at all.
Although the syntax they use for representing HTML is the same, the rest of the framework can have arbitrary design.
Maybe I haven't tried hard enough, but it was a pain doing JSX/Typescript with mithril. All the TSX tooling expects a React API and if you use something else you get a ton of annoying type errors.
I used TSX with Cycle.js for a while and didn't experience too much trouble. Typescript has some simple compiler options to change how it generates JSX or JS and doesn't bundle any types out of the box for TSX: all of the React API types come from React's type library. Sometimes that was more of detriment than if there were base types in TSX because reimplementing mostly the same set of standard HTML elements and HTML-like attributes a third time in a different .d.ts file when switching VirtualDOM implementations was a chore. (It was fine, but it was a chore.)
If you are seeing errors that are React specific, most likely means you just need a subtle tweak in your tsconfig.json.
Oh boy, now that’s some flame-bait. I don’t like JSX, and like the Author also prefer Vue over React, but I know a lot of people simply dislike other frameworks *because* they don’t have JSX (or, as is the case with Vue, it’s theoretically possible but no one uses it).