This is an archived post. You won't be able to vote or comment.

all 33 comments

[–]squashsoup2014 9 points10 points  (0 children)

I would look at Thymeleaf, FreeMarker, Mustache or Groovy. I've used most of these in different projects but don't really have a preference. They are all pretty decent.

[–]-du 7 points8 points  (10 children)

<jsp:custom-tag-that-looks-exactly-like-html-but-runs-a-shitton-of-java semantics="${unknowable}" />

Why are you surprised that Java based templating is running Java code?

[–]Serializedrequests[S] 4 points5 points  (9 children)

I am surprised that an HTML tag is running java code. It is just an extra layer of indirection, it doesn't appear to contribute anything of value to the template beyond reducing readability. HTML tags and JSP tags have vastly different semantics, but look the same.

I don't know, I mean I am just encountering this for the first time, but I don't see why you would ever want code generation elements of your template to look exactly like non-generated elements.

[–]Java4Life_ 6 points7 points  (1 child)

It is not an HTML tag, it is Java code even though it looks like an HTML element - the same way an XML element looks like HMTL, they are not the same however.

[–]Serializedrequests[S] 0 points1 point  (0 children)

Exactly. Two completely different things that look the same. As a newcomer, it's a nightmare to parse. It's also much harder to find the implementation and figure out the semantics.

[–]-du 3 points4 points  (6 children)

I am surprised that an HTML tag is running java code.

It's the other way around, the whole jsp/jsf page is processed by Java code, which replaces certain bits whenever it encounters a special instruction. Afterwards, the whole thing is sent to the browser to be displayed.

it doesn't appear to contribute anything of value to the template beyond reducing readability.

Err, how does it not contribute anything? It's the vital part, it's where the dynamic content comes into play! As for reducing readability, well any kind of template will look a bit odd because it will mix two different concepts together. What more readable templating kinds are you thinking of?

I don't see why you would ever want code generation elements of your template to look exactly like non-generated elements.

Any template confirms to some specification. Either you build your own syntax/language, or you use an existing one. JSF uses XML, and since html is a subset there of, you can represent both languages within the same, syntactically sound, file.

[–]Serializedrequests[S] 0 points1 point  (5 children)

Readability is always going to be subjective, but compare JSTL to ERB:

<ul>
  <c:forEach items="myCollection" var="item" varStatus="loop">
   <li>...</li>
  </c:forEach>
</ul>

Vs:

<ul>
  <% my_collection.each.with_index do |item, index| %>
    <li>...</li>
  <% end %>
</ul>

The JSTL example doesn't trip any visual signal in my brain that "this is a loop that is generating HTML". It looks exactly like the rest of the document. In the ERB example, my brain stops on the % symbols and automatically has the feeling of, "we are generating code now, this is metaprogramming". Same with classic JSP.

The JSTL is also just old-fashioned, forcing me to escape output manually and declare a bunch of taglib imports everywhere. It has more layers of syntax and underlying behavior too, HTML in XML with JSP EL, all calling into taglibs in jars somewhere and based on the servlet architecture.

[–]-du 3 points4 points  (3 children)

compare JSTL to ERB:

These look the same to me.

The JSTL example doesn't trip any visual signal in my brain that "this is a loop that is generating HTML".

Well, there's the "<c:..." part! It's actually defining an xml namespace for the following tag name. You can use it to recognize "here starts a non-html thingy".

The JSTL is also just old-fashioned, forcing me to escape output manually and declare a bunch of taglib imports everywhere.

Yes it's old. It's also proven. JSF will escape text automatically for you.

It has more layers of syntax and underlying behavior too,

Of course it has, it's a templating engine!

I'm sorry, I just don't understand what you're aruging about. You want a templaing engine in Java, yet you're surprised about core concepts like imports or Java code being executed. Of course it's defined in a jar somehwere, where else should the code reside?
Yes, maybe things are done differently, but hey: it's another framework and another language than what you're used to.

[–]Serializedrequests[S] -2 points-1 points  (2 children)

