Which is the best web framework in Java world is one of the most debated topic. It's actually a highly debated topic even outside of Java but we will concentrate on Java based web frameworks. There are endless debates on this issue in project teams of all levels and people fight for it for life and death. There are people who are even happy to adopt a framework agnostic approach as it gives them more flexibility or they think so.
First let's dwell on the question of whether to use framework or not. I think there are two arguments that go in favor of no framework approach.
However before you venture into the plain servlet and JSP approach, remember that eventually for non trivial application you will land up something similar to a framework. There are usually many boiler plate patterns, for handling of them you will start up writing your own proprietary framework. Then the following question comes
Even than if you want to go for plain servlet and JSP approach, give it a deep thought many times before you convince yourself about the path you are going to take.
Now let's assume that you have decided that you want to go for one of the framework. Let's understand how the landscape of frameworks span. Fundamentally we can divide the web frameworks in three broad categories:
- MVC type frameworks: Prevents you from low level request and response processing. Struts was the undisputed king here but Spring MVC is making good inroads here. he idea here is that you donot have to do low level request and response processing. The request is parsed by the framework and sets the parameter values present in the request to attributes in java objects based on certain defined mapping. Similarly the response is created from java objects based on some mapping. Apart from that the action mapping is done which basically means that which request is handled by which method of which class. In Servlet and JSP world usually these mappings are done either by mapping servlet/jdp in web.xml based on url pattern or hitting the jsp's directly. Currently in Spring 3+ the MVC part has been completely reorganized especially using the annotation based approach. It has made, writing web applications much easier.
- Component based frameworks: It adopts more swing like programming model where you think more in terms of components and event handlers. The space is quite open. The prominent names are JSF, wicket and tapestry.In JSF itself there are many libraries. The idea here is that as a developer you basically choose your components and than bind them to the backing beans. For example the value in an input box is set as an attribute of an object and click of a button results in a method call in another object based on mapping. The low level Request Response processing is handled by the framework.
The approach here is to go to component based framework and having pages in pure html.These frameworks do have little steep learning curve but bring productivity. However be careful about the performance especially many of these frameworks provide statefulness behaviour which can quickly eat your resources. However the UI space is very rich here. Check Richfaces and Icefaces. JSF2.0 has also brought many new changes especially supporting Http GET.
There is another one vaadin also which comes in this category. I have not played with it but it seems to be a choice to evaluate.
- Javascript and HTML generator - There are third set of frameworks which provide a pure Java way of writing. GWT is one of the leading framework in this. The code is written in pure Java. There are compilers than, which convert the Java code into HTML and Javascript. They can provide very good response time to end users as a lot of code can be easily pushed to client side.
- Javascript based Single page applications - Here the front end is completely build using Js frameworks like Angular and it interacts with the back end using rest style web services and using JSON data.
At the end, I am sure you are looking for a crisp answer to which one to adopt. Unfortunately I have no simple answer to that, and I have found different frameworks useful for different situations. I will try to put some situations and the choices and the reason behind them
In almost all the situations, I would not go for a pure JSP and servlet strategy. I still cannot think of a good reason for that strategy.
If the client has something specific in mind and does not want to change the mind. The reason could be there existing stack of technology or cost consideration or that their best Beer buddies think that way, you have no choice. (Believe me, I have atleast seen one case where I thought the other choice was much better but just that one of the client's best friend thought the other way, it went the other way).
One of the strong parameter of choice is usually based on what kind of developers are available. If we have a formula one team on GWT or on JSF and there are no other special requirements, I would settle on that. It's about playing on the strength of the team.
If we do not have an existing team and we have to build one. Also the application is a standard web application with normal expectations in user about how web applications behave. One of the important behavior parameter is a slightly lagging response time. Than MVC would be a good choice. The learning curve is faster. A good choice can be Spring MVC with Spring as the backend. This provides a consistent framework to work with.
If we are looking for very rich UI and the application does not have a very strict performance requirement, JSF is a good choice. JSF libraries provide very rich UI interfaces but they carry a lot of data. Also the learning curve is steep here. However once you get a handle of it, it's very easy.
Than comes the situation when end user is looking for a desktop like behavior which basically means very fast response time. Than frameworks like GWT are a good choice. The other alternative is to use MVC frameworks and use Javascript frameworks like Dojo or jquery. Thought the learning curve of GWT is steep but it's much easier to maintain GWT based applications. A very fast response time usually means a lot of javascript code and which can easily become a maintainance headache. It's better to adopt something like GWT which can generate the code automatically.
There is one more trend you might want to check before taking the final decision. It's coming in the name of HTML5 especially the ability to provide a database at browser. But that path is still has to go some way before becoming stable. Even there is not enough consistent support from browsers.
So Good luck with your choice.
First let's dwell on the question of whether to use framework or not. I think there are two arguments that go in favor of no framework approach.
- Working with plain servlet and JSP gives you the flexibility. There are situations while using in framework where certain features are not there or not in the way you want them to be. Than getting the things you desire becomes a pain and it leads to a lot of tweaking. With Servlet and JSP everything is in your control.
- Working with plain servlet and JSP gives you performance advantages. Frameworks are written more generically and try to handle a lot of situation. But this bloats the code and hits the performance.
However before you venture into the plain servlet and JSP approach, remember that eventually for non trivial application you will land up something similar to a framework. There are usually many boiler plate patterns, for handling of them you will start up writing your own proprietary framework. Then the following question comes
- How many good developers you have got to handle these infrastructural framework development? Present day web development is not trivial. There are internationalization, AJAX, rich GUI features which are reasonably complex.
- How long these developers are going to be employed with you? What if some critical people leave than can you handle the situation?
- The proprietary in house developed framework usually lack good documentation and wide community support. This makes the ramp up of new developers very difficult.
- Eventually you will land into a situation where your own framework will start hindering your own development because of the lack of flexibility. Don't assume that you will be able to handle all the complexity in a reasonable way. This argument is a self sustaining argument and a sweet trap.
- Do you and your team better of spending their time writing business level code or infrastructural code? Better value for money.
Even than if you want to go for plain servlet and JSP approach, give it a deep thought many times before you convince yourself about the path you are going to take.
Now let's assume that you have decided that you want to go for one of the framework. Let's understand how the landscape of frameworks span. Fundamentally we can divide the web frameworks in three broad categories:
- MVC type frameworks: Prevents you from low level request and response processing. Struts was the undisputed king here but Spring MVC is making good inroads here. he idea here is that you donot have to do low level request and response processing. The request is parsed by the framework and sets the parameter values present in the request to attributes in java objects based on certain defined mapping. Similarly the response is created from java objects based on some mapping. Apart from that the action mapping is done which basically means that which request is handled by which method of which class. In Servlet and JSP world usually these mappings are done either by mapping servlet/jdp in web.xml based on url pattern or hitting the jsp's directly. Currently in Spring 3+ the MVC part has been completely reorganized especially using the annotation based approach. It has made, writing web applications much easier.
- Component based frameworks: It adopts more swing like programming model where you think more in terms of components and event handlers. The space is quite open. The prominent names are JSF, wicket and tapestry.In JSF itself there are many libraries. The idea here is that as a developer you basically choose your components and than bind them to the backing beans. For example the value in an input box is set as an attribute of an object and click of a button results in a method call in another object based on mapping. The low level Request Response processing is handled by the framework.
The approach here is to go to component based framework and having pages in pure html.These frameworks do have little steep learning curve but bring productivity. However be careful about the performance especially many of these frameworks provide statefulness behaviour which can quickly eat your resources. However the UI space is very rich here. Check Richfaces and Icefaces. JSF2.0 has also brought many new changes especially supporting Http GET.
There is another one vaadin also which comes in this category. I have not played with it but it seems to be a choice to evaluate.
- Javascript and HTML generator - There are third set of frameworks which provide a pure Java way of writing. GWT is one of the leading framework in this. The code is written in pure Java. There are compilers than, which convert the Java code into HTML and Javascript. They can provide very good response time to end users as a lot of code can be easily pushed to client side.
- Javascript based Single page applications - Here the front end is completely build using Js frameworks like Angular and it interacts with the back end using rest style web services and using JSON data.
At the end, I am sure you are looking for a crisp answer to which one to adopt. Unfortunately I have no simple answer to that, and I have found different frameworks useful for different situations. I will try to put some situations and the choices and the reason behind them
In almost all the situations, I would not go for a pure JSP and servlet strategy. I still cannot think of a good reason for that strategy.
If the client has something specific in mind and does not want to change the mind. The reason could be there existing stack of technology or cost consideration or that their best Beer buddies think that way, you have no choice. (Believe me, I have atleast seen one case where I thought the other choice was much better but just that one of the client's best friend thought the other way, it went the other way).
One of the strong parameter of choice is usually based on what kind of developers are available. If we have a formula one team on GWT or on JSF and there are no other special requirements, I would settle on that. It's about playing on the strength of the team.
If we do not have an existing team and we have to build one. Also the application is a standard web application with normal expectations in user about how web applications behave. One of the important behavior parameter is a slightly lagging response time. Than MVC would be a good choice. The learning curve is faster. A good choice can be Spring MVC with Spring as the backend. This provides a consistent framework to work with.
If we are looking for very rich UI and the application does not have a very strict performance requirement, JSF is a good choice. JSF libraries provide very rich UI interfaces but they carry a lot of data. Also the learning curve is steep here. However once you get a handle of it, it's very easy.
Than comes the situation when end user is looking for a desktop like behavior which basically means very fast response time. Than frameworks like GWT are a good choice. The other alternative is to use MVC frameworks and use Javascript frameworks like Dojo or jquery. Thought the learning curve of GWT is steep but it's much easier to maintain GWT based applications. A very fast response time usually means a lot of javascript code and which can easily become a maintainance headache. It's better to adopt something like GWT which can generate the code automatically.
There is one more trend you might want to check before taking the final decision. It's coming in the name of HTML5 especially the ability to provide a database at browser. But that path is still has to go some way before becoming stable. Even there is not enough consistent support from browsers.
So Good luck with your choice.
No comments:
Post a Comment