I am a champion of front end development.
I am a back end developer.
I can do front end development, and I have, but I would prefer not to. It is not an efficient use of my time. I can spend a day developing the foundation for an enterprise application, or I can spend a day troubleshooting a minor user interface issue. A front end developer can spend a day developing the foundation for a mobile user interface, or they can spend a day troubleshooting a minor persistence issue.
It’s like car racing. I would be the mechanic. I can drive a car, but that doesn’t mean I should be racing the car. A front end developer should be racing the car, and we should be working together. We should be collaborating (link).
The driver and the mechanic are both critical to winning a race. The driver experiences the car in one way, while the mechanic experiences the car in a completely different way. The driver can not adjust the engine, and the mechanic can not drive the car. The driver and the mechanic have to develop a way to communicate about the performance of the car.
Race-cars, Drivers, and Mechanics (link)
As developers, we apply separation of concerns to our code. Perhaps it’s time to apply separation of concerns to our deployments.
A Brief History of Web Frameworks
It begins with Apache Struts and Tapestry. Apache Struts is a push / action based MVC framework while Tapestry is a pull / component based MVC framework. Spring MVC is released as an alternative to Apache Struts because Spring Framework is an alternative to everything.
The problem is that web applications built on top of server side web frameworks tend to include both front end code and back end code. It often leads to back end developers being responsible for front end development. While a web framework should be limited to the presentation tier, web applications built on top of server side web frameworks tend to include both the logic (business) tier and the data (presentation) tier.
Next, Java 5 is released.
A new generation of lightweight, server side web frameworks are released. They leverage Java 5, and they include Apache Stripes as an alternative to Apache Struts and Apache Wicket as an alternative to Tapestry.
This leads to the release of the second generation of the original server side web frameworks. They leverage Java 5, and they support AJAX. They include Apache Struts 2, Tapestry 4, and Spring MVC 2.5.
While web applications built on top of server side web frameworks tend to include both front end code and back end code, it is now possible to separate some of the front end code from the back end code via AJAX and REST (XML / JSON) services. However, the REST services tend to be included in the web application.
There is no problem. The web framework is limited to the presentation tier. The web application is limited to front end code. It does not include back end code. The enterprise services are limited to the back end code. They do not include front end code.
I know what you’re thing. What about Twitter?
Yes, Twitter moved their front end from the client to the server (link). We still have to consider the performance of client side code versus server side code. For some web applications, the performance of server side code may be better. For others, the performance of client side code may be just as good if not better.
Then again, perhaps there are other options.
I’ll discuss them in my next post.
I did not mentioned JSF because I have little experience with it myself. Nor did I see the value in adding it. I left out a lot of web frameworks (client side and server side).
I did not mention REST and JSON. I assumed that it was a given. In my last post (link), I talked about the beginning of the end of web containers and the role of Java EE and enterprise services. Well, that includes JAX-RS and JSONP. It’s how you separate the front end from the back end.
I, myself, do not consider services (REST or WS) to be web applications. I consider them to be enterprise services. Perhaps it’s just me, but I tend to think of web applications as applications that include a presentation tier.
When I refer to web frameworks, I am referring to frameworks that generate HTML.
Now open for discussion…