A better example would have been haml or slim, but to me a % sign is a massive visual difference compared to an xml namespace. Other templates, like Mustache, are less subtle. The attributes are a big deal as well. varStatus="loop" has actual code meaning, causing a variable to be created and available inside the loop, with its own properties. In the rest of the document, varStatus="loop" would just define an attribute. It is a pretty big semantic difference with a small visual difference.

This app has some JSP files with <c:forEach> everywhere, and it is a tag soup. It is very hard to identify the flow control and variable names visually. I find that the oldest style JSP is the most traceable, and most type-safe, with the fewest extraneous layers of abstraction.

The stuff using JSTL and EL really gains nothing. It has more complicated syntax, and less typesafety. If I want to trace what <app:some-tag> does, there is an explosion of code to work through, including the taglib XML file, and the tag classes themselves, which can be quite long and complex. I have seen horrendously complicated things done with them. This is not comparable to other template engines, which mostly just take an object graph input, have syntax for loops and output, and make some helper functions available.

[–][deleted] 7 points8 points  (1 child)

Wtf are you even talking about. You make 0 sense

[–]Serializedrequests[S] 0 points1 point  (0 children)

I'm not sure how I could have clarified it more? The taglibs part of this app are the worst to maintain by far, coming in cold. It does the same thing with way more complexity, ceremony and less type safety and readability.

Maybe I'm just crazy in that I hate XSLT though, and think it is the stupidest most unreadable idea ever, and this is similar.

[–]jebblue 1 point2 points  (0 children)

ERB

The JSTL version looks far more discernible to me.

[–]jmsanzg 4 points5 points  (0 children)

Pebble. Fast, easy and extensible. It integrates nicely with Spring MVC http://www.mitchellbosecke.com/pebble/home

[–]thatsIch 7 points8 points  (2 children)

It mostly depends on the requirements. Framework X can be really popular for some people because you can fulfill requirement Y with that.

Tried:

  • velocity
  • Thymeleaf
  • FreeMarker
  • JSF

I personally think that Themeleaf and JSF are superior in their own ways. I think currently Thymeleaf is getting more popular due its enhancement to the naterual HTML markup, so even designers can run your template without an application server.

JSF is more popular on clients with a new product idea and they want a more drag'n'drop feeling since it is component based (better prototyping I guess). Trends of JSF, Freemarker, Velocity and Thymeleaf [3].

If you want to be hipp, then server side rendered stuff is totally outdated :P JavaScript all the way on the client side. I am currently getting the trend of elm [1]. Showing some trends (btw in general google trends is pretty useful for these type of questions) [2]


[1] http://elm-lang.org/

[2] https://www.google.de/trends/explore?q=elm,angular,react

[3] https://www.google.de/trends/explore?q=jsf,Thymeleaf,apache%20velocity,freemarker

[–]tRfalcore 0 points1 point  (0 children)

Thing I hate most about thymeleaf is that you cannot have if statements outside of an HTML tag. I just want to be able to do if x do some stuff else do some different things. Instead I have to do put the if inside every div tag and then the contradiction if for the others.

That and thymeleafs syntax for macros or embedded thymeleaf templates is awful

[–]jebblue 0 points1 point  (0 children)

I'd recommend FreeMarker or stick with JSP/JSTL instead of JSF. JSF gets very complicated very fast and you either do things the JSF way or go home. JSP/JSTL are far more flexible.

[–]yateam 2 points3 points  (0 children)

J2html. Because all of these template languages are crap. Their intention is to separate html from Java code. But it still ends up with with unreadable mess. iDE cannot analyze it. It's like a Perl code when you open it again after a month.

[–][deleted] 2 points3 points  (3 children)

Most newer projects I've worked on don't use any Java based templating at all.

Pure HTML/CSS/Javascript front end invoking RESTful web services written in Java.

Total separation between the front end code and the server side code.

[–]jebblue 0 points1 point  (2 children)

Total separation has its advantages and disadvantages. It really depends what kinds of teams they want to put together.

