There’s a lot of discussion related to server vs client side application rendering. While there is no “one choice fits all” solution, I’ll try to argue in favor of client side (specifically AngularJS) from different points of view. First of them is architecture.
Architecture
Well done architecture has clearly defined separation of concerns (SoS). In most cases minimal high level configuration is:
- Data storage
- Services
- API
- Presentation
Each of those layers should have only minimal knowledge of the one above. Services need to know where to store data, API needs to know what services to call and the presentation layer can communicate with the rest only through the API. Important thing to note here is that knowledge about layers below should be non-existent. For example API should not know who or what will consume it. It should have no knowledge of the presentation layer.
A lot more should be said for each of those layers and the situation in the “real world” is much more complicated than this. However, for the rest of the article the important takeaway is that the presentation layer communicates with the server through the API which, in turn, does not know anything about the “world outside”. This separation is becoming more important with ever-increasing types of machines and devices (laptop, mobile, tablet, desktop). Back-end should only provide business logic and data.
Skills
Taking developers skills into account is an important aspect of the architecture. If, for example, developers are used to work in Java, one should not design a system that is based on C# unless there is a clear advantage to do the change. That does not mean that skills should not be increased with new languages (who said Scala and Clojure?). It’s just that productivity of the team must be taken into account and knowledge of programming languages are an important element.
No matter the existing knowledge, there are some skills required by the type of the application. For example, if the application will have a Web site as the presentation layer, HTML, CSS and JavaScript knowledge is a must. There are frameworks that can be used to avoid the need for that knowledge (i.e. Vaadin). However, usage of those frameworks only postpones the inevitable: acceptance that HTML, CSS and JS are, one way or another, languages that browser understands. The question is only whether you’ll adopt them directly or use something else (i.e. Java or C#) to write them for you. Later case might give an impression of being able to do things faster but, in many situations, there is a price to pay later when the time comes to do something those “translators” do not support.
Server side is easier to cope with. There are more choices and there are good (if not great) solutions for every skill set. We might argue whether Scala is better than Java but both provide results good enough and the decisions to learn a new language are much harder to make (even though I think that a developer should continuously extend his knowledge by trying new languages and frameworks). One can code the back-end in Java, Scala, C#, Clojure, JavaScript/NodeJS, etc. We don’t have that luxury in browsers. Adobe Flash is dead, Silverlight never lifted off. Tools like Vaadin that were designed primarily to alleviate the pain that JavaScript was causing are loosing their ground due to continuous improvements we’re seeing with HTML and JavaScript. The “browser” world is changing rapidly and the situation is quite different from what it was not so long ago. Welcome to the world of HTML5.
Similar can be said for development of mobile devices. There is no one language fits all. We cannot develop iPhone applications in Java. While HTML can be the solution in some cases, in others one needs to go for “native” development.
The only constant is that, no matter whether it’s Web, mobile, desktop or Google glass, they should all communicate with the rest of the system using an API.
The point I’m trying to make is that there must be a balance between the adoption of languages needed to do the work and switching to a new language with every new project. Some languages are a must and some are good (but not mandatory) to have. When working with Web, HTML, CSS and JavaScript are a must.
Server vs client side rendering
Since we established that, in case of Web sites (who said applications?) HTML with CSS and JavaScript is a must and tools that are trying to create it for us are “evil”, the question remains who renders the HTML. For most of the history of browsers, we were used to render HTML in the server and send it to the browser. There were strong reasons for that. Front-end technologies and frameworks were young and immature, browsers had serious compatibility issues and, generally speaking, working with JavaScript was painful. That picture is not valid any more. Google showed us that in many cases browser is as good as desktop. JQuery revolutionized the way we work with JavaScript by letting us manipulate DOM in a relatively easy way. Many other JS frameworks and libraries were released. However, until recently there was no substitute for the good old model-view-controller (MVC) pattern.
Server rendering is a must for all but small sites. Or is it? AngularJS changed the way we perceive MVC (actually it’s model-view-whatever but let’s not get sidetracked). It can be done in the client without sacrificing productivity. I’d argue that, in many cases, with AngularJS productivity increases. There are other client side MVCs like BackboneJS and EmberJS. However, as far as my experience goes, nothing beats AngularJS.
AngularJS is not without its problems. Let’s go through pros and cons of client vs server-side page rendering. By client side I’m assuming AngularJS. For this comparison, server-side can be anything (Java, C#, etc).
AngularJS cons
Page rendering is slower since browser needs to do the extra work of DOM manipulation, watch for changes in bind data, do additional REST requests to the server, etc. First time the application is opened, it needs to download all JavaScript files. Depending on the complexity of the application, this might or might not be a problem. Modern computers are perfectly capable to take over the extra work. Mobile devices are more powerful than older computers. In most cases, clients will not notice this increase in the work browser needs to do.
Compatibility with older browsers is hard to accomplish. One would need to render alternative pages on the server. The weight of this argument depends on whether you care for (very) old browsers. The main culprit is Internet Explorer. Version 8 works (somehow) if additional directives are applied. Earlier versions are not supported. Future versions of AngularJS will drop support for Internet Explorer 8. It’s up to you to decide whether support for IE8 and earlier is important. If it is, alternative pages need to be served and that will result in additional development time. Depending on the complexity of the application, same problem might exist in non-AngularJS development.
Search Engines Optimisation (SEO) is probably the biggest issue. At the moment, most common technique for mitigating this problem is to pre-render pages on the server. It’s a relatively simple process that requires a small amount of code that will work for any screen. More information can be found in How do I create an HTML snapshot? and Prerender.io. In May 2014 Understanding web pages better article appeared giving us good news about Google being able to execute JavaScript thus solving (or being on the way to solve) SEO problems for sites relying heavily on JS.
AngularJS pros
Server performance, if done well (clever usage of JSON, client-side caching, etc), increases. The amount of traffic between client and the server is reduced. Server itself does not need to create page before sending it to the client. It only needs to serve static files and respond to API calls with JSON. The traffic and server workload is reduced.
AngularJS is designed having testing needs in mind. Together with the dependency injection, mocking objects, services and functions it is very easy to write tests (easier than in most other cases I worked with). Both unit and end-to-end tests can be written and run fast.
As suggested in the architecture section, front-end is (almost) completely decoupled from the back-end. AngularJS needs to have knowledge of the REST API. Server still needs to deliver static files (HTML, CSS and JavaScript) and to pre-render screens when crawlers are visiting. However, both jobs do not need any internal knowledge of the rest of the system and can be done on the same or completely different server. Simple NodeJS HTTP server can serve the purpose. This decoupling allows us to develop back-end and front-end independently from each other. With client side rendering, browser is the API consumer in the same way as an Android, iPhone or desktop application would be.
Knowledge of server-side programming languages is not needed. No matter the approach one takes (server or client rendering), HTML/CSS/JavaScript is required. Not mixing server-side into this picture makes lives of front-end developers much easier.
Google support for Angular is a plus. Having someone like Google behind it makes it more likely that its support and future improvements will continue will full speed.
Once used to AngularJS way of working, development speed increases. Amount of code can be greatly reduced. Elimination of the need to re-compile the back-end code allows us to see changes to the front-end almost immediately.
Summary
This view of the client vs server-side rendering should be taken with caution. There is no “one fits all” solution. Depending on needs and solutions employed, many pros and cons listed above are not valid or can be applied to the server-side rendering as well.
Server side rendering is in many cases chosen in order to avoid the dive into HTML, CSS and JavaScript. It makes developers that are used to work with the server-side programming languages (Java, C#, etc) more comfortable thinking that there’s no need to learn “browser” languages. Also, in many cases it produces (often unintentional) coupling with the back-end code. Both situations should be avoided. I’m not arguing that server-side rendering inevitably leads to those situations but that it makes them more likely.
It’s a brave new world out there. Client-side programming is quite different from what it was before. There are many reasons to at least try it out. Whatever the decision, it should be taken with enough information that can be obtained only through practical experience. Try it out and don’t give up on the first obstacle (there will be many). If you choose not to take this route, make it an informed decision.
Client side MVCs like AngularJS are far from perfect. They are relatively young and have a long way to go. Many improvements will come soon and I’m convinced that the future of Web is going in that direction.
| Reference: | Server vs Client Side Rendering (AngularJS vs Server Side MVC) from our JCG partner Viktor Farcic at the Technology conversations blog. |
Working at a large news, sports and streaming media organization where just one of our sites can get over a million hits a minute (sometimes a second), the need to understand server vs client side rendering is extremely important. The need to understand how degradation of bandwidth or a super increase hits needs to be handled gracefully is paramount. And we have implemented multiple solutions. Publishing relatively static content with embedded widgets that provide dynamic content we use jquery, jqueryUI, and angular.js though we are moving more to angular.js because it is so flexible. However, much of our data manipulation… Read more »
I would like to correct a few inaccuracies. 1. Last time I checked Flash is not dead. It’s still on 90% of the user’s browsers, used by biggest companies (because HTML5/CSS/JS is simply not up to par), latest version Flash/AIR is 14 and has some cool stuff like multithreading/concurrency, Chrome comes with it by default, Windows as well, the tools are constantly improving and Adobe AIR is the new killer runtime for mobile that has over 1 billion app installs. Most rich media and interactive stuff including games are being built with it. AS3 has skyrocketed to 14th place from… Read more »
The adoption of Web Components will see even more UI rendering on the client, but server side rendering of cache templates will likely always have their place.
Cheers