Monday, January 23, 2012

Java web frameworks discussed


Java has been around for a while. Soon after its initial inception, Sun started to push the platform towards the web with an eye on big enterprise environments, in the form of the Java Enterprise Edition specification. This gave birth to, among others, the epic Servlet specification - in most environments the heart of the Java web layer.

Now many years later, there are dozens of web frameworks that either extend the initial Servlet core or bypass it completely. There is for example Sun's own JSP technology which is a simple templating system on top of the Servlet specification. Next to that there is the Javaserver Faces technology, which is a stateful enterprise scale web framework designed to be used to build large backend systems and user interfaces for existing enterprise solutions (and less for, say, the next Facebook).

Having also visited the Sun/Oracle forums for many years now, the same question pops up again and again and again: which web framework is best. Let me address and demystify that question right here and right now:

the best does not exist.

Stop looking for it, it is not there. They all have their merits and they all have their breaking points. There is not a single web framework out there that will work for all requirements out there. JSF is a good example of this: you could attempt to create web 2.0 type webapps with it (blog, social website, twitter 2.0, etc.), but you'll only find it a rather grueling experience. JSF was not designed for that purpose. Neither was Spring framework. Struts and Play framework however are better candidates in this particular case. But if I would have to build a web application that ties into a JEE backend, I wouldn't want to use anything but JSF 2.1.

So what then!? Why is there no one tool for all jobs like in .NET and why is there no Microsoft telling you what to use and how to use it? Yep, that's the Java platform. You either love the freedom of choice, or you should run away now. As it is, you have a whole wonderful world of frameworks to examine and explore. I have done that too just for the fun of it and I like to discuss some of them with you, to perhaps save you some time or at least make you aware of their existence. This will most certainly not be a "JSF VS Spring" type comparison, because I am smart and experienced enough to know the futility in such discussions. Of course I cannot document what I don't know, so don't expect to find all frameworks in the world in this article.

Before we start I have to make the obvious crystal clear: these ramblings are of course my personal opinion and experiences which in some cases may have been resolved since the time of writing, or a better solution escaped me at the time. Your mileage may and probably will vary. If you keep it neutral I will be very glad to hear where you disagree with me!

Servlets and JSPs

The golden oldies. I have long called JSP technology seriously outdated, but I have recently changed my mind a little about that. The fact of the matter is that Servlets and JSPs do nothing for you; its you in charge, you do everything including mapping request parameters to objects and validating them.

Even with the big bad world of frameworks out there, is there still a place for Servlets & JSPs? Yes, certainly. Smaller web applications are still quickly and cleanly built using them and you don't need any external dependencies either. The only side note is that you do it properly, which means:

  • use Servlets to invoke business logic (which includes invoking database queries)
  • use JSPs to generate the view
  • JSPs contain no Java code, only JSTL tags and if you want custom tags

One 'page' will generally be bound to both a servlet and a JSP; the servlet for the backend business logic and the JSP for the view logic. This works by making the servlet the entry point (for example a form submission goes to the servlet) and when its time to show something, you forward control to the JSP. By setting appropriate objects in the request scope, you can share data between the servlet and the JSP.

If you want or need to stick to these bare basics, it would still benefit you to investigate the Stripes framework. Stripes is a lightweight framework on top of servlets & jsps, taking away many boilerplate tasks you would normally be very bored with yourself.

Want to learn Servlets & JSP technology? Read Core Servlets 2nd Edition, a free online e-book. It is old, but still the best book I know on the subject.

I would use this: when you have only a few pages/functions to implement, like for a simple management interface for a backend application or a webapp with very light dynamic needs.

Javaserver Faces

Javaserver Faces, or JSF, has had a rocky development cycle. It only became anything close to 'good' with the 1.2 release where many design flaws were fixed. Years later JSF 2.0 (and now JSF 2.1) made its appearance, which fixed even more design flaws and took away most if not all of the XML configuration necessity that made JSF 1.X clunky indeed.

Many hate it, many love it. The main reason most people hate it is because of its steep learning curve and the fact that people use it for all the wrong purposes. You have to accept one basic fact: you are not going to properly use JSF until you really know how it ticks under the hood. You have to understand how the request lifecycle works and how the statefulness of JSF works. And when you do, you can wield it like a magic wand. It is a powerful framework that can save you an immense amount of time... if used for the right purpose! The right purpose is found within the specification it is part of: the Java Enterprise Edition specification. JSF is primarily aimed at being used to build web components for enterprise applications. That is where it shines: creating complex user interfaces with bells and whistles while the framework takes care of wiring UI components to backend classes with automated validation and transformations going on. Due to its stateful nature you even have an object representation of the web UI available to you server side.

JSF itself is only the base actually. It is designed to be extended, and many third parties do just that. On top of JSF you also have JBoss Richfaces, Icefaces, Primefaces, Oracle ADF, Apache Tomahawk, JBoss Seam, Omnifaces, etc. They all share the fact that they extend core JSF with more functionality, which usually comes in the form of Ajax controlled "rich internet components". Jboss Seam is unique in that list in that it does not actually aim to extend, but "seamlessly wire together" many frameworks and technologies to the enterprise platform.

Since JSF 2.0 these extension frameworks integrate quite neatly, so you can even mix and mash them together and have an even richer component library available to you. Its all quite neat, but beware: this is not easy material. JSF is hard, and "they" want you to buy books to remedy that so don't expect rich online documentation either. What documentation there is, you can find as part 2 of the JavaEE tutorial - that's a good place to start to see if JSF is anything for you.

I would use this: For medium to complex enteprise webapps where full control over the front end is not a requirement. If the application is built and designed around a solid backend, JSF 2.1 is your friend. If your application aims around a rich and dynamic web 2.0 front end, JSF is not your friend.

