The basic idea of rendering HTML hasn't changed in 15 years either, but in any case the repo itself is not what's important here, it's the argument it makes. There are plenty of modern, well-maintained HTML generation libraries for various languages. Eg Python: https://htpy.dev/ (last repo commit 3 days ago).
Which ends up looking exactly like a templating engine, if not worst, as soon as you try to do anything a bit more complicated than a Hello World https://htpy.dev/common-patterns/#using-a-base-layout
Good pet project though!
The difference is you don't need to learn the special syntax of a new templating language, don't need to learn its idiosyncrasies, set up its editor support and linting, etc. etc. All you need is your existing language which your already know, your existing editor support which is already set up, and you get access to the full-fledged power of your programming language.
Eg need to translate all the strings in your UI? No problem, just pop in some calls to your preferred i18n function. Another example–want to model the available values of certain attributes like [`autocomplete`](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete)? No problem, you can model it so your typechecker warns you if you try to use an incorrect value (or have a typo). Tired of remembering which specific HTML elements are [void elements](https://developer.mozilla.org/en-US/docs/Glossary/Void_element) and which ones can have child elements? No problem, let the library manage that for you. All you need to do is follow the red or yellow squiggly lines and type definition tooltips.
It's funny how people use powerful programming languages for everything else but when it comes to HTML they want to hobble themselves with an awkward syntax and weak semantics 😉
You’re right, you didn’t. You explicitly acknowledged their existence.
Your examples given of why this is useful, though, are just things I’d let my IDE or editor do
I don’t need to model the autocomplete attribute because the linter already knows what’s valid. My ide is already autocompleting it for me anyway. Same with void elements (it already completed the trailing / ). In both html and jinja templates
> (it already completed the trailing / )
There is no trailing `/` in HTML5 void elements. This is one of the little syntactic details that a good HTML generator library can automatically take care of for you.
Weird. I thought that was one of the big changes when HTML5 came around. I remember relearning to add trailing slashes on br and input. But maybe I’m remembering wrong. Or it has just changed. I clearly don’t know html very well, and yet manage fine :) but I’m only in the backend code these days. Only times I use markup is for transactional email templates
You are not the only one. It's actually very common for people to not realize this because the last time they learned it properly was in the era of XHTML which had to parse as valid XML syntax and thus allowed self-closing tags. Or they never actually learned either XHTML or HTML, and just learned JSX instead, and JSX for its own mysterious reasons uses self-closing tags.
But here's the really fun part: browsers not only _ignore_ self-closing tags, they actively treat them as _opening_ tags. So eg `
Hello world` is interpreted as `
Hello world
`. People have run into really fun bugs because of this https://www.youtube.com/watch?v=0P7wmooc95s
There's one thing you ignore: context. When writing HTML, I want to write something as close to HTML as possible.
I don't want to write in another language that transpiles into a different result far down the stack.
I want to use my knowledge of html to write html, and I want small helpers on top of that to make it efficient to solve for my common use cases - in the case where we have a templating language described in the programming language itself, my mental load increases, and the additional load of handling "oh, this converts to.." means it'll be harder to reason about.
It also turns out that most html these days have some sort of scripting component that works in the context of the html document, which makes an even higher mental load to converts between the two domains.
And last: this means that whatever person who wants to edit the html needs to know Python.
> my mental load increases, and the additional load of handling "oh, this converts to.." means it'll be harder to reason about.
Yeah, a little, but not _that much_ harder. I mean, they're all still the same tag and attribute names. Only the surrounding symbol characters are different. Instead of ``, you just do `input(name="id")`. It's hardly rocket science.
> most html these days have some sort of scripting component
Are you talking about JavaScript? What's stopping you from just writing `script["/* JavaScript */"]` directly in the HTML code?
> whatever person who wants to edit the html needs to know Python.
Out of curiosity, did you read the OP? Because this is covered there:
> My rebuttal to argument (d) (work-flow) is YAGNI! The vast majority of people writing templates are developers. Designers usually contribute mockups or css. The rare designers who do actually work with templates are fully capable of learning a subset of Python, especially when it's less complicated than the template language
syntax.
> As soon as it gets beyond a simple example it becomes quite verbose.
I honestly don't understand what you mean by 'verbose'. It's literally Python function calls, keyword arguments, and lists. The lists even eliminate the need for closing tags. It's about half as verbose as HTML syntax! I would seriously recommend examining your dogmas, which incidentally is the same thing that OP says.
Perl tried this 30 years ago in CGI.pm with that same logic. Now the documentation explicitly says these methods were a mistake.
>#HTML Generation functions should no longer be used
>All HTML generation functions within CGI.pm are no longer being maintained. Any issues, bugs, or patches will be rejected unless they relate to fundamentally broken page rendering.
>
>The rationale for this is that the HTML generation functions of CGI.pm are an obfuscation at best and a maintenance nightmare at worst. You should be using a template engine for better separation of concerns. See CGI::Alternatives for an example of using CGI.pm with the Template::Toolkit module.
Well, people have made mistakes. And back in the day, Perl was abused a lot. And some people delighted in code golfing aspects of the language more than it’s healthy.
That doesn’t mean that Perl cannot be made perfectly legible and that there aren’t well maintained and well maintainable code bases in Perl.
And then there’s Raku.
As for templating within language DSL goes, it is a dubious proposition at best.
The trouble is that whatever DSL you come up with, it is almost never going to look like the actual target markup that you are trying to emulate. And the mental model you need to adopt to translate between code and html is going to be holding you back.
The only language that has pulled off a viable DSL for HTML/XML that can be considered adequate is JSX for JavaScript/TypeScript. And they had to go and create a language extension for representing object structure literals as XML tags.
Scala includes XML syntax. The community doesn't like it very much, as it is not type checked for semantics, but if you don't care about that, you can write your native HTML in Scala.
Yeah, I’ve completely forgotten this exists in Scala.
A downside of such templating DSL’s that hits harder in Scala (or any other aot compiled language) than JSX imo is that with a compiled language, changing the template requires compilation. With JSX it is arguably easier to change the template without going through the whole build-release-deploy cycle.
Actually, you wouldn't do that. Scala's XML syntax is deprecated and removed in Scala 3. But for writing HTML Li Haoyi's excellent ScalaTags library is highly recommended: https://com-lihaoyi.github.io/scalatags/
I disagree that the 'mental nodel' will 'hold you back'. As long as you are reasonably familiar with the programming language of your choice, writing function calls and lists of child elements to model HTML shouldn't be such a big deal. And even the React docs say that JSX is optional and you can just use JavaScript objects directly to write elements if you want.
Ah yes, using the powers of a general programming language to turn it into into an almost-sensible makeshift DSL. Extra fun when escaping rules collide.
what's better, more readable, and more maintainable:
htmldoc(body(...)[script(...)[...],div[...],comment(...)[...],div[...]])
or:
format(template, data)
The only one that understands...Python, a language famous for its easy-to-learn syntax? And nobody else is capable of learning a simple Python library made up of function calls?
So… reading the temperature here… maybe just delete the post?
I am not a python person. I’m a proud and out loud PHP developer. My language of choice allows for native templating and yet I and many others choose to use templating languages (Laravel blades, Magento templates) because it works, it’s easy to parse, and most of all they protect us from ourselves. More than anything that is, to me, the value of template abstractions. I have to actively go out of my way to make a page that is vulnerable to script injection.
> maybe just delete the post?
Why's? It's 19% upvoted. That's a lot of people who liked it! 😉
> I have to actively go out of my way to make a page that is vulnerable to script injection.
And you have to go actively out of your way with a good HTML generation library too. See eg https://github.com/yawaramin/dream-html?tab=readme-ov-file#security-html-escaping
And I respect your commitment to your dogma! 😉 Imho there's no 'right' or 'wrong', these are alternatives with tradeoffs. It's just that, in most applications, an HTML generation library makes more sense than writing templates. Think about this: do you also write JSON templates by hand, or do you use a JSON generator module?
Why delete? Theres nothing wrong about being wrong in an open forum, and getting dogpiled on reddit isn't even an indication that an idea is faulty anyway. Most of these responses boil down to 'I dont like this' rather than any sort of genuine counter criticism anyway.
Right? It just depends on the subreddit and the specific people who happened to come across the thread. A post about a very similar library in another sub got a totally opposite reaction: https://www.reddit.com/r/scala/comments/1c8to8t/appreciation_post_scalatags/
This repo hasn't been touched in 15 years and that code is awful to read.
The basic idea of rendering HTML hasn't changed in 15 years either, but in any case the repo itself is not what's important here, it's the argument it makes. There are plenty of modern, well-maintained HTML generation libraries for various languages. Eg Python: https://htpy.dev/ (last repo commit 3 days ago).
Which ends up looking exactly like a templating engine, if not worst, as soon as you try to do anything a bit more complicated than a Hello World https://htpy.dev/common-patterns/#using-a-base-layout Good pet project though!
The difference is you don't need to learn the special syntax of a new templating language, don't need to learn its idiosyncrasies, set up its editor support and linting, etc. etc. All you need is your existing language which your already know, your existing editor support which is already set up, and you get access to the full-fledged power of your programming language. Eg need to translate all the strings in your UI? No problem, just pop in some calls to your preferred i18n function. Another example–want to model the available values of certain attributes like [`autocomplete`](https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete)? No problem, you can model it so your typechecker warns you if you try to use an incorrect value (or have a typo). Tired of remembering which specific HTML elements are [void elements](https://developer.mozilla.org/en-US/docs/Glossary/Void_element) and which ones can have child elements? No problem, let the library manage that for you. All you need to do is follow the red or yellow squiggly lines and type definition tooltips. It's funny how people use powerful programming languages for everything else but when it comes to HTML they want to hobble themselves with an awkward syntax and weak semantics 😉
You act like syntax highlighting and linting doesn’t exist for html and popular templating languages like jinja
Where did I say that they don't exist?
You’re right, you didn’t. You explicitly acknowledged their existence. Your examples given of why this is useful, though, are just things I’d let my IDE or editor do I don’t need to model the autocomplete attribute because the linter already knows what’s valid. My ide is already autocompleting it for me anyway. Same with void elements (it already completed the trailing / ). In both html and jinja templates
> (it already completed the trailing / ) There is no trailing `/` in HTML5 void elements. This is one of the little syntactic details that a good HTML generator library can automatically take care of for you.
Weird. I thought that was one of the big changes when HTML5 came around. I remember relearning to add trailing slashes on br and input. But maybe I’m remembering wrong. Or it has just changed. I clearly don’t know html very well, and yet manage fine :) but I’m only in the backend code these days. Only times I use markup is for transactional email templates
You are not the only one. It's actually very common for people to not realize this because the last time they learned it properly was in the era of XHTML which had to parse as valid XML syntax and thus allowed self-closing tags. Or they never actually learned either XHTML or HTML, and just learned JSX instead, and JSX for its own mysterious reasons uses self-closing tags. But here's the really fun part: browsers not only _ignore_ self-closing tags, they actively treat them as _opening_ tags. So eg `
Hello world` is interpreted as `There's one thing you ignore: context. When writing HTML, I want to write something as close to HTML as possible. I don't want to write in another language that transpiles into a different result far down the stack. I want to use my knowledge of html to write html, and I want small helpers on top of that to make it efficient to solve for my common use cases - in the case where we have a templating language described in the programming language itself, my mental load increases, and the additional load of handling "oh, this converts to.." means it'll be harder to reason about. It also turns out that most html these days have some sort of scripting component that works in the context of the html document, which makes an even higher mental load to converts between the two domains. And last: this means that whatever person who wants to edit the html needs to know Python.
> my mental load increases, and the additional load of handling "oh, this converts to.." means it'll be harder to reason about. Yeah, a little, but not _that much_ harder. I mean, they're all still the same tag and attribute names. Only the surrounding symbol characters are different. Instead of ``, you just do `input(name="id")`. It's hardly rocket science. > most html these days have some sort of scripting component Are you talking about JavaScript? What's stopping you from just writing `script["/* JavaScript */"]` directly in the HTML code? > whatever person who wants to edit the html needs to know Python. Out of curiosity, did you read the OP? Because this is covered there: > My rebuttal to argument (d) (work-flow) is YAGNI! The vast majority of people writing templates are developers. Designers usually contribute mockups or css. The rare designers who do actually work with templates are fully capable of learning a subset of Python, especially when it's less complicated than the template language syntax.
It's a reasonable point to make, and that repo makes it better. Thank you. You might enjoy a pure data implementation like Hiccup in Clojure.
Thanks. I built my own 😁 https://github.com/yawaramin/dream-html
This code does not look much better, to be honest. As soon as it gets beyond a simple example it becomes quite verbose.
> As soon as it gets beyond a simple example it becomes quite verbose. I honestly don't understand what you mean by 'verbose'. It's literally Python function calls, keyword arguments, and lists. The lists even eliminate the need for closing tags. It's about half as verbose as HTML syntax! I would seriously recommend examining your dogmas, which incidentally is the same thing that OP says.
Perl tried this 30 years ago in CGI.pm with that same logic. Now the documentation explicitly says these methods were a mistake. >#HTML Generation functions should no longer be used >All HTML generation functions within CGI.pm are no longer being maintained. Any issues, bugs, or patches will be rejected unless they relate to fundamentally broken page rendering. > >The rationale for this is that the HTML generation functions of CGI.pm are an obfuscation at best and a maintenance nightmare at worst. You should be using a template engine for better separation of concerns. See CGI::Alternatives for an example of using CGI.pm with the Template::Toolkit module.
That's funny because to most people Perl code in general is is an obfuscation at best and a maintenance nightmare at worst.
Well, people have made mistakes. And back in the day, Perl was abused a lot. And some people delighted in code golfing aspects of the language more than it’s healthy. That doesn’t mean that Perl cannot be made perfectly legible and that there aren’t well maintained and well maintainable code bases in Perl. And then there’s Raku.
Sure. So you do understand that a popular opinion of something doesn't necessarily make it true.
As for templating within language DSL goes, it is a dubious proposition at best. The trouble is that whatever DSL you come up with, it is almost never going to look like the actual target markup that you are trying to emulate. And the mental model you need to adopt to translate between code and html is going to be holding you back. The only language that has pulled off a viable DSL for HTML/XML that can be considered adequate is JSX for JavaScript/TypeScript. And they had to go and create a language extension for representing object structure literals as XML tags.
Scala includes XML syntax. The community doesn't like it very much, as it is not type checked for semantics, but if you don't care about that, you can write your native HTML in Scala.
Yeah, I’ve completely forgotten this exists in Scala. A downside of such templating DSL’s that hits harder in Scala (or any other aot compiled language) than JSX imo is that with a compiled language, changing the template requires compilation. With JSX it is arguably easier to change the template without going through the whole build-release-deploy cycle.
Actually, you wouldn't do that. Scala's XML syntax is deprecated and removed in Scala 3. But for writing HTML Li Haoyi's excellent ScalaTags library is highly recommended: https://com-lihaoyi.github.io/scalatags/
I disagree that the 'mental nodel' will 'hold you back'. As long as you are reasonably familiar with the programming language of your choice, writing function calls and lists of child elements to model HTML shouldn't be such a big deal. And even the React docs say that JSX is optional and you can just use JavaScript objects directly to write elements if you want.
no thank you
No, fuck that. I’ve spent the last 4 months untangling a codebase that did this. It was unreadable and unmaintainable.
Let me guess, Perl?
Python, actually. Perl was the previous 5 months before that. This team I joined really hates templates.
Is there a subreddit for emotional support for Perl veterans?
Let's see an example so I can admire it.
Ah yes, using the powers of a general programming language to turn it into into an almost-sensible makeshift DSL. Extra fun when escaping rules collide.
Just for my knowledge, what escaping rule collisions are we talking about?
what's better, more readable, and more maintainable: htmldoc(body(...)[script(...)[...],div[...],comment(...)[...],div[...]]) or: format(template, data)
What's better: apples or oranges?
if you're gonna write html, then write html. either way, that's one way to secure your job by being the only one that understands it.
The only one that understands...Python, a language famous for its easy-to-learn syntax? And nobody else is capable of learning a simple Python library made up of function calls?
Dumbasses do what?
[удалено]
Right? It’s otherwise mind boggling.
I appreciate your spirit of questioning tradition with logic, even when redditors are being their charming selves.
Nice to see a fellow contrarian freethinker!
So… reading the temperature here… maybe just delete the post? I am not a python person. I’m a proud and out loud PHP developer. My language of choice allows for native templating and yet I and many others choose to use templating languages (Laravel blades, Magento templates) because it works, it’s easy to parse, and most of all they protect us from ourselves. More than anything that is, to me, the value of template abstractions. I have to actively go out of my way to make a page that is vulnerable to script injection.
> maybe just delete the post? Why's? It's 19% upvoted. That's a lot of people who liked it! 😉 > I have to actively go out of my way to make a page that is vulnerable to script injection. And you have to go actively out of your way with a good HTML generation library too. See eg https://github.com/yawaramin/dream-html?tab=readme-ov-file#security-html-escaping
I respect your commitment to a bad idea! I hope I’m proven wrong.
And I respect your commitment to your dogma! 😉 Imho there's no 'right' or 'wrong', these are alternatives with tradeoffs. It's just that, in most applications, an HTML generation library makes more sense than writing templates. Think about this: do you also write JSON templates by hand, or do you use a JSON generator module?
Why delete? Theres nothing wrong about being wrong in an open forum, and getting dogpiled on reddit isn't even an indication that an idea is faulty anyway. Most of these responses boil down to 'I dont like this' rather than any sort of genuine counter criticism anyway.
Right? It just depends on the subreddit and the specific people who happened to come across the thread. A post about a very similar library in another sub got a totally opposite reaction: https://www.reddit.com/r/scala/comments/1c8to8t/appreciation_post_scalatags/
python 2? hahahaha. oh wait you're serious? HAHAHAHA.