The Fall of Server Side Web Frameworks

October 8, 2013

Developer Topics

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.

Next, AJAX and Web 2.0 lead to the release of client side JavaScript libraries such as jQuery and Dojo Toolkit.

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.

Finally, HTML 5 and mobile lead to the release of the first generation of JavaScript client side web frameworks such as Backbone.js / Marionette, Ember, and AngularJS.

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.


In some respects, Adobe had it right. I’ll admit it, I liked Adobe Flex. I liked MXML, and I liked ActionScript. The user interface was executed on the client. The enterprise services were executed on the server. It supported remote services (SOAP / HTTP / Java) and a high performance binary protocol, AMF. It supported real time data push and publish / subscribe messaging with BlazeDS or Adobe LiveCycle Data Services. However, Steve won. Adobe lost. Thankfully, the first generation of JavaScript client side web frameworks has arrived.


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.

It depends on the complexity of the JavaScript. It depends on the size of the content / data. It depends on the amount of server side resources and the number of clients.

That being said, both browsers / JavaScript engines and processors are getting faster.

It may be that this is the fall of server side web frameworks in Java. It may lead to the rise of client side web frameworks in JavaScript or to the rise server side web frameworks in JavaScript. Regardless, it will lead to the separation of front end code and back end code.

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…


About Shane K Johnson

Technical Marketing Manager, Red Hat Inc.

View all posts by Shane K Johnson

11 Comments on “The Fall of Server Side Web Frameworks”

  1. bu.f.di Says:

    thank you!!!


  2. Reza Rahman Says:

    Nice job on a potentially heated topic.


    • Shane K Johnson Says:

      Thanks Reza!

      I can tell from the comments on Twitter that I should have clarified a few things here and there. Hopefully, everyone can see what I was getting at though.


  3. guillermo Says:

    I think that you missed on GWT + ZK + Vaadin backend-frontend frameworks


    • Shane K Johnson Says:

      Don’t get me started on GWT ;)


      • Rogerio Says:

        Why? GWT is by far the best choice, if you have a Java-based backend. I used it extensively (~100K lines of GWT client-side code) for a large and complex Tomcat+Hibernate web app which originally only used Struts 1.x for the UI, and it worked very very well. New use cases implemented in GWT were much superior to the old Struts-based ones. In another project, I even got to use GWT with a C++ backend; again, with great success.

      • Shane K Johnson Says:

        Personally, I’m not a fan of any framework that generates code. If I wanted the front end to be written in JavaScript, I would have a front end developer code it in JavaScript (JS) using a JS web framework and / or library. That being said, with GWT, it depends on the implementation. Conceptually, I’m not a fan of the GWT UI framework. However, I have nothing bad to say about the declarative UI framework.

  4. jmarranz Says:

    You’re forgetting SEO compatibility, regarding SEO compatibility you must be in peace with server, that is, server is required to render HTML code to be crawled, that is when JS is ignored.

    This is one reason why Twitter was going again to server side, to avoid the dual site (single page and paged) of the previous architecture, another one was performance (rendering a HTML chunk with DB data in server may be speeder than several JSON requests and JS based HTML rendering).


    • Shane K Johnson Says:

      Sorry Jose,

      I had not seen this comment when I responded to you via Twitter. It had been flagged as spam. My bad.

      I am planning to publish another post on the role of server side rending in an era of client side web frameworks. You beat me to it ;)

      As I mentioned on Twitter, I have been thinking about PhantomJS (or something like it) with respect to server side rendering of client side web frameworks (JS) for both SEO and performance.


  5. Sebastian Stein Says:

    I fully support your observations. Few years back I was very concerned seeing someone doing a web client in pure JS (with jQuery at that time). But I think those people were right, because with the separation you get many benefits from an architectural point of view.

    – no compile time dependency between client and server code (e.g. in contrast to GWT)
    – REST/WSDL API serves as contract between client and server developers
    – REST/WSDL API gets re-used for different clients (e.g. iOS, Android, web client)

    In addition, it also lowers overall complexity for the individual developer. A JS/HTML5 developer doesn’t need to care about server code as he is just working with the API exposed by the server.


  6. Dmitry Shultz Says:

    I don’t know if I’m more server side or front end developer (by front end I mean not only the Web UI) – I’m a ‘component’ developer where component can be anything from the rest/ejb service to ui panel.

    From this perspective all the pure JS frameworks don’t come close to JSF (because it is component oriented framework). I also believe that porting client from JSF to JavaFX (in couple of years, maybe?:) will be much easier.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: