Developer experience writing React is much nicer than using other markup languages. That's why I use it at least, the fact that it spits out a fully JS-free website at the end is the icing on the top.
Nothing about the developer experience of React seems better than any old HTML template language (and hardly better even than plain HTML), if you're not doing any interactivity and are just going to render once and spit out the HTML.
Have you used React before? It's miles above HTML templating. I honestly don't use frameworks that have regular templating anymore, like Vue or Svelte.
I have used React. I'm a huge fan and I also prefer it over its most common "competitors" like Vue and Svelte.
But React (like Vue and Svelte) are fundamentally about interactivity. If I had a project where I knew for sure that I only wanted to generate HTML sans JS on the server (or with a static build process) I wouldn't even consider using React.
It barely even makes sense. Your "React components" would just be JavaScript functions that take props and return some JSX. None of the interesting React features and hooks would even make sense, other than maybe context (and presumably most or all popular static HTML templating tools have comparable features).
Yes. JSX is nice for escaping by default but encourages total spaghetti coding hiding app logic in the templates and various footguns like non-standard attributes className and breaking id. Running it on the server side mitigates the React performance hit somewhat but the selling point is interactivity.
What are you referring to? I am unaware of what “regular” templating you’re referring to or what react is achieving that is not available or cumbersome under react or svelte.
Think of JSX as a macro, rather than "regular" templating, which is typically string substitution.
For static sites, this means that you get functions and objects the entire way through the render pipeline right up until there is a full tree built and the final output is rendered.
You still get all the separation powers of contexts, the component based reusability, etc, and it is all regular JavaScript / typescript except for the JSX macro itself and React's APIs (which are just JavaScript). Conversely, with templating engines like handlebars / erb / et al you need to learn the specific DSL of the template engine- custom loops and controls, imports for partials, and your custom helpers are limited to what they can do. Even Vue's render function has special markup for control (v-if, v-else).
Some day we have to stop repeating this nonsense. JSX requires much more learning than simple templating, there is no inherent benefit. Even a simple conditional is more complex than your average template.
How so? Any expression is valid within JSX- ternaries, function calls, binary and unary operators are all valid. If you know JavaScript, you already know all of the control mechanisms that are valid.
The thing is, if you know JS, then a conditional is JSX is the same as in JS. Contrast that with every new templating language under the sun which might have its own way of doing conditionals and loops and control flow. That to me is much more annoying.
> Nothing about the developer experience of React seems better than any old HTML template language
Is that a joke? You get autocomplete from typescript and props to be fully typed functions, or any kind of object for that matter. That compares to autocomplete that's just some ad-hoc, bug ridden tools that locks you into some IDE or editor, and who cares because all the attributes have the same type (string) anyway.
and what's your experience writing other markup languages that you base this statement on? I can definitely agree it is nicer for a data intensive sites, and with effort can be made somewhat equivalent in most document heavy sites, but there are definitely some scenarios I've encountered where the match of technology to use case was disastrously not in React's favor.
Specifically I can think of parts of the websites' functionality is editing highly technical structured data documents by highly trained domain experts.
I mean basically where years of developer productivity was thrown down a React hole when it could have been months in SGML / XML based tooling for what was required.
I can say that because I have built big solutions in both stacks, though.
I've used many, Handlebars, Pug, Vue's, Svelte's, Zola's, many. They're all somewhat similar in that they try to recreate loops and conditionals, all without strong type support unlike in JSX. I've never used SGML though, another commenter told me that it is more powerful.
You have to be joking, surely? React/Vue as a mere static template languages? Dedicated static site frameworks such as Jekyll and Middleman are a much better experience. My favourite is still Perl's Template::Toolkit.
TypeScript, that's the differentiator. Having fully typed variables in the templates cannot be replicated in templating languages (well technically they might be able to but that's not as ergonomic as fact).
Talk about sledgehammer to crack a nut - honestly, why does anyone need type safety in a simple templating operation? Dynamic languages have their uses, you know. Type safety is a tool, not an ideology.
because it's nice to know whether that `post` variable contains a property `createdAt` or `published` At without leaving the template. Arguing "I don't use it why should you" is unproductive.
Agreed, you get all the benefits of type inference even in a template. It's a pain to debug template variables that don't exist, I've written enough Handlebars to know.
I basically never use dynamic languages anymore. If there aren't algebraic data types in a language I simply don't use it. Sometimes people think I'm exaggerating but it's truly great to use a language with ADTs that you get spoiled.
I like using Nim or Rust, or TypeScript, depends on the script. If it's just a few lines, sure I'll write it in bash, but if it gets a little larger, I convert it into a real programming language.
For sure. I'm a big fan of type safety in larger codebases with reasonably stable domains. But when a project's small or new enough to be relatively volatile, the overhead just isn't worth it for me.
There are "templating languages" such as SGML for generating type-checked markup ie. respecting the regular content model and lexical types expressed in DTDs and other markup declarations. This results in injection-free, HTML-aware templating ie. templating engines can properly quote/escape content in attributes, CDATA sections, etc. and can enforce content model rules (that eg lists consist of nothing but list items, that script elements aren't placed where forbidden as would be required in user content such as comments provided by your web site visitors, etc.) Much more powerful than programming language types, and needed in CMSs.