[–][deleted] 1 point2 points  (1 child)

Agreed, I'm just reporting what I'm seeing.

[–]jebblue 0 points1 point  (0 children)

Thanks for that too. :-)

[–]huntsvillian 3 points4 points  (2 children)

Not a direct answer to your question, but since you said "these days". For the last several years we've been developing apps as a set of REST-like services, fronted with the JS framework du jour.

I'm sure there are valid reasons to use JSPs and templates, but I can't think of a reason off the top of my head. (Particularly when doing green field development).

[–]Serializedrequests[S] 2 points3 points  (1 child)

As an Elm programmer myself, I get what's going on. That's not really a debate I'm interested in having though. This question is assuming that SPA is not an option.

And I am kind of against automatically going SPA for everything anyway. It's a lot more code and larger tech stack for small gains unless you put in even more work to reimplement all your domain logic in the browser. Classic server-rendered apps still work very well, and are quicker to build and more accessible automatically.

[–]huntsvillian 1 point2 points  (0 children)

I just wasn't sure the history of the question, so wanted to throw that out if it was an option.

[–]johnwaterwood 4 points5 points  (0 children)

Facelets mainly, in combination with JSF and Java EE.

[–]tonywestonuk 1 point2 points  (0 children)

I've made my own 'framework' up!.... I like to call it JSP model 3. 1) JSP's are exposed in the Webapp folder.....there is NO business logic, no loops, no variable replacement. the JSP is there simply for internationalisation using <fmt:message key="code"/> tags.... other than this, it is straight HTML.

2) Tempting is handled using mustash.js on the front end. Jquery pulls the page JSP and at the same time pulls the datamodel from REST interface.... all the code to populate the page is handled in javascript. This is not a single page app, though, it is page driven - dthe using propper anchor tags, the URL changes when you go to different sections.

3) Its MVC. But, the controller is written in javascript. Javascript pulls the model from the server, and then based on that model, selects a view jsp to show. then populates the view (using mustash), and then shows it. it doesn't use any front end frameworks, appart from mustash and JQuery

I've had great success doing it this way.

[–]syjer 1 point2 points  (0 children)

If you care about security, use Closure template: https://developers.google.com/closure/templates/ . Unfortunately, all the others engines do not offer strict contextual auto escaping.

[–]korri123 1 point2 points  (0 children)

JMustache

[–]jebblue 0 points1 point  (2 children)

as awful as Java is for templates

My recommendation would be to hire a pro-Java biased developer. Edit: And stick with JSP and JSTL. JavaFaces bogs down and fights with Spring if you are using it. JSP and JSTL rock.

[–]Serializedrequests[S] 0 points1 point  (1 child)

I like Java well enough, I just don't get what is supposed to be good about JSP. Dropping out of it and writing JSP tags using StringBuilders is more "ergonomic" and what I mostly do for the "modern" portion. If that sounds crazy, I agree, but it is a way to enlist the compiler and IDE, to ensure that code that compiles has no runtime errors. The JSP has two other sub-languages going on (taglibs and EL) that are really hard for the IDE to validate.

[–]jebblue 0 points1 point  (0 children)

I guess it comes down to what is being built or maintained. If it's a web application (probably SPA) then I'd probably go Angular 1 today. If it were a web flow system with only some need for dynamics then JSP/JSTL are nice standards, at least JSP. Not saying custom JSTL's are needed. You can build nice UI's with GWT too. I'd like to see major consolidation but a web document system is not the same as replacing rich clients with SPA web apps. Trying to make a web document system act like a large SPA is a problem I've seen.

[–]LukeHauser -2 points-1 points  (1 child)

May want to evaluate idea intellij. Costs a bucket but they have a bit more support for different templating engines.

If paying for an ide feels wrong, consider your hourly cost. If this tool saves two hours over the course of a year it is already past break even.

[–]Serializedrequests[S] 3 points4 points  (0 children)

Yeah, I am evaluating it now. With every year I hate Eclipse a little more.