JSX is a nice templating language. And when you use Deno or Bun you can use it directly on server-side. My server-side components have no hooks and use preact-render-to-string or `renderToString()` from `react-dom/server`.
Also there is Gatsby which is a popular content management system which also allow non-interactive statically rendered pages (as far as I remember).
Because of a poor design choice in an otherwise well designed platform (at least in the case of Deno).
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.
eg ``` <ul> @foreach(var item in list) { <li>@item.name</li> } </ul> ```
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).
jsx map accepts a js function which should return a jsx element. Can I use...? If it works in js, yes.
Using Razor obviously did not stop Microsoft from building buggy web applications.
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.
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.
You can also complain about JSON being a mediocre data format. But I think it's minimalism and compatibility with JS made it successful.
One issue in the frontend space is that React has been the default no-questions-asked choice, but my personal vague, no-true-insight feelings are also that you need a technically very proficient team to avoid it turning into a maintenance nightmare.
Many people work for SMBs, and it feels like there's not a great golden path currently for frontend. Doing a something simpler somehow feels like a bigger risk to the people I chat with.
That's not to say React is to blame, per se, but good code is the result of good developer practices rather than some framework.
* a list of elements you can select and delete/bulk-edit is feasible with <form>
* any kind of form with input
* hide/show toggle
* tabs
* accordions
Many single page apps aren't really interactive or require minimal JS.
Currently, we're doing things in JS (like forms, pages, tabs, virtualized lists & tree views, hovers, even buttons with JS click handlers) just because our server does not render HTML.
Might as well just start with the least common denominator that everyone knows and is easily hired for
Completely painted into a corner, I gave up after about six hours of trying to get my event listeners to work with React.
It's a shame, because there's so much server side stuff I could be doing right out of the box with Next, but now I basically need to choose a completely different architecture from the one I want because I thought it would be easier to use jQuery.
In all fairness, direct DOM manipulation works a lot better than React for the original app, but now I have to keep DOM state in sync with my server, which is a whole other challenge that React solves quite nicely.
React does a fantastic job working with common developer principles such as Don't Repeat Yourself, and Single Source of Truth.
Their points come across as overly vague and lack any true insights into development besides initial impressions.
For a static page it doesn't make sense to use React, obviously. For a highly interactive page it, or another framework is critical to clean, manageable code.