Jogger design decisions FAQ

Jogger is a lightweight library for building Web Applications that provides a routing mechanism and a view template engine based on FreeMarker. The source and documentation are on Github.

In this post, however, I would like to answer some questions about design decisions I made with Jogger that will help you understand the philosophy behind.

Why do we need another Java Web Framework?

I wanted a super simple Java web framework that would allow me to:

• Map HTTP requests to Java methods: similar to Play! Framework (which is inspired by Ruby on Rails).
• Use a better request/response API than the one provided by the Servlet API.
• Define views and layouts: reuse layouts in multiple views.
• Plug into any project: let me choose the project structure and the libraries/frameworks I want to use; don’t make this hard on me.
• Deploy into any Servlet Container: such as Jetty or Tomcat.
• Easy testing: test controllers and views without having to start a Servlet Container.

Why not a component based framework like JSF, Wicket, etc.?

Short answer is that they couldn't keep the promise of isolating the user from client side development and the request/response nature of HTTP. Long answer is here.

Why not using the Servlet API directly?

Because it sucks! It's difficult to test, it has an endless hierarchy of classes, exposes hundreds of useless methods and provides an inconvenient configuration mechanism. The only good part is that it doesn't try to hide the request/response nature of HTTP.

Why using FreeMarker for the view?

JSP's (Java Server Pages) were dismissed from the beginning, you just can't create and reuse a layout with them. My first options were Jade and Haml but there is not a decent implementation for Java that I know. The truth is that I am happy with FreeMarker now.

Why not using annotations instead of the routes.config file?

First, with annotations you would have all this routing configuration scattered in multiple Java files. I wanted to keep this information centralized and as simple as I could. Second, I'm against of scanning the classpath (one of the reasons I moved away from JEE), it just doesn't scale. Third, it would be a problem for hot deployment.

Why exposing the Jogger Request and Response in the controller actions?

Because I think we should embrace the fact that HTTP is a request/response protocol. You retrieve things from the request and use the response to, well, respond.

Why testing without starting a Servlet Container?

First, it's an unnecessary overhead. Besides, you wan't to test that your routing is working as expected, that your controller is rendering the correct template, etc. and I think that mocking the Servlet Container works well in this cases. It really depends on how you need to test your application.


If you have another question or think that an answer is not clear enough, ping me and I will add it or improve it. Thanks.

Java web development: back to basics

The first post that I wrote on this blog is titled AJAX: JQuery, Google Web Toolkit or RichFaces. There, I praise RichFaces for being built on top of JSF (Java Server Faces):

"If you haven't work with JSF, I really suggest you do as it is one of the most powerful, easy to learn Web technologies, very similar to swing with heavy use of components and events. It also has a really good support for managing the state in the server using plain Java objects (POJO’s)"

What has happened since? Well, after working with Wicket and Vaadin (which I still use in one of my open source projects), I have drifted away from component based web development.

The reason is simple. It doesn't have to do with performance, number of components or the size of the community. It's just that component based web frameworks couldn't keep the promise of isolating the programmer from client side development and the request/response nature of HTTP.

A leaky abstraction

Yes, I know. Every abstraction, to some degree, is leaky. However, the problem with this specific abstraction is that it leaks way too fast. You end up investing large amounts of time understanding how the framework works underneath and how to tweak it in order to achieve what you want. It's a real pain in the ass. The productivity that they promise in their "build an app in 10 minutes or less videos" is dead in the eleventh minute or so.

The other problem is that the technology underneath is moving too fast. HTML5 introduced a lot of new features such as web sockets, canvas and new data storage options. Web development is also moving towards stateless REST services and heavy clients. The future is not clear yet, though.

Back to basics

Lately, I have been working with Ruby on Rails and Express.js (Node.js). I think that their success lies in the fact that they embraced the request/response nature of HTTP. However, I don't buy the "Ruby made programming fun again" bullshit - a topic for another post -. I still like Java.

I also tried Play! Framework for a few weeks. It's an interesting option but I don't think that the solution is to copy exactly how Ruby on Rails works in Java/Scala. It's not really about productivity, it's about maintainability.

So, I'm actually using a super simple Java request/response based framework I made, HTML5, CSS3, Javascript and JQuery.