His Scrollycoding framework uses a DSL similar to markdown+xml for the script and generates the webpage from it.

For others who are interested: https://medium.com/hexacta-engineering/didact-learning-how-r... and https://medium.com/@pomber are the articles.

Every single time I look into them I just can't find a reason why I'd ever want to use them over regular HTML and JavaScript. This is especially true in recent years when so many convenience functions have been added to the languages which you'd only previously find in the likes of jQuery etc.

I've looked at framework comparison sites like ToDoMVC.com and the React code just looks so disgustingly over-engineered.

I just don't get it at all.

I personally wasn't sold on JSX until I engaged with it through the lens of TSX. Having Typescript check that my templates make sense and variables are passed in correctly and unlikely to be `undefined` fixes a lot of the problems I've had in most other ways to template HTML.

As for styling, yes I'm also a big fan of letting CSS cascade, be the province of the designer, if possible, and that templates and scripting should focus on CSS classes and good selectors over inline styles as much as possible.

In JSX/TSX you can get some of the same linters that warn "no inline styles" even if using off-the-shelf React. Some projects turn those off for "CSS-in-JS" alternatives or Tailwind, but those are still options that I find uncomfortable. In my opinion: good templates produce good markup that a designer can use the "Cascade" in CSS to do wonders with, and components shouldn't need to micro-manage their own styles.

When I built my own React-like library with TSX I was also sorely tempted to remove inline styles and/or binding changes to them, but eventually was convinced that there are still some things that are more convenient that way (including if you are copy/pasting someone else's components or vanilla JS code). My library tries to stay "close to the vanilla wire" so to speak, so I needed inline styles and style bindings just because otherwise it would be done directly to the DOM object anyway, vanilla style. So in the end I was convinced to include them, but it was definitely something I thought long and hard about as someone who believes classes and the Cascade should be the first tool to hand, not inline styles.

For styling, there has never been a requirement (or even, really, an incentive) to style your elements directly in JSX. It's possible to do so but you're just passing through inline styles to HTML.

For "the province of the designer," do you mean the designers of your sites are writing all the HTML and CSS themselves? I do not think that's the province of the designer personally, but it may be an older school of thought (I only started my career in the age of React). When writing in JSX, they truly can become thoroughly intertwined, as the structure influences the styling and vice-versa, and code can control either of those other options. I find this complex, but quite reasonable. The majority of the time it's actually just straightforward.

The two are so ridiculously intertwined. It’s already a problem within CSS, where layout systems and styling are mixed. Flexbox and grid have nothing to do with colors and gradients, which are again themselves orthogonal to positional properties. Fonts, paddings and margins (in 15 different units, look it up) add to the insanity. Now sprinkle in animations, box models and borders.

There is a separation of concerns when using react but it’s not split by technology but by responsibility. A react components is an isolated piece of the puzzle which’s concerns are separated from the other puzzle pieces.

I just hate the fact that it requires JavaScript to render even the simplest of pages. I would be bold enough to state that most websites built using React have absolutely no need to be built with React, i.e. they should be using plain HTML/CSS and maybe a tiny bit of JS instead.

Instead we now have an entire ecosystem where JavaScript powers everything, even the rendering of the most basic static page. And have you seen the markup generated by React and its ilk? It's horrific and makes debugging/modifying pages using client-side tools (user scripts, accessibility tools etc.) much harder.

It's anathema to me. I hate it all.

I completely agree with your point that most sites could easily just be static HTML and we would all be better for it, but React does not generate any markup beyond what the developer instructs it to.

A lot of the hate modern JS frameworks get is actually the result of so many web developers having poor HTML skills (and, if I’m being honest, poor development skills all round). Nothing inherent to any JS framework is responsible for div soup.

You can construct clean semantic HTML from React just as easily as you can hand-write crappy HTML directly into a file on a server.

If you don’t want to use inline styles, then don’t use them. Though even if you use a stylesheet, they are still essential for setting CSS variables.