[lucideer]

This seems intuitively right but doesn't really result in good outcomes in practice (I'm curious if you have any concrete reasons to justify saying it "was always a bad idea").

In practice what I've found is that HTML is fine/optimal for event-driven interactions layered onto entirely static content, but for inherently interactive UIs, what ends up happening is you get one of two systems:

1. If you start from a HTML-forward standpoint, you can go a certain distance separating your concerns entirely, but at scale the drawback is maintaining disparate references, negatively impacting code colocality: having to edit a reference in three separate files in a repo is incredibly bad for DX and readability. To overcome this, a common approach is to make the JS side generic by embedding DSL with dynamic functionality into your HTML: the worst of both worlds, creating both a Frankenstein HTML+weird-extras language and still needing to bundle JS with it.

2. If you're starting a greenfield project with the early intent of having a fully interactive UI, instead of growing into it, you can avoid the above mess and architect your project from the offset with good code colocality by embedding templates for highly dynamic/transient UI components into the imperative part of your application logic (i.e. the JS).

[ttfkam]

Svelte is neither a Frankenstein nor incredibly bad. In implementation, the compiler is JavaScript and there is JS bundled in the output. However, the developer experience is comparatively indistinguishable from plain old HTML, CSS, and JS in a substantially similar form to a static HTML page to the point where vanilla JS libraries can bind to HTML elements without modification. This is in fact how I develop for Svelte: I start with a static page, put in some elements and CSS to look like my design target, drop them into Svelte largely unmodified, and add if/each/await control flow.

I have yet to find a greenfield React project with more than a few developers over a few years that didn't turn into a big ball of mud that only the original developers could understand (at best). State management alone on React is an utter, total, and indisputable shitshow. Codebases with a mixture of classes and functional Hooks are far from ideal for developer experience.

Svelte code by comparison is a breath of fresh air both to develop as well as maintain. Whether Svelte wins or something inspired by Svelte does not matter as much to me as something that takes away the inverted JSX model, the virtual DOM, and allows the use of vanilla libraries without React wrappers interfacing with other React wrappers.

[lucideer]

> Svelte is neither a Frankenstein nor incredibly bad.

"bad" is subjective I guess but "Frankenstein" can equally be applied to ".svelte" & ".jsx" - both are non-standard amalgamations of imperatives with markup. In my mind the qualitative differences here end up being in parser support (jsx as a js language extension, svelte as... I'm not sure... not quite a HTML extension but closer to it I guess) and output consistency: this is either dynamic output by the node server in Svelte's case, or perhaps a multifile static bundle with Sapper/SvelteKit; that bundle taking various forms depending on your bundler chunking plugin configs, etc. JSX in contrast is a line-by-line one-to-one simply defined translating to basic native JS render calls: it's eminently auditable and will work with an infinity of preexisting testing/parsing tools that support basic JS.

> I have yet to find a greenfield React project with more than a few developers over a few years that didn't turn into a big ball of mud that only the original developers could understand (at best).

I've seen this with Svelte and React in relatively similar measure (I've seen hundreds of large React projects, some elegantly structured but most a mess. I've seen <20 large Svelte projects, all much much younger, all but 1 a complete mess). All in all this is a problem with the development/developer landscape and not either individual project dependency. Contributor scale is a hard problem.