EDIT 10-04-2013: Apparently JSF can now also be stateless, as reported by Balusc on his blog. That may help a lot of people to actually use the framework where previously they couldn't or it was very hard (session-size limited environment, load-balanced website)!

EDIT 14-06-2013: JSF 2.2 is going to bring some cool improvements, including the Wicket-way of binding HTML components into JSF so you can have 100% control over the front-end. Its amazing how slowly the boundaries and limitations of the framework are being broken down without turning it into a legacy mess.

Spring framework

Its a bit unfair to list Spring framework here, as it is actually not a 'web framework' but more like an alternative to Enterprise Javabean technology. But Spring is unique in that it does not want to be something specific; it is such a dynamic and open framework, it shares JBoss Seam's aim in wiring together many different technologies, both frontend and backend. It does not aim to replace Java Enterprise Edition technology, not at all. You can use it as an alternative, but you are just as free to wire Spring and JEE technologies into the same application. Spring helps you to do it. Want to use JSF as the front end? No problem. Want something simple but you don't want to lower yourself to JSPs? No problem, Spring has a built in front end layer.

So what does Spring add itself? Plenty!

  • a bean autowiring system to replace (or extend) the dependency injection model as it exists in the JEE specification. Spring does not limit itself to managed classes, you can autowire just about anything using Spring with either the right configuration or a few annotations, including in client side applications if you would want to go so far.
  • an incredibly strong security model (which can be uses separately from the Spring framework itself).
  • "Inversion of Control", or IOC. In stead of manually constructing objects, you "inject" them from a Spring managed context. You may be familiar with dependency injection schemes as they exist nowadays in the JEE6 specification; Spring offered such services for a long time already.
  • a strong emphasis on the Model View Controller pattern. Spring provides default controller types for example, but you can also implement your own. As for the model layer the framework can setup JDBC, Hibernate, JPA, etc. for you and it can even manage the sessions and transactions.
  • A built in web front end framework with easy to use annotations that is a very decent replacement for JSP technology and hooks nicely into Spring's MVC model.

And much, much more. Check out the reference manual to at least adopt the awe it deserves.

That also proves Spring's main disadvantage: it is huge and huge frameworks tend to be clunky. On top of that Spring has been around for a while now and has gone through three iterations already, which means that there is also a big amount of legacy that the framework has to drag around. All this makes it quite hard to start to use the framework as first you have to separate those pieces of corn from the cob that you really want to eat.

I would use this: when I have to build and maintain a large enterprise application that will also target other legacy systems and technologies. Spring is so flexible you'll have the least trouble adapting it to whatever you already have floating around. That doesn't mean it is going to be easy, but the people that built Spring already did a lot of the ground work for you. Also there is a huge community around Spring, which counters the startup troubles you'll likely have.

Struts 2

Struts is what existed "before Spring". It is one of the earliest Java web frameworks out there. As such, you don't want to use Struts 1 anymore. It is old, outdated and every framework released after it was aimed to do better than it.

Struts 2 is one of those frameworks that aims to do better than Struts 1; it is actually quite a clean and neat framework if you but dive into the documentation for a moment. If all you want to do is create simple web applications, "web 2.0" or otherwise, then it isn't a bad idea at all to consider Struts 2. But beware that it has limitations. For one, the security model is weak at best (the fact that the sales pitch on the home page doesn't even mention it is a good backup of that statement). In this world of web paranoia and heightened security demands, the framework does nothing to assist you or to help you prevent doing it wrong.

I would use this: for web applications that do not have high security demands but will be a mix of complex forms and dynamic frontend pages. Also good to get into the world of Java web development as it has such an incredibly low learning curve.

Wicket 6+

Another framework brought to us by Apache, Wicket is actually quite a cool alternative to its competitors. A Wicket application, although targeting the web, develops like a Swing application. You work with components in stead of a "backend and a frontend"; the separation between the two layers is almost taken away by Wicket. In stead you think in events. A user presses a button, what is supposed to happen? Where other frameworks tend to hide the interaction, Wicket bares it all - on the Java side. Unless you introduce the rich Ajax functionality of Wicket of course, then stuff starts to happen client side as well.

Wicket is also a framework that is friendly to the developer. It integrates nicely into IDEs and even has built in support for hot-deployment making it far easier to change and debug your applications. Also boring and cumbersome features like making your application multilingual is made incredibly easy. The framework really takes away most of the boring repetitive chores from you, leaving only the interesting stuff for you to do.

But, no framework is perfect. Wicket has some downsides in my opinion:

  • the available information is a bit weak and disorganized (but has grown since I first wrote this article). I found myself having to hunt through endless forums, blogs and even the source code to figure out how the more advanced features of Wicket not only really work - but also how they should be properly applied and what you absolutely should not do. Don't get me wrong, when you know how they work Wicket rules, but I wish someone would have written it all down in a coherent form in a single resource. A notable exception is "Wicket in Action"; that book tends to go a little bit further and actually provides useful examples you can use directly in your application. But in my opinion: still not enough and the book is aging and Wicket's evolution has not stopped since it was written.
  • Even if the framework takes away plenty of work, I found myself having to write lots of boilerplate code nonetheless because of the component oriented approach; in some cases it can even be a little counter intuitive. You really have to think about how you organize your project to not drown in the sea of pages, panels, components, validators, model objects, message files, etc. etc. It can be hard to manage large Wicket projects, take your time to keep your project well-structured and don't be afraid to move things around. Also don't fear inner and anonymous classes when you know you're not going to reuse something.
  • The framework may appear simple, in fact it shares the Javaserver Faces problem of being complex under the hood and yet again do you really need to know how the framework ticks, or you can get into big trouble later on. A notable problem is that of an exploding session for example; Wicket is by default stateful and uses the session to keep its state, including the component tree of pages being rendered. If you're not careful you can be cramming a lot of data into the session without even realizing it; the framework does not do enough to help you prevent that. You have to read the fine print to know what to do and what not to do. Be careful choosing and using Wicket in an environment were the session size is limited. There are more such examples, most of them boiling down to "Always use models!". Then why offer the possibility to not use them and send newcomers awry? :/
  • The framework has a rich history, which has also lead to feature creep. There are ALWAYS multiple Wicket classes and features to do the exact same thing, and you have to be experienced to know which way fits with what exact requirement. Keep the javadocs really close.

