You could have some client side JavaScript handle your for nodes as well. That's how I imagined what OP described actually.

> Nobody uses PHP this way any more though

Well… I have bad news.

I do, for one :-)

I ask you then: (1) how do you deal with the template that surrounds a large number of pages on a site? (2) how do you deal with the fact that the average web form might want to display something different based on the form contents (e.g. redraw the form if there's an error, draw something different on success?) (3) do you write anything that returns JSON or other results for AJAX or web services?

(1) What about it? (note that I don't manage websites with a large number of pages)

(2) It's easy to add if conditions that test $_GET, $_POST or $_REQUEST display different things depending on what was submitted

(3) Not often (but have in the past, and will probably have to soon in a personal project). What issue are you anticipating?

(1) It's a problem if you have 2 or 3 (never mind N where N is large) different web pages that have the same stuff at the top of the bottom. I mean you can have

  <?php include("header.php") ?>
  ... body ...
  <?php include("footer.php") ?>

but...

(2) ... in either case it is just as easy to write

  <?php
  ... some "router" that tests $_GET, ... to set $body_file ...
  include("header.php");
  include($body_file)
  include("footer.php");
  ?>

where you have the option of putting headers on before you include header.php, showing a different header or footer conditional, etc. This approach is structurally stable and scales with the complexity of your application no matter what you're doing...

(3) ... for instance say you want to write a page that might return a different format depending on the headers, the router can return JSON if that is called for, or XML if that is called for, or HTML inside the site's global template if that is called for.

I'll use (1) for when I have a restricted set of pages (say, the usual pages of a site, like home, contact, about ...); body is not in a separate file; and (2) when the number of page is dynamic, say, a site that displays recipes stored in markdown files.

(3) I don't know yet for sure how I'd do it today (I will soon normally), I suppose I would just write different scripts, that can call some shared code. For APIs, people expect something that looks like REST endpoints and I suppose I would return JSON or XML in REST endpoint, but the URL structure that looks good for REST wouldn't for a normal page.

If HTML was never able to be the full solution, then I guess if I had to expand on where I'm going, then what the heck are we even doing with this html thing? Either MAKE IT like PHP, ditch it, or do something, anything.

HTML is perfectly able to do what it was designed for: mark up documents.

There still needs to be something like HTML even when you have PHP: PHP is something you run on the server and it still needs to output something to the client in some format, and HTML is adequate for this.

The heck we are doing with HTML is taking it for building client apps. But even then, you now have UI toolkits that mimic this model: QML, whatever XML format Android has to design UIs, etc.

> Either MAKE IT like PHP, ditch it, or do something, anything.

Do nothing so I can make websites that are accessible, secure, static and fast. HTML is the full solution unlike PHP or JS. With CSS it’s Turing complete.