> There is a reason why we switched away from template-based frontends (à la PHP).

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.

Frontends became more interactive, and as such, you can't really template that interactivity / reactivity away. Hardly anyone uses Vanilla JS nowadays, and thus, hardly anyone can create a template-based website for today's standards. This is just my opinion though, happy to be proven wrong :)

> There is a reason why we switched away from template-based frontends (à la PHP)

Who is "we"? There are more websites out there written using template-based frontends (mostly PHP) than the other way around.

> So basically PHP, but in Go?

You say that like it's a bad thing ;^)

Then why not <?go ... ?> instead of the random ^ soup?

Please, no. Let's not intermix <> code fragments with <> html elements. Have you witnessed the nightmare of reading and updating JSTL, for example?

Meh, JSP and PHP do this already. JSP is of course <%… %>. ColdFusion does it all the time. It’s easier on the eye, especially with editor support, than having to scan for all those ^ characters.

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…

Why is that better?

Looks like other SSRs. FEDs will thank you.

In real word HTML template are 90% DIVs, 10% generated content.

Internationalization, not every keyboard has ^ easily accessible.

One counterpoint is React is doing gangbusters right now and uses the JSX syntax extension to embed HTML directly into JavaScript or TypeScript.

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.

There's a difference though. JSX embeds html into strings while the way Php intermingles html and code uses global buffers. That makes composition more complicated since you have to deal with nested buffers, flushing, cleaning, etc. I really prefer the way JSX does it over Php's.

Are you equating PHP and Perl? If so, that's incorrect - the relationship between the two is just one of influence, PHP has some influences from Perl (but also tons from C, C++, and Java).

To be fair, you haven't exactly augmented the single-element list [Perl] with a host of languages that I'd consider improvements on writing correct code. ;)

Java, yes, mostly.