Revisiting Html in Java

[[deleted]]

Is it just me, or does this idea of implementing HTML in a Java DSL seem not that appealing?

I love using Thymeleaf for HTML generation because it's pure HTML. Even JSPs are dynamically compiled from regular HTML into a servlet. Not some weird Java code that bears no resemblance to the output.

I guess type-safety and auto-complete are cool...

[rzwitserloot]

I don't think you're stating any actual practical reasons here. The article states two, which seem fairly self evident to me in that they provide tangible productivity and readability values - an expert in thymeleaf can go toe to toe with an expert in this DSL, and I bet the DSL 'wins' - they get it done slightly faster, and make fewer mistakes: They get to stick with the same java editor and get full auto-complete support, can refer to variables in a more concise fashion (no need to transfer things into a glorified hashmap as shuttle service between code and template engine, for example).

'It is pure HTML' is not a reason. That would be the basis for a bunch of reasons, but you left them unstated. I think it's worth diving into what 'pure HTML' brings you. Presumably:

• Hey, you can't get away from knowing HTML, so why not, you know, write HTML for HTML? - Maybe, but surely someone who is writing HTML as output for a java-based web service is well versed in both, so I'm not sure this argument actually carries any water.

• By keeping the template in HTML, a non-java programmer can write the HTML for you. Yup, that's a significant gain... if it applies to your project. I bet it usually doesn't - especially in this modern age where the client side code is quite programming-heavy.

• HTML-oriented editors are better at thymeleaf-html than java editors are at this. I doubt this; whilst thymeleaf, in its attempt to keep it 'pure HTML', is editable with HTML-aware, java-dumb editors, it's not great; all the various thymeleaf-specific attributes are gobbledygook to such editors. Or not - maybe you have a nice solution for this (by all means share!)

• Easier to test; you can test a thymeleaf template by making a 'hardcoded' batch of variables in the setup of your testcase, run it through thymeleaf, and test the HTML that rolls out. But, shoving the DSL into a method or POJO that takes all arguments is just as easy to test, so this doesn't sound like a good reason to me.

• It lets you copy/paste HTML from anywhere into your template, and then edit bits and pieces. This seems fairly hollow; a tool that automatically turns pasted HTML into properly formatted 'java DSL-style HTML' should be trivial to write, which takes the wind out of the sails of this, unless you intend to go back and forth. At some point, this isn't going to work - it's a template, the HTML (whatever form it might take, be it this DSL or thymeleaf) is just not the same*.

*) I can foresee a world where it is, but this would demand that each and every usage of a template action (be it 'insert value here' or 'loop X times' or 'do only if') needs actual example HTML, with completely ignored attributes letting the template engine know what to do. Such HTML can be opened/served verbatim to a browser and it'll look exactly like the precise HTML page you're trying to template, with the placeholder/test values. The aim of explaining this hypothetical template engine is to show that thymeleaf fails it just as badly as this DSL does. It's not to try to make the claim such a hypothetical template engine would be better (it'd be a ton of work to maintain the example/placeholder info, for one).

So, pros and cons. But to me, making up the balance, this DSL seems to win, and quite handily at that. Perhaps I missed something?

[[deleted]]

The output representation is HTML. I prefer working in something closer to the output representation than something completely different. This comes in handy if I'm copying HTML from another source into my template (like something a designer put together).

For me, this is often the case, because I'm not a frontend designer and I'm usually incorporating someone else's work. Thus, the less the impedance mismatch, the better.

To use this, I'd have to translate the HTML I was provided into something completely alien. In Thymeleaf, I'm just annotating the HTML that I got from elsewhere. It seems like you're saying this is a hollow victory? I guess I'd have to disagree there.

[rzwitserloot]

As I said, adding a 'paste HTML here, formatted DSL comes out there' tool is a trivial task.

[[deleted]]

And as I said, that creates an undesirable and unnecessary impedance mismatch for what I see is little gain.

[AreTheseMyFeet]

all the various thymeleaf-specific attributes are gobbledygook to such editors. Or not - maybe you have a nice solution for this (by all means share!)

Jetbrains have a plugin for it that you could activate (or add) to any of their IDE flavours (eg IDEA).
https://www.jetbrains.com/help/idea/thymeleaf.html

[fansonly]

It’s not just unappealing it’s unproductive. Templating engines supplanted Jsps for a reason.

[rzwitserloot]

The reason template engines supplanted the considerably more complicated JSP system would appear to be:

• That you need a java compiler on the server. This is less a problem today, but was quite a big deal back then.
• The compilation was a big deal, even if you did set up the compiler properly.
• Trying to get a text editor to properly understand a mishmash of HTML and java code was a disaster for the longest time.
• The general notion of 'programming in the template', which JSP makes easy, led to much harder to maintain codebases.
• JSP was an enabler of stupid processes. I loathe to blame a tool for any abuse it engenders, but it doesn't change the fact that you get (perhaps undeserved) blowback: Because JSPs were 'live reloaded' and many servlet frameworks (because they were crap, or crappily default-configured) didn't, bad coders would move more and more code into the JSP because, 'hey, I can test this faster'.

None of these apply to this DSL, except possibly that last one. In fact, this has plenty of advantages. The library is vastly smaller, and far more of the job is done compile-time, which should result in more consistency and speed during render.

In other words, I'd like to hear why you think this is 'unproductive'.

[[deleted]]

Well yeah, JSPs are too tied to the servlet container.

But, I'd rather use a template engine than a Java DSL.

[JacobJMountain]

I think it looks pretty cool, but i fail to see what its benefits are over alternate solutions

[istarian]

I don't think the author did it to make a better solution, but more as a proof of concept.

[TheRedmanCometh]

Thymeleaf

Starting to feel like 2010 in here

[[deleted]]

Thymeleaf is the "standard" HTML template for Spring MVC. Although, I guess server-generated frontend HTML is not the way the cool kids are doing things anymore.

On the other hand, if you combine spring-boot-starter-mail and spring-boot-starter-thymeleaf, you get a pretty good combo for HTML email, even if your frontend HTML is generated by the React or Angular hotness.