[KronisLV]

The whole point of the parent comment was that it doesn't, at least when you want to be able to experiment and iterate quickly:

> It is the purest form of web programming. You don't need a framework. Spin up a server and just start writing. Experiment. Do crazy things with it, like an art project. Every page is it's own world. Have fun with it.

Why would that be a bad thing? Even when it comes to something like REPLs, everyone always touts being able to iterate more quickly as a good thing, don't they?

Edit: aside from the implications of an in process language runtime, that was discussed in another comment.

[JimDabell]

Why are you talking as if embedding server-side logic in HTML is necessary to experiment and iterate quickly? I can get up and running with a Python project in seconds and can iterate quickly with that.

“This is good because it enables you to iterate quickly” isn’t a good argument when you can iterate quickly regardless.

[KronisLV]

> Why are you talking as if embedding server-side logic in HTML is necessary to experiment and iterate quickly?

Necessary? Not quite.

But having those things be closer together leading to faster iteration? I'd argue that that's definitely true, same as how someone could skip out on writing a bunch of enterprise programming patterns, MVC or even tests, as well as use a language with a dynamic type system, or even write serverless functions. Not that any of that is very maintainable long term, but at the same time nobody would expect that from something that's very much like a REPL.

It's the same as how I like to have a clearly separated front end (typically a SPA) and a back end API (something RESTful) in most cases so that those technologies wouldn't be coupled and the API could be re-used as necessary, except that people who go for the various SSR and templating approaches typically code around me in circles, because they don't have to write as much API client code as I do.