Play Framework has lost its relevance. Or has it?

The last few weeks, rather months have been very interesting for Play Framework at least at Knoldus. We end up working and custom developing large sophisticated products and very niche reactive products. Over the last few months there has been a healthy (the part where people starting pulling each others hair is omitted on purpose) on whether we should be using the Play Framework at all. The usual suspects being the client side html generation hippies who would not buy the Play philosophy at all and then we have the Play Framework fan boys who would not code in anything but Play. I carried on this debate to the Scala Days conference in SFO and also discussed it with Typesafe’s Rich Dougherty (@richdougherty) to get an idea about his thoughts. We decided to do a rundown of all the pros and cons of one approach versus the other and this is the list that we came up with.

Client Side Rendering

Here, client code drives everything from reacting to user input, querying the server for data using APIs which in most cases would return JSON, presenting the resulting data back to the user. Backbone, Angular, Ember etc would be good illustration of this strategy.

Advantages of client side rendering

1. High Re-usability – The back-end code only needs to spit out JSONs. There could be n number of clients for the same service who would be consuming these JSONs on the webapp level as well as mobile.
2. Front end can be tested in isolation from the back end.
3. The front end is totally independent of the back end and the back end can be swapped out to a different language. We did this when we converted the back-end of a product from Node.js to Scala. Read our ServiceSource case study.
4. Saving power on the server – Well, I would debate this one, but this came up as an advantage that we are pushing the processing to the client machine than the server.

Server Side Rendering
Here, the server decides what the client should render. The pieces of HTML returned by the server may contain complex client-side behaviour, which may include client-side HTML generation. This behaviour however would be limited and might not suit well for all the desktop like client applications and front ends.

The advantages are as follows

1. Code is type-safe, cleaner and easier to debug.
2. There are set standards for writing server side code. Ok, with the advent of frameworks in js there are very well defined standards in js world as well, but how many of us follow them.
3. It is faster to generate and send back HTML from server. Twitter moved from server to client only rendering and them moved back to server side rendering only to realize load time gain of 400% across different browsers.
4. Server side rendering requires a constant time over load but client side rendering defines a linear increase with load.
5. Content is visible to search engines for better indexing.
6. There is less data going down the pipe.

In general the mantra to remember is that it is a bad practice to send JSON if all that we are doing on the front end is to incorporate that JSON in page’s DOM structure. Also it is a bad practice to send HTML to the client side when the client would need to parse the HTML and do some calculations with that.

So what is the best strategy?

In my opinion, it is a hybrid approach. That means instead of delivering JSON data and baking them into the template on client side, you could render the template on server side. Once the page is loaded, next the smaller interactions come into play, thus AJAX call has to append html templates to the DOM instead of processing JSON data.

Play has a robust templating engine which would allow us to define HTML generation in a type-safe manner and then render it on the client fast. Hot reload for all code, templates, config changes, etc allows you to iterate much faster. The stateless design of the framework helps you with performance and also enables you to write non-messy code. Play is also an amazing combination of best practices like non blocking and is built on Akka thereby getting the resilience and concurrency support. Finally LinkedIn, Guardian, Klout and other high scalability sites use play which endorses its value.

So does that mean Backbone and Angular have lost the battle? No, but they need to co-exist with Play. I would propose to always render the first view with Play templating and then make JS based calls to the server to generate JSON for rendering portions on the page based on user actions. Thoughts and brickbats welcome 😉