Contrarian take: the whole field of front-end frameworks seems to be lacking an all around good isomorphic solution to me.

Is there anything that would out of the box: 1) do fully static server-side rendering that outputs zero JS by default, 2) still be capable of rendering client-side interactive components where appropriate (for user agents with JS), 3) have both of the above as equal first-class citizens without contrived workarounds needed to achieve either interactivity or SSR, 4) handle all required bundling/fetching at build stage and load fast at runtime, 5) be isomorphic and leverage TypeScript typings to validate the correctness of the whole thing at build time as much as possible, and ideally 6) allow easy reuse of preexisting React components?

Another comment already mentioned Svelte. Alternatively, Hotwire Turbo or htmx might be more along the lines of what you want. Choose your own server-side language. I sprinkle in fancier frameworks when individual components need it, but this is more the exception than the rule.

https://turbo.hotwired.dev/ https://htmx.org/

I'm using Astro + Svelte for a small project right now, and it sounds like that's the combo that you're looking for.

Remix (https://remix.run) comes awfully close

Try ts-liveview (https://liveviews.cc) if you like JSX and querySelector without VDOM

Ooh, ts-liveview looks really interesting! Thnaks for sharing!

Take a look at Qwik

https://qwik.builder.io/

Remix.run

The biggest difference is that it uses tags/components as a means to mix markup and code. (the "old" server-side language ColdFusion does this same thing)

Remember when PHP was supposed to be that?

I still slip <?php> tags straight into inline html a la 2004 from time to time, when it suits the purpose. I even occasionally use href="javascript:" if it saves time. No shame in using what works.

It's not clear to me why a subset of PHP with an extremely fast compiler isn't available/common. That's what it's designed for...

People plug-in all sorts into python, why not `from microphp import tpl`, `tpl("blah.phtml")` etc.

    <html..> 
    <? foreach($xs as $y): ?>
        <? $y; ?>
    <? endforeach; ?>
    </html>

PHP is pretty fast already if you use it that way, and don't bury it under 20,000 layers of recursive framework callbacks like wordpress etc. does.

But dedicated template languages have superior ergonomics these days, so why bother adapting PHP to it?

templates are always limitations, my friend. albatrosses. You're so right about the awful structure of the big CMSs...

I've just used my own RYO CMS for 15+ years for website work... it's gone through lots of updates, but it's super simple. I'd never make it public as a framework because any decent dev should be able to roll their own anyway, and I don't need the aggravation. But it's basically a VERY simplified cross between {{handlebars}} and React, without attempting to bind the whole DOM to data, plus a DSL for specifying all the pages and modules of each website in SQL, and setting up english-language router rules.

I'd ditch ergonomics any day for understanding what's going on and being able to pare it down as much as possible. Simple website clients pay so little these days it's basically charity work... you need something you can both do in an hour AND never have to worry about WordPress updating.

At least in Python, that's kinda what https://www.makotemplates.org is. Although if you're just using a subset of PHP suitable for templating, it's not really clear to me what benefit there is to PHP syntax versus, say, Jinja2 syntax.

the whole thing with PHP, originally, was you just wrote HTML pages and slipped in PHP <? echo $hello; ?> code here and there where you wanted the server to fill something in with server-side processing as the page was served. This is how it was used before it became common to generate whole templates or pages out of code. You'd be serving a basically static webpage and have a counter at the bottom showing hits, for example, so you'd take your .html and rename it to .php and the counter would be tagged to be generated by the server but everything else would just be plain HTML. PHP still supports this and the fact that it evolved into a full fledged language where you generate HTML from it (as opposed to embedding its output in static pages) still seems slightly humorous to me.

This is close to Twig syntax, and Twig is pretty much the defacto standard for writing templated PHP.

PHP with a correctly-configured server is about as fast as web-oriented scripting languages get, in practice. Yes, including Node. To be sure to beat it you'll need to switch to something compiled, and then take great care not to make any mis-steps.

The ease of deployment alone keeps me going back to PHP, but the speed is nice too

If I'm in a hurry I still just use the fucking <center> tag. It works and I can't be bothered to google what's correct this week, if I'm just dipping into HTML for a minute or two.

ColdFusion is an interesting referent ... even as an Adobe subscriber I was surprised to just find out it still exists.

Not as popular as it used to be, but definitely still around. The open source version (Lucee, formerly Railo) sees a lot of use as well. As for Adobe, I think it's treated as a step-child they acquired along with the rest of the Macromedia IP. I've actually been to trade shows where one part of the company was there and they didn't even know what ColdFusion is.

I would so love if Adobe would just spin off Macromedia again. I remember working on Flex frontends with CF engineers in the early 2000s and ...I mean, there is no reason that couldn't be updated to be a killer framework now if it worked with modern stacks.

Not surprising, but sad that Adobe flacks don't even know what it is. The world would be a lot more interesting if Macromedia was still a going concern, maybe aligned with Unity or some other ecosystem for game production.

>maybe aligned with Unity or some other ecosystem for game production

I think I recall Flash did try to offer some type of iPhone app development features towards the end of it's useful life but Jobs effectively sentenced Flash to death so most everyone had jumped ship by this point.

We built some games in Flash/Air that compiled to native iOS apps... they basically bundle the whole flash player into the game. It was and still is a working way to make an iOS game, it's just that Adobe no longer supports the plugin version... and you can't really trust them to support anything else going forward, so most devs moved to other languages and stacks like Unity.

ColdFusion is quite useful for internal (intranet) data search and reporting apps/pages that don't need lots of JavaScript eye-candy nor layer-happy frameworks. It makes it easy to stick hyperlinks in HTML data tables so managers can click to drill up, down, and all around to study data from different dimensions. There's also an open-source implementation or two, although I found the charting tools of the commercial version to be more mature.

I'd much rather use ColdFusion than Microsoft Power BI, if I had to choose. (MS-BI is probably a better fit for non-programmers.)

It's a whole weird world that just doesn't die. I worked at a place with ~ half a million lines of CF last year. There is a thing called CF Script which has vaguely JS-like syntax which can be used instead of the XML-based logic. There are even open-source frameworks built on top, with religious quotes in the documentation for some reason[0].

[0] https://github.com/coldbox/coldbox-platform

I know Luis, the creator of Coldbox. It's a great framework, and the quotes reflect his personal values, but other than finding that in the documentation, you won't find yourself being beat over the head with scripture. In years past, there were several other CF frameworks, and none could be characterized as having religious quotes, just the one :-)

> My personal website has about 30 lines of javascript, no framework and no library.

"my use case doesn't need a JS framework so we don't need JS frameworks"

That's not what they said.

That's pretty much what they said. Most programmers don't work on "personal websites" at their workplace, as strange as that might sound.