“Mixing code and HTML” a la PHP definitely turned out to be “a very-appealing mistake,” but I don't know that it's right to go to the opposite extreme.

The essential mistake that PHP made was to attempt to completely-merge the output and processing stages. What was good for simple websites (such as were common when PHP was first invented) turned out to scale poorly, and as a consequence of this, PHP developers have adopted templating systems.

I happen to like the approach that is used by systems such as Template Toolkit. This system has a moderately-complex meta-language but it's strictly for output-formatting. The “thinking” comes first, then the output-preparation follows. The two are not interleaved.

In a curious way, I think that the approach you are recommending here does “interleave” these two concerns, in an improper way. It is simply the opposite-extreme: the display-preparation is simply shifted into Perl, and HTML-generation is reduced to a perfunctory, “empty,” non-task.

The advantage of a good templating system, meta-language and all, is that a graphic designer can completely express a display task, given a description of what information has been pre-arranged into what variables. Meanwhile, the programmer can completely ignore that same display task, his-or-her concern only being to get the right information pre-arranged into the right variables. We all know that most “changes” that are requested, once a site has been first delivered, are cosmetic changes... involving a sometimes-substantial rearrangement and re-presentation of the same data. If what we are re-arranging is, indeed, “the same data,” then a suitably-smart templating system works to our advantage since once again it will be the graphic-designer who's doing most of the work. Changes to the underlying Perl-code are needed only for the new functionality, not to re-arrange the old functionality. I am not of the opinion that this “empty” approach would really allow that.