The Return Of JSPs In HTML 5?
In it's early days JSPs were misused for the realization of business logic. Any complex code enclosed in scriplets is hard to write, test and so maintain.
However: JSPs are perfectly suitable for delivery of HTML 5 documents:
- You have full control over HTML markup. There is no hidden code generation in place.
- No magic: JSPs become Servlets. Usually you can even look at the generated code in case something feels strange.
- After the initial invocation, JSPs are as performant as Servlets.
- JSPs just serve strings, so no components have to be hold in memory -- the memory requirements are low.
- IDE support, debugging and performance analytics for JSPs are superb.
- JSPs even support lambdas in EL.
- JSPs can be perfectly used in the "logic free" mode, just as a powerful templating language.
- You can introduce custom tags for the encapsulation of recurring functionality.
- CDI managed beans and so whole Java EE components can be easily exposed to JSPs
A simple POJO:
public class Greeting {
private String title;
private String content;
public Greeting(String title, String content) {
this.title = title;
this.content = content;
}
public String getTitle() {
return title;
}
public String getContent() {
return content;
}
}
Could be easily exposed by a CDI presenter / backing bean:
@Model
public class Index {
public List<Greeting> getGreetings() {
List<Greeting> greetings = new ArrayList<>();
greetings.add(new Greeting("short", "hi"));
greetings.add(new Greeting("casual", "hello"));
greetings.add(new Greeting("formal", "welcome"));
return greetings;
}
}
...and conveniently rendered using a JSP:
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE html>
<body>
<h1>Hello JSP</h1>
<ul>
<c:forEach var="message" items="${index.greetings}">
<li><c:out value="${message.title}"/> - <c:out value="${message.content}"/></li>
</c:forEach>
</ul>
</body>
See you at Java EE Workshops at MUC Airport or on demand and in a location very near you: airhacks.io!
Hi Adam,
The time for server side frameworks is over.
Replace JSP with AngularJS and mae your CDI presenter a RESTful Service and you have a perfect fit.
Posted by Simon Martinelli on August 06, 2014 at 10:46 AM CEST #
And what about server form validation (and messaging in case of invalid fields) ?
In jsf or spring its "out of the box" and in example above you would do this "manually".
Posted by Marek on August 06, 2014 at 10:53 AM CEST #
I agree with Simon. Nowadays has no sense using ServerSide Frameworks if you have Backbone or AngularJS.
The mix of RestFul WS, JSON/XML, JAXB, CDI, BeanValidation on server side and HTML5 JavaScript Frameworks+CSS3 Frameworks.
And now we have WebSockets and ServerSideEvents. I don't see any advantage on JSF or JSP. Even more, the lack of session layer over HTTP it's not necesary if you have your state on client side.
And in high concurrency scenarios, the server side only have to create object to proccess business logic, not render, analyze, validate view.
But your example is nice, and about Marek comment, I think that server form validation don't have to be manually, you have Bean Validation API (in JavaEE7 with wider use).
Posted by martdominguez on August 06, 2014 at 12:44 PM CEST #
Although syntactically similar, they are radically different. Clieny side frameworks distribute rendering cost to clients, in jsp it is all done in server. You have to do web services any way for 3rd party integration and mobile apps. JS model makes decoupling of model and view more obvious.
Posted by Deniz on August 06, 2014 at 12:48 PM CEST #
Client side frameworks are OK for lightweight applications (by lightweight I do not mean simple) however they are not a replacement for things like RIA's where JSF/JSP are a better fit. Having Session data on the client is definitely not a valid argument in favour of client side frameworks either, you can get that with JSF too. The expense comes in maintaining that state which with JSF is done for you.
Anything based on client side scripting will become increasingly difficult to maintain and extend as the size of the project grows too.
I advocated using the best tools for the job, avoiding any ideological argument in favour of pure pragmatism.
Posted by Andy on August 06, 2014 at 04:20 PM CEST #
Angular and REST Services are cool and can solve many of today’s web developemt problems, but server side frameworks, like JFS, can be used sucessfully in many situations too.
HTTP and even AJAX abstractions provided by JSF can lead to better maintainability e productivity. I think it's more enterprisely.
Hybrid architectures with REST, JSP (for template only purpose), and javascript (JQuery,Angular,etc) are also valids.
For simple applications, event pure JSP can be an option as Adam posted.
Technical decisions should be driven by product requirements, not by “coolness factors”.
Posted by LeonardoCruz on August 06, 2014 at 09:01 PM CEST #
I share the feeling that jee front end alternatives didn't follow html evolution. Even though jee wasn't designed for heavy consuming Web applications, I believe there are a lot of room for improvements in this direction. The way might be redesigning jsf components rendering kits more focused on html 5, css3, js new best practices.
Posted by Yamada on August 07, 2014 at 03:06 AM CEST #
Client side framework will end next year with web components and http/2. Today they are good, if you need fast development and don't care much about client performance. And yes badly written code has more impact on speed, than use of more complex js library.
Jsp are great if you need better control of generated HTML quality. Also you don't have to use expression language, which is horrible slow. (using scriptlets for passing values to jsp tags, no other code) Also jsp tags can be translate with tag plugins, which will get your server to light speed. (for example ebay use tagplugins)
Posted by Pavel on August 07, 2014 at 07:55 AM CEST #
I agree that you have a bag full of tools and you have to choice what better fit in every project/situation.
Maybe I have a bias because i have a large app on JSF2+Richfaces4, and whether it have clear benefits in comparison of the way we used to develop GUI interfaces some years ago (Struts1.2 or only servlets+jsp). But also, i've found a lot of problems related to the way that JSF works (and many workarounds too). So some years ago, I've started two projects with Backbone and Rest and this architecture was so useful, so my bias.
And also, as Yamada says, I have the feeling that JSF don't use all the improvements of HTML5 (perhaps because JSF is older).
Posted by martdominguez on August 07, 2014 at 12:20 PM CEST #
Simon,
Software industry != Fashion industry
Posted by John on August 07, 2014 at 09:14 PM CEST #
@Simon: JSF 2.2 does a pretty good job of supporting HTML5 but the standard components are pretty primitive so that isn't really a problem.
The plethora of JSF Component libraries out there make up for this and the responsibility for HTML5 support lies with them and not JSF. JSF2.2 and PrimeFaces is probably the best fit out there at the moment and graceful degradation to support less capable HTML5 browsers is there out of the box. I assume that the better libs do the same too.
What Adam has shown us here is that an 'old' technology, JSP, is still very much relevant because of the control you have over the HTML being generated and the ease with which you can integrate them with modern technology stacks. There are many situations where a JSP is a much better alternative to writing a Servlet, that is still a very powerful feature.
Posted by Andy on August 08, 2014 at 10:56 AM CEST #
The only problem with things like AngularJS etc is that you have to work with awful JavaScript. It would be nice to have type safety and refactoring but that's not going to happen with JavaScript.
Posted by Dan Howard on August 09, 2014 at 04:58 AM CEST #
JavaScript IMHO is not a great language to write complex code in, so I'd rather use it minimally, only to manipulate my DOM after an initial version has been rendered by the server.
The latest client side frameworks also frighten me a bit from a security and privacy perspective. With server side frameworks only that what is shown is send over the line, with client side frameworks it is very easy slip up and to send that whole client record while only the name should be shown (and the user is only allowed to see). And peeking into the network communication debug tab on the browser is easy.
Posted by Tom Eugelink on August 11, 2014 at 01:37 PM CEST #
JavaScript auf der Client-Seite - Na gut;
Aber Server-Seitig freiwillig mit JavaScript arbeiten grenzt an Wahnsinn :-)
Posted by Gustav on August 11, 2014 at 04:37 PM CEST #
Article from Twitter why twitter moves from client-side to server-side rendering. (https://blog.twitter.com/2012/improving-performance-on-twittercom).
Do you have performance benchmarks with Jsf and client-side JS frameworks?
Posted by osman on August 26, 2014 at 12:57 AM CEST #
As long as web components are not the part of HTML, I will not go in client side rendering.
Posted by asd on April 04, 2016 at 03:31 PM CEST #