JS is missing switch/match expressions, that's pretty much all IMO.
And I commend the maintainers of JSX for refusing to extend its syntax.
JSX can be learned in 15 minutes and it is a macro usually used to wrap React.createElement.
You could just as well swap your bundler plugin and use some other type of macro, e.g. sth like Mithril's m.
JSX is a very slim basic concept and I don't know a single gotcha except for the renamed attributes/props that are otherwise reserved keywords (htmlFor, className).
That you can use/see it as a templating language is just a part of its appeal.
I loathe having to use dedicated templating languages, having worked with Mustache and various PHP templating languages such as Blade and Twig.
Maybe "loathe" is a strong wors because most of the time it's easy and just works. But when it doesn't, debugging is a nightmare.
Escaping rules and questions like "what is code, what is a just an uninterpreted string" become unpredictable, and you have to learn useless baggage for each of them.
Same goes for all the JS DSLs using HTML attributes (Vue 2 "templates", which are actually not templates, etc). This is also what turns me off about htmx.
It'a great to throw together a specialized solution for one problem, but not great for libraries inventing unnecessary proprietary languages.
>don't know a single gotcha except for the renamed attributes/props that are otherwise reserved keywords (htmlFor, className).
This is related to `React.createElement`, I think. Preact does not have this problem. For client-heavy web applications I prefer React over Preact (not all libraries work well with Preact), but server-heavy web applications are fine with Preact.
ts-pattern has been a decent band-aid for the lack of native pattern matching, but obviously has downsides that could be avoided if it was built into the language.
That's true. It's missing "a ton of features" but the question is, if these missing features in the template language stop us from building correct and maintainable web applications. Having that said: We are fine with JSX.
Using Razor obviously did not stop Microsoft from building buggy web applications.
I had no idea what Razor was (I'm not a C# guy, I don't like to work on mediocre platforms... (see what I did here?)) so I read about it a lil' bit and could not find a single thing that it does that JSX cannot. Not one.
I suspect they want better condition handling. Because JavaScript lacks a useful conditional expression beyond ternary expressions, condition handling in JSX generally uses boolean operators or ternary expressions. Suppose the conditional logic is in any way complex. In that case, your choice is to use nested ternary expressions, which can be hard to read or to somehow break the condition out of the JSX using a helper function or separate component so you can use if statements in a regular function context. SolidJS added conditional helpers to its JSX flavour to address this issue[1]. The React team seems ideologically opposed to the idea as it presumably moves JSX away from using only JavaScript for handling logic.
>I suspect they want better condition handling. Because JavaScript lacks a useful conditional expression beyond ternary expressions, condition handling in JSX generally uses boolean operators or ternary expressions.
If a condition in JSX gets too complex I normally extract a component-level function and call it from the JSX part of the component.
knowing both i used to be frustrated by jsx's lack of support for plain if and for loops like razor has (eg map and the weird && syntax we general end up with)
of course this idea goes against jsx's implementation (as it's just nested functions) and paradigm of being html in plain javascript rather than an interpreted templating language.
some of the differences i really like (like being able to assign compoents to variables, pretty sure razor doesn't have anything like that).
