On the other side, it's also true that some frontend frameworks are partially moving back to SSR...
On the other side, it's also true that some frontend frameworks are partially moving back to SSR...
Can you elaborate on that reason? Genuine question. As you mentioned in your post, a lot of what newer web frameworks are doing (SvelteKit, Astro, Enhance.dev, etc.) are reminding me a lot of my early days with PHP. The benefits of SSR are widely acknowledged amongst the proper JS frameworks.
Who is "we"? There are more websites out there written using template-based frontends (mostly PHP) than the other way around.
You say that like it's a bad thing ;^)
Anyway, my original comment was a take on “PHP but for Go”, and only half serious. I don’t see myself using the product discussed here. I hear the people who say “I disable JavaScript” but frankly I always write my apps so that the frontend part communicates with the backend via JSON API. I’m not a frontend dev…
In real word HTML template are 90% DIVs, 10% generated content.
To my money, the main issues with PHP had little to do with template embedding and everything to do with Perl being a messy language for writing correct code (coupled with too many people in the era underestimating the importance of "correctness" for HTML rendering when the ability for a malicious operator to mutate HTML on a page can result in all manner of security exploits). Perl just has too many ways to write accepted almost-correct code that breaks abstraction / fails to string-escape in subtle and whole-farm-losing ways.
Java, yes, mostly.