Regardless of those negative points, they are all to be circumvented by properly thinking about it, doing the necessary research and simply gaining experience. Rarely any framework can work without those basic attributes in your personal involvement. So now that you're aware of it, don't fear to use Wicket if you're interested.

I would use this: When you need the power of JSF but you hate JSF's design, or when you need more control over the front-end. Wicket also works really well in environments where web designers and developers share tasks, since there is no code and almost no special markup in the views. Finally: if you're a client software developer by heart and you want to get into web development, Wicket will make the transition easier than other frameworks given its component approach. Finally, if you anticipate your project will make use of lots of components or fragments of pages that you'll be reusing multiple times, definitely go for Wicket!


Google Web Toolkit is a strange beast. You write applications using the Java language - yet come time to deploy, it is mostly javascript. GWT offers incredibly powerful browser user interface capabilities that go far beyond what any other framework offers; using it you can create the coolest web front ends with relatively little work. You can see proof quite easily; Google creates most of its own online web services using GWT. JBoss also uses it for many projects, such as the JBoss 7 management interface and Drools Guvnor.

On top of GWT itself Google also provides you a wide range of tools, for example a rich set of plugins for Eclipse. This makes it a complete package that is completely carried by Google itself. This keeps it all tightly integrated and documented, which is a big plus for a web framework. It is of course also a good choice if you want to deploy into Google's App Engine - there are also tools to be able to do that from your IDE. These tools are a bit invasive however; I recommend installing a fresh copy of Eclipse specifically for GWT app development.

My main beef with GWT is that the framework is so vastly different from any other framework out there; you even need a specific GWT compiler. When you want to use it you start from scratch, even if you've been writing webapps for years already. That is not necessarily a bad thing of course, but it may make it hard to adopt it for a new project.

An added bonus of GWT that makes it a good choice in this day and age lies in its Java to Javascript conversion capabilities. The HTML 5 madness has begun and people are now actually writing whole applications in Javascript; you know, that scripting language that up to a few years ago was hated and feared and everyone needed to block it. Through GWT you don't actually have to write your stuff in Javascript itself; you can write Java code in stead and still end up with "HTML 5" components. For example LibGDX makes good use of that to be able to make Java games built with it deployable to the web!

I would use this: when you have the requirement to create highly complex and feature rich web user interfaces. This is especially true when you have to work with people that do not have widespread experience with Java enterprise development, as GWT only lightly touches upon the Java language.

Play Framework

Play framework is a relatively young framework that hasn't been given the attention that it deserves so far. I say that because when I started to experiment with it, it made one thing clear to me: this framework succeeds royally. What it does better than other frameworks:

  • stripping away the boring part of Java web development
  • fusing backend and front end development
  • being completely stateless and REST-enabled
  • providing perfect hot-deployment without need for JRebel; even JPA entities!
  • simplifying setup; you don't even need to configure anything in the web.xml
  • integrates with many popular and important web technologies
  • manages dependencies for you without needing to learn the complexities of Maven
  • consolidates web dev into a neat package. You don't have to make choices, Play has everything on board to get you going.
  • data is very easily shared as XML or JSON
  • incredibly easy ORM model based on Hibernate and JPA 2.0, with an additional layer that takes away the cumbersomeness. You don't even need a persistence.xml.
  • toolset inspired by that of Ruby and Groovy On Rails that allow you to manage most of anything you want to do with a Play project, including setting it up for a specific IDE.
  • not the least important: the maintainers are active and listen to you. Expect bugs you report to be fixed timely (if it is really a bug of course).
  • for easy administration, a CRUD module is available

Really, this framework is a breath of fresh air and will appeal to people that cannot work with for example the statefulness of a framework such as JSF or the confusingly open nature of Java enterprise development as a whole. Play lays down the rules, it brings the conventions and it provides you the foundation to allow you to quickly and painlessly develop web applications, without boilerplate, dependency conflicts or layer upon layer of configuration.

This is the first framework I know of that can utilize the benefits of the Scala language (but it is also built for the Java language). The same is true for Play 2.0 which is out right now, and more so. This is mostly because the framework is modeled almost entirely after Ruby on Rails 3 including the available tooling, which is a web framework stack that "just works". If you know which buttons to push and which levers to pull of course.

I've been incredibly positive so far, of course there are a few things to complain about.

  • the programming model is quite... counter-intuitive. You'll be creating lots of static classes and entities with public members for example
  • navigation is based on throwing exceptions :/
  • documentation is a bit shallow at the moment, although Play 2 will have some nice books written by people I have had the pleasure of conversing with and I respect a lot. The online documentation is of the "this is the easiest way to do it" type. Still with a bit of digging you can figure out anything you need, especially because you get a nice set of example programs.
  • deploying is a bit of a mess using Play as you don't deploy classes, you deploy the source files (which the framework instruments at runtime before compiling them for you). You can deploy as a war, but you are encouraged to deploy in exploded form. At least using Play 1.X I would advise you to just do that.
  • The (alternative) way you manage a Play project makes it difficult to integrate it in for example a JEE application in a way that is easy to maintain.
  • Play 2.0 still supports the Java language, but at its heart it is really designed for Scala. You'll see evidence of that every way you turn, starting with the template language which is Scala based.

I would use: if you are new to Java web development as it is really easy to pick up. Also if you are bothered by the incoherence that most popular Java web frameworks are prey to, Play may be the relief you need. Finally if you need to create a webapp that is highly front-end oriented but you don't want to dig into the complexities of for example GWT, Play is also a really good choice as you have total freedom there. The basic idea is that you use jquery and jquery-ui to create your rich internet components. Play's simple Java (or Scala) backend will help you take care of the rest. If you want to use Scala in stead of the Java language, the choice should be a no-brainer.

The unmentioned

As stated I did not use all frameworks out there so I can't comment on them, but readers of this article have seen fit to make recommendations and I respect their opinions. Hence let me summarize some things that you may glance from the comments; I encourage you to check them out before making a final decision on a framework to use.

2014 - How about NO Java web framework?

This article was written back in 2012, times have moved on a lot even since before then and for some time I was oblivious to it. This entire article focuses on web frameworks that live on the server side of things, where Java is king. But there is a trend to move away from those and to do more on the client side, using Javascript frameworks. Frameworks such as AngularJS and EmberJS, as well as the neat server-side component Node.js allow you to build your entire web application stack using the Javascript language - both client-side and server-side. With the help of tooling such as Grunt you have a build management tool that in my opinion is superior to anything the Java platform has to offer, including Gradle and Maven.

It may seem a little odd to mention such a thing in an article like this, but this article was aimed at giving you a good idea about what is out there and I can't ignore a very popular movement in this day and age. When you are considering a web framework, ask yourself if you really want to use server-side solution such as Java at all. You don't need to anymore. If you are completely new to all of this, you might want to reconsider and go the Javascript way to be directly working with the technology of today and tomorrow.

What about a compromise - a Javascript front-end and a Java back-end? That is certainly possible - you can relatively easily setup a Tomcat server and deploy a JAX-RS based RESTful webservice on it and use Servlets for some alternative features such as file uploads. If you have Java code already lying around that you need to use, then it is certainly a viable option to do and relatively painless too - using JSON as the main data format you can quite easily communicate information between the front-end and the back-end; it "just works". Just be aware that when you're using a Javascript front-end, you are likely to run into security restrictions you need to take care of in the form of CORS. My article on setting up a JAX-RS based service has a paragraph on how to configure that in Tomcat.

In the end it is a difficult to say whether you need to completely bypass Java (or some other server-side technology) and go Javascript only. If you do you'll enter a rich and fresh online community which is rapidly expanding and developing this technology; thus you'll always have plenty of people to talk to and get help from and you might even contribute to the technology stack yourself given that it is still growing. But there is a flip side to that coin; it is a rather young area of development even though Javascript has been around for ages. Thus the frameworks are still settling, the best practices are still being invented and the documentation is still being written; case in point, I have yet to find a good book that covers any framework in any kind of half-decent way. It is so bad that people have started actual documentation gathering projects to help you out.

So its really cutting edge technology which is not decently documented, versus aging technology that is rapidly becomes less commonly used, but is very solidly documented and thus easier to learn and adopt. Tough choice, really.

In closing

That was a quick overview of the web framework which I consider to be the most viable. There are many, many more, but most of them serve the same purpose as one I already named here. I couldn't end this article without at least passing out my personal recommendation. And that would be:

  • use Play framework for pure stateless webapps
  • use JSF 2.1 for JEE systems for highly data driven applications and/or that require tight integration between the web layer and the business logic layer. As an added bonus I would add Primefaces for a whole slew of easy to use rich internet components while keeping the webapp lightweight.
  • use a pure Javascript technology stack if you want to be as lightweight as possible, target multiple platforms easily and be as current-gen as you possibly can.

If you stick these three in your toolbox, you can basically tackle any problem IMO. Your mileage may vary.


  1. It would be interesting to see your comments on HybridJava too.

  2. But as I said, I can only comment on what I know. I've never used HybridJava and I probably never will. Even the website looks like it was made by amateurs to be honest :/

  3. Very interesting article!
    Thanks for the Play Framework recommendation, I'm going to take a look at it right now, it sounds like a solution for me ;)

  4. Learn it, love it and be sure to spread the word!

  5. What about Vaadin...did you ever look into Vaadin? Great article btw!!

    1. I haven't used it, but glancing over the (excellent) website it seems it is a lot like Wicket - only far better documented. I'm certainly going to give it a try sooner or later.

  6. Wonderful write up Gimby. I was giving a colleague my thoughts on JSF based frameworks and an MVC action based on like Play (specifically we were considering using either JSF /w Primefaces versus Play) and your closing point was more or less what my recommendation was.

    1. Yeah JSF 2 + Primefaces is really the ideal combination IMO. Primefaces is nice and lightweight but still provides an incredible amount of components to play around with.

  7. I liked the article.I plan to use Spring MVC in my project. The existing architecture is Model1 /Model 1.5 mix.
    Most of the team members are freshers.The UI features required are not very rich and mostly it is data driven.

  8. cleaned up some statements; Added Primefaces to my closing recommendation; Made reference to the fact that Play 2 is now actually released; enriched JSF block with web links and added JEE tutorial link for online documentation.

  9. What about Play framework security?!??

    Anyways, let me add my own opinion on JSF here.
    Initially impressed, i would no longer prefer/recommend it for all future projects.
    The performance, complexity and its non-standard ajax limitations is not worth it.

    The trend is going towards more client-side code plus REST, and JSF doesnt help simplify that.
    I say Spring MVC is still the way to go, although its xml configuration history and size of its scope are too bewildering. Hope Spring can be further simplified, removing all xml config stuffs and improving in documentation.

    Play's design, particularly on use of memcache inplace of httpsession on servers is refreshing and neat. Although im not sure if such non-std design and the non-java ee web deployment is desirable. These said, Java's webframeworks certainly require urgent simplification.

    Another thing, im not enough of an expert, perhaps someone can enlighten if statefulness of JSF is critical to enterprise applications?!? (i believe theres 2 type of statefulness: page vs ejb, i assume its the former we are concerned here)

    1. I already mention that JSF is not for applications that orient on the client side and it never was; using that as an argument against JSF makes no sense, you shouldn't have considered the framework for such purposes to begin with. Play framework basically has all areas covered including security, that's why I recommend it for applications that ARE more heavy on the client side of things.

      Statefulness or statelessness is a design choice, not a feature and not tied to any platform. Both design choices have their benefits and downsides; it depends on what you'll be doing what works better.

      Remember: its too easy to blame the technology. Not being able to use something properly is generally a personal failure, not a problem of the tech. Programming is difficult and it will stay difficult no matter how the technology changes.

  10. Before doing recommendations please make sure you know what you are talking about.

    This blog post, although it contains a few valid and good points, is full of misinformation. For instance, one of them is that Wicket does allows you to customise the project layout. Here are a few references:
    - Wicket wiki
    - A nice blog post
    - Wicket in Action, (yes a BOOK), has a section about it 12.2 Customizing resource loading.

    "Remember: its too easy to blame the technology. Not being able to use something properly is generally a personal failure, not a problem of the tech."


    1. You make a valid point but "full of misinformation" is way over the line, plus you can't make any comments on "me knowing what I'm talking about" - I read plenty (including Wicket in Action) and I used every one of these frameworks personally to develop a full product. I shall remove or rewrite the specific point you mention because I agree it is my own failure and not to be blamed on the framework.

  11. After reading about so many frameworks, I'm having a hard time trying to understand what they could possibly do so much better than the others to justify their existance (I admit that I have not tested that many).

    Yet another HTML template language?
    - JSP is not that bad, IMHO. If you do not want to mix code and presentation, just don't do it.

    Yet another expression language (for the templates)?
    - Java EL and Java itself (in JSP) seem enough to me. Too much confusion with ${}, #{} %{}, @, @@, {{}}, EL, Unified EL, ONGL, Groovy, Scala, etc.

    Object-relational mapping?
    - This is not specific to web apps, and if a framework mandates a specific ORM, I think it's trying to do too much.

    Some kind of action infrastructure?
    - This might help you if you do not want to think about GET, POST, AJAX, file uploads, type conversion, etc. but in the end you can do anything with standard HTTP GET/POST, a Javascript library to facilitate AJAX and some helper methods.

    Components that completely abstract the underlying HTML and HTTP?
    - This really changes the way you write your pages and can be very powerful, but I've been burned before, that's why I prefer to write the real HTML and Javascript (with helper libraries, of course)

    And yet, none of the frameworks I tried makes things as easy as Oracle APEX. I know APEX has its own set of problems (I hate that you don't really have the source code, just some crazy exported PL/SQL that magically builds an application), but it is really easy to create interactive forms for querying and updating data.

    What do you think? Am I missing something?

    1. Sorry, but I don't see anything in there that I can actually respond to. I mean you even manage to lump together EL formatting with whole JVM languages, the only thing I think is that you are really confused and should perhaps revisit some of the material you've been reading.

      And Apex? That's woefully off-topic.

    2. I lumped those languages together because Play 1 uses Groovy as its expression language and Play 2 uses Scala. Am I wrong?

    3. I mentioned Oracle APEX because other teams at my workplace use it, and they see Java as too complex (very hard to disagree with that...).

      And yes, I am confused, because every framework I try makes me think: I could do that with JSPs too (and some JAX-RS, maybe)

    4. Ah, PL/SQL devs that live inside an Oracle DBMS all day right? For those people Apex is a gift from god; the alternative is invoking all their dangerous scripts and queries uncontrolled in production environments or at best through scheduled jobs. But that's not the target audience of this article.

      You should focus on what JSPs CAN'T do. As I mention in the article, you do *everything* yourself and that results in layers and layers of boilerplate code. If you only build simple things then that's fine. But if you build anything worth mentioning, any framework is already a huge improvement.

  12. Can you tell me something about Hibernate?

    1. Yes, the website with a very complete reference manual is here:

      Its not a web framework.

  13. Hi Eric!

    I was looking for you e-mail address but failed. Otherwise I would use that one. So if you find my message as an advertisement then please clean it away. If I see it removed I will have at least some hope that you have read it.

    Your article contains many (if not all) right statements. If I understood everything correctly one thing you say (and I 100% agree) that it would be nice if all was as simple as in JSP but could provide more functionality. All other variants gave a lot of functionality but at the cost of complexity. As a rule at a cost of a too big complexity.

    For some time (like 10 years) I was thinking in the same direction looking at as many frameworks as could be inserted into my brain. On that direction I have gradually developed my own approach that IMHO resulted in an equally (at least) powerful framework that by itself proves that most of those complexities are not necessary.

    I am speaking about HybridJava framework of mine. That is about presentation layer only, but I believe that it does that part of job _better_ than other frameworks including those considered in your article.

    I hope "will be very glad to hear where you disagree with me" is still a valid suggestion and you will find some short time to continue discussion.

    1. I don't post my email on the net for the obvious reasons of not wanting spam, I've managed to keep that contained for now and I'd like to keep it that way.

      I've not had the pleasure of using your framework even though it was mentioned once already before (sorry). Let me be brutally honest with you for a moment: you might want to reconsider your website as the color scheme does not exactly give off a vibe that it is actively maintained; it looks like the site was built over a decade ago. I had trouble finding where to download stuff. When I clicked on 'example' I was redirected to a completely different url which on top of that did not load, at least not in the 20secs I gave it. I did not see any kind of "getting started" article. You're making it very difficult for me to believe you when you say your stuff is good.

      Don't take that the wrong way, I'm not out to insult you; I'm just pointing out my "user experience". Its good that you take the time to personally post here to share your views; the aim of this article is to make it easier for people to know what to investigate and hopefully through your comment you can convince people to check out your stuff too. But not me at the moment I'm afraid (who cares, I'm just one dude).

      Cheers and good luck!

    2. I must add that my opinion stated in the above reply no longer applies; the websites has been cleaned up and is very decent now.

  14. Expanded the GWT section referring to possibilities for 'HTML 5' applications.

  15. Hi Gimby!

    I would have warned you that the site is not looking too good and that in fact I ask you to read the text rather than evaluate its look. All the site has about 15 pages when on A4 which is a comprehensive documentation and at the same time smaller than typical "getting started". is run using DynSys which is not always perfect in Europe but the release zip contains all including example to run (

    You are not "just one dude" - unbiased researches on frameworks comparison are extremely (3-4) rare. I still hope that you find more that just 20 seconds for me.

    Alex, programmer since 1972, Ph.D. in CS since 1990.
    PS. Honestly I would prefer not to load public with this.
    PPS. Competing with money-running teams in site look and feel IMHO is useless anyway.

  16. Hi, have you ever look at Portofino ?
    I tried it and it seems to me very innovative.
    I'd like to know an opinion from a scala/play user, which i never used. And if possible a comparison.


    1. Its not in the article, so nope. Glancing over the website it looks more to compete with the likes of Wordpress or perhaps Drupal with a focus on generating and building by clicking, less on being an actual web development framework for programmers which is the real topic of this article.

    2. Thanks for your reply.

      I'm not completely agree. I tried it and it has some feature similar to Drupal and Wordpress for CMS but it is also a web framework in wich you can write your pages or action in Groovy. It seems to me more similar to Ruby on Rails.
      It is based on Hibernate as ORM, you write on code in the web pages and has CRUD pages and other things that, in my opinion, make it similar to play (but i read only articles in the web), that's why I'm looking for a comparison between the two.

      However I never learned Scala, do you think Play is difficult to learn for a Java web Developer (I used Struts 1 and JSF).


    3. I'm using Play 2 for Scala, not Java. It's not that difficult after I went thru a tutorial. I came from PHP world and been learning a lot from the community everyday to discover new problems and how we can tackle the issues quickly.

      By the way, what is the purpose of comparing Portofino and Play! framework when both are built with completely different use case and purposes? You should spend some time to try out both to get a good understanding and decide which is comfortable for you.

      If you need to do lot of automation tests in the Play framework, you might find ScalaTest for Scala or Java code a whole lot easier and it's really fun.

    4. I have nothing to add over what yanli said :) Only that Play works equally well for Java. As said there are some decent books coming out (or perhaps are already out), that should make picking it up a breeze.

  17. Just to note: I remove replies with links to commercial products no matter how beautiful they appear to be, especially when posted by anonymous users.

  18. Nice article. I like your saying " its too easy to blame the technology. Not being able to use something properly is generally a personal failure, not a problem of the tech. Programming is difficult and it will stay difficult no matter how the technology changes."

    1)Would you please you please elaborate on Play is best for stateless applications?.
    I can't imagine a full stateless commercial web application
    eg: Java Web CRUD (with add,filter,edit,delete,pagination features.

    2)How best JSF 2.x for commercial Java Web CRUD applications of medium complexity for small to medium size organisation where number users are less but quantity of data could be more eg: twenty thousand to fivty thousand records of Database. All these records are applicable for filter,edit & delete operations.

    1. Thank you for your praise. Unfortunately you missed the most important statement of the entire article: "the best does not exist.". Stop thinking in terms of the best, you're not going to find it.

      "I can't imagine a full stateless commercial web application" - no webapp can be 100% stateless; you need at least something like a cookie to hold on to some sort of token which you can use to identify the client.

      I'm afraid I can't provide much of an answer to either of your questions; I don't even really understand what you're asking. But suffice it to say I can't make choices for you; if you want to figure out what works for you, you'll have to bite the bullet and go try out whatever LOOKS like it might work for you.

    2. Apologies for any miscommunication.

      I have chosen JSF 2.x for Java CRUD web-application based on my analysis.
      I am thinking for the best possibilities with JSF 2.x, PrimeFaces DataTable.

      With JSF, it was long initial pain to develop simple and standard CRUD features but I could find enough and best resources to learn JSF.
      After that JSF CRUD dataTable with create,filter,edit,delete features has been developed.
      I personally like Play.
      But it is almost impossible to hire another readily available Play developer in local market.

      You might be correct that Play hasn't been given the attention that it deserves so far;
      but I am little afraid of it's industry acceptance(= Customer,developers,programming language,total cost,demand in USA & Local markets).
      I did not like the Scala Compilation for Java app in Play framework.
      I believe Play community might be working for better java oriented framework.

      Before choosing JSF 2.x,I have considered JSP & Servlet with a JS library like ExtJS.
      I did not consider "Wickets,Struts,Spring" for my requirement of Java CRUD webapp.

    3. You don't need to hire someone that already knows "framework XYZ"; you need to hire someone that is an adequate developer. Learning to properly use a framework is then only a matter of weeks. Looking for someone that is capable is a hundred times more valuable than hiring someone that knows a particular trick; it is something that people nowadays don't seem to understand anymore.

      If CRUD is really the only thing that you care about you should have considered Ruby on Rails in stead; then you hardly even do any programming. Java is more for applications that actually do something interesting.

    4. Most of my developers are new in EJBs and JSF, because I do understand the importance of key skills.

      CRUD is primary requirement from my customer besides some DB transactions to maintain various credit, debit accounts and invoice generation and next phase would be enterprise/n-tier web application.

      I have chosen Java for CRUD webapp because the target environment is Linux.
      I am using JPA2 Eclipse link with MySql Database besides JSF2.

      Please share your thoughts on "Ruby on Rails" for CRUD(Add,filter,edit,delete&pagination)
      for medium to large enterprise applications. It would be nice, if it really scales well for enterprise applications it. Usually I consider, Java, .Net, Mobility, SOA and some open-source.
      I believe that it is very important to consider experienced developer based on the business need and etc.

  19. Optimal is yet another word for best, and there is no best. Programming languages are very much not what makes a difference, much like it doesn't matter if you take a hammer from brand A or brand B. Its you that makes the difference. Some people perform magic with C and C++, others perform magic with Java. Again: nobody will make the decision for you; I suggest you in stead look at your local job market and see what is in demand. Might be that in your environment there is demand for .NET in stead of Java.

  20. I assume you mean C++, not C. Java is IMHO superior by two reasons. 1. It is approximately twice as simple as C++ still give all the same. 2. It excludes several classes of difficult to debug errors upfront due mainly to managed memory.
    I used those languages for 15 years each.

  21. It is simpler because it is more restrictive than c++. Total freedom is still the power of c++, only really professional developers can deal with such freedom and not snow under. So to say java gives everything that c++ does is absolutely not true.

  22. Huge and in many aspects similar systems have been developed using each of the languages. Those developed in Java look more reliable and need less overhead for knowing language tricks. (In my personal experience I may compare PayPal and BofA applications I worked for).

    An anecdote from 1996. Q: What was C++ invented for? A: It was invented for six digits salaries. Unfortunately the day the IT bubble has blown up not only C++ but almost each technology turned to be a technology of job security. The word "professional" today often means having the most complicated skills regardless of their real usefulness. Examples are many.

  23. rewrote the wicket section to be more up to date with my current opinion (on Wicket 6), added links to stuff mentioned in the comments.

  24. I like the Gimby saying " to say java gives everything that c++ does is absolutely not true."

  25. Gimby,

    A simple and practical authentication with JSF2 for Loginpage and to maintain session.

    I tried with Netbeans JsfJpa example.
    Looking ahead for your valuable thoughts.

    Users table is in MySql,JSF,PrimeFaces,JPA-Eclipselink,GlassFish3.

    And also noticed while googling:

    1. Looks like you found plenty to get started with, what more thoughts do you need? I don't really dedicate articles to such specific things because they are already documented to the high heavens in a plethora of sites, I try to focus on things where I think there is not enough (correct) information on the net, or it is too fragmented.

  26. I mean examples or approach that would be good to implement a complete login,session and log-out cycle.

    Some thing like this:
    User logged and session has been created and user landed to Landing page or homePage.
    After that open the login page in a different tab/window, it should navigate to homepage;
    or it should render login page if session timed out or no session exists because user logged-out.

    1. Yes but that is incredibly basic. Google can lead you to many examples on how to do that. I tiny bit of JSF knowledge is already enough to create your own login page, if you want to use Tomcat based security then read the tomcat documentation on the subject.

      I don't see how this is on-topic in this article though, perhaps you wanted to comment on my JSF 2 on Tomcat 7 article.

    2. Yes, I know. but I was trying to implement using JSF 2 without servlet filter.
      I tried to use etc. Not tomcat please at this moment.

      I am using Glassfish 3.1 and doing with servlet filter as of now.

      Thanks Gimby.

    3. Well they certainly work, but if you want to do it properly then google is your friend: glassfish container managed authentication. I don't know anything about Glassfish myself, JBoss is the only thing I need for a JEE server.

  27. Hi Experts,

    I am new to java webapps and given a task to assess the following case study.

    - Moderate to complex front end.
    - Mix of secure and non-secure web access.
    - User authentication and authorization with LDAP
    - Business logic from simple to moderate
    - Database access for application functions
    - (optional) SOA based integration with back-end systems
    - System to support a population of around 2K users
    - High availability and DRC is must

    I need to know the following;

    1. What should be the solution components and why? What are the alternatives?
    2. Which framework or design pattern best suite this and why?

    Many thanks in advance for your help.

    1. Most of these are covered by Java and have little to do with any specific framework. High availability and load is not up to code either, its how you setup your server environment and hardware. I have no idea what SOA based integration would entail - you either use a SOA solution or you don't, its not something you tag onto your application as an afterthought. If you do need to apply a SOA system then you're in the wrong place.

      As for which framework - read the article. See how much text I wrote? That should tell you that it isn't as simple as saying go left or go right. You have to make the effort yourself to figure out what does -not- work for you, and from there make a selection from the choices left over. If you make the choice without doing some experimentation first, you're doing it wrong.

  28. Thanks Gimby,

    This is what I was thinking of that if all can be done by Java EE, for example using MVC.

    Controller: could be Servlets
    View: Could be JSP, JSF and AJAX to support complex UI navigation
    Model: EJBs and then exposing some Web Services to support with external SOA layer.

    How does this sounds to you? I also need some guidance as when and why to use framework if JEE support somehow all these?

    if it enables ease and structure approach then I do not see this in the details above rather its more confusing. Please advise.

    1. Jsf controls all. If you use it you will do the front end and the back end using it and manual ajax meddling will only lead to disaster. If you need a rich front end, dont use jsf. Which i already state in the article, I hope i didnt write it for nothing.

      Using ejb in the backend is fine, but make sure you really need it. If you dont need complex transaction schemes, its probably overkill.

      Why use something else than jee? Because you can! If you want someone telling you what to use, that is microsoft and apple territory. Java is all about freedom and choice. If you cant manage that responsibility, java is not for you.

  29. Added note that JSF can now also be stateless.

  30. JSF gets my vote. I can't understand how people say it has a steep learning curve. When I went about learning a web framework I got to JSF last on the list, largely because of negative opinion. But when I got around to it, I learned it a lot quicker than the others and in my opinion it is the best out there. The ajax support is excellent, and with third party components like PrimeFaces, I find it fits almost every need when it comes to building solid web applications.

    1. It helps to have prior knowledge of other frameworks though :) I state the reason in my article: you -need- to know how JSF ticks under the hood or you're going to use it very badly indeed. You must resist the urge to work outside of the boundaries of the framework, its do it the JSF way or be prepared to be bitten in the ass. People learning a framework tend to want to start from a "getter started" article and then slowly copy/paste things on top while staying as oblivious for as long as possible as to how it actually works. JSF does not allow that, its learn everything there is to learn about it from head to toe theoretically and practically and only then you can really use it.

    2. I agree, but even learning how it works under the hood (lifecycle, etc) is not that complicated. In saying that, I am a Java developer who works with Java EE so maybe it comes easier to me. Great write up by way, each to their own I guess ;)

    3. I had very little trouble too (and I only knew servlets, JSPs and Spring MVC at the time), but I'm guessing you, like me, are from different times :) Do you perhaps remember having to go to a bookstore to buy books to be able to learn stuff, not having the internet available to you? Those were the days where you couldn't even try (and fail) to get by doing the very minimal - you had to apply yourself to get anywhere at all. No youtube to get instructional "click here and there" videos, no forums to circumvent having to perform research, no rent-a-coder to do your homework for you, no nothing. There was only you and your brain. Better times.

  31. Hi Gimby,
    I really appreciated and enjoyed your article, its one of the better articles I've seen so far.

    In Struts2 you said "it is actually quite a clean and neat framework if you but dive into the documentation for a moment", which I understood as "documentation was not great", to which I totally and utterly agree, I had the hardest time getting answers to my questions on that site. The sentence might be a little unclear to the non-native English speaker.

    Also I had the thought (after reading our JSP intro and then the Wicket piece) that, well, maybe the reasons we moved on from JSP's can re-surface in the almost completely Java based approach too. Maybe we need some forced divide between presentation and business logic to keep us and our merry developers on the straight and narrow. Just thoughts.

    Bottom line, thank you for an informative and well formed article, I enjoyed the read.

    p.s. Regarding your "Better times" (March 20) comment... I spend a very long time trying to understand the subst command in DOS with a single book (Amstraad) and I'm very grateful for the internet these days. That said, I do miss that Eureka feeling I got back then!

    1. Once last thing...
      What about the ZK Framework ( I assume I've totally missed something, as I bet there is an obvious reason why it isn't on your list. I'd love to know what I have missed here. I know parts are costly, but the majority seems to be OpenSource ( Feature rich?? I'd say Feature silly rich. Even the guys at PrimeFaces would go quiet when demo'd some of that stuff.

    2. Very obvious reason: its part of the dozens of frameworks that I have never even taken a look at. Looks very new too, probably newer than this article. If you try it out let me know what you think in a comment. I'm more into Wicket nowadays; it takes some time learning it properly, but the flexibility of the framework is worth the effort.

  32. Great article. thanks for putting this out there.

    I'm kind of new to web programming and wasn't exactly sure what you mean when you talk about "if you require 100% control of the front end". Could you say a few words about what this means in a web app to either have (or not have) rigid control over the browser/front end?

    1. I mean you have 100% control of the HTML, CSS and Javascript side of things. For example JSF is oriented from the back-end and generates large amounts of the front-end for you, meaning you have to conform to its standards and not your own. It can save lots of time, but it makes it more difficult to integrate with existing front-end technologies.

  33. Added a section on not using Java or any other server-side web technology at all, but using purely Javascript technology.

  34. David Walsh is Mozilla’s senior web developer, and the core developer for the MooTools Javascript Framework. David’s blog reflects his skills in HTML/5, JS and CSS, and offers a ton of engaging advice and insight into front-end technologies. Even more obvious is his passion for open source contribution and trial-and-error development, making his blog one of the most honest and engaging around.

  35. David Walsh is Mozilla’s senior web developer, and the core developer for the MooTools Javascript Framework. David’s blog reflects his skills in HTML/5, JS and CSS, and offers a ton of engaging advice and insight into front-end technologies. Even more obvious is his passion for open source contribution and trial-and-error development, making his blog one of the most honest and engaging around.

  36. David Walsh is Mozilla’s senior web developer, and the core developer for the MooTools Javascript Framework. David’s blog reflects his skills in HTML/5, JS and CSS, and offers a ton of engaging advice and insight into front-end technologies. Even more obvious is his passion for open source contribution and trial-and-error development, making his blog one of the most honest and engaging around.

  37. David Walsh is Mozilla’s senior web developer, and the core developer for the MooTools Javascript Framework. David’s blog reflects his skills in HTML/5, JS and CSS, and offers a ton of engaging advice and insight into front-end technologies. Even more obvious is his passion for open source contribution and trial-and-error development, making his blog one of the most honest and engaging around.

  38. David Walsh is Mozilla’s senior web developer, and the core developer for the MooTools Javascript Framework. David’s blog reflects his skills in HTML/5, JS and CSS, and offers a ton of engaging advice and insight into front-end technologies. Even more obvious is his passion for open source contribution and trial-and-error development, making his blog one of the most honest and engaging around.

  39. David Walsh is Mozilla’s senior web developer, and the core developer for the MooTools Javascript Framework. David’s blog reflects his skills in HTML/5, JS and CSS, and offers a ton of engaging advice and insight into front-end technologies. Even more obvious is his passion for open source contribution and trial-and-error development, making his blog one of the most honest and engaging around.

  40. Admin I like this article.I was searching over search engines and found your blog site.I like your good blog site..keep doing it..

  41. I really loved reading your blog. I also found your posts very interesting. In fact after reading, I had to go show it to my friend and he ejoyed it as well!

  42. Writing a blog post is really important for growth of your websites.Thanks for sharing amazing tips. Following this steps will transform the standard of your blog post for sure.

  43. Hey there, You have done a fantastic job. I’ll definitely digg it and personally suggest to my friends. I am confident they will be benefited from this web site.

  44. Hello, the whole thing is going perfectly here and of course every one is sharing information, that’s truly good, keep up writing.

  45. Fantastic website. Lots of useful info here. I’m sending it to some friends ans additionally sharing in delicious. And obviously, thank you on your sweat!