Server vs client side rendering (AngularJS vs server side MVC)

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.

Advertisements

18 thoughts on “Server vs client side rendering (AngularJS vs server side MVC)

  1. Petri Kainulainen

    This is a good summary about this topic. I used to be a server side developer with a very limited understanding of frontend technologies such as Javascript. That all changed about three years ago when I started working for a company which hires only “full-stack” developers.

    I think that the biggest problem of moving from backend rendering to Javascript web applications is not related to technology. The thing is that some backend developers have a huge change resistance because they feel that this transition will make them “obsolete”. And yet, nearly everyone who has made this change (me included) is happy that they did it. It is a totally different world but in many ways it is much more pleasant than the old one.

    You mentioned that SEO can be a problem of Javascript web applications. It used to be this way but it seems that Google has started indexing webpages implemented with Javascript: http://googlewebmastercentral.blogspot.fi/2014/05/understanding-web-pages-better.html – Any thoughts about this?

    Reply
  2. Pingback: SERVER VS CLIENT SIDE RENDERING (ANGULARJS VS SERVER SIDE MVC) | Devspaper

  3. Hélio Rugani Brandão

    Good material.
    I always ask myself about this theme. What is the better approach?
    Today, I agree with the article opinion and think the layers architecture where each layer don’t know nothing about down layer is the most flexible way to build systems.
    Isolate the visual layer makes sense and allows improve technologically each layer
    with the best available on time.
    AngularJS appears recently, but it is stealing the scene and seems to be a very good option for visual layer.
    This article made a good reflection about that.

    Reply
  4. Miriam

    Another issue for clientside rendering, is support for accessability (for blind people and other disabilities).

    Reply
  5. Pingback: Client-side Rendering Pros and Cons | Stacey Learns to Code

  6. Joseph Brr

    I used to work with several frameworks server side based, I had accomplished projects using ASP, JSP, Struts, JSF, Primefaces and so on. Now in 2015, we can see the strong of JavaSCript frameworks as we never seen before. If you do things right, with good structure and following the best pratices you can do much better systems than using the old approach.
    Pages are incredibly more flexible, interactive, responsive and faster to develop.
    Frameworks like Angular.js cannot be beaten by those old frameworks, I bet that because the old guys force you to write several pieces of code, a template using JSP, HTML, DHTML or maybe XML, and after, pieces of configuration and complex setup, pieces of compiled code like Java classes, more css for style and after all of those work, at last you can see a hello world screen…
    At other hand, the client approach you only need web assets like html, css and of course, JavaScript, you can rely on this and don’t have to worry much about server for testing.
    Client side is much faster for developing and mocking up.

    Reply
  7. Pingback: Frontend JavaScripts Framework: Khởi đầu với Ember JS (Phần 1) | Một ngày code một ngày vui (≧▽≦)

  8. jeff

    with the acceptance of ES6 (angular,Typescript) impedance mismatch between the client and server has been resolved. Domain Data model reflection will be used to create messaging endpoints between the consumer and producer with directives and bindings. I will now be able to follow the same patterns (javascript , java, scala, nodjs etc) on both consumer and producer. DESIGN TO SPECIFICATIONS, not framework of the day. I am now able to control the digital stream from end to end with consistent patterns. I can now design a system that does not look like frankesteins revenge and constantly changing. It took time but finally there is a light at the end of the client framework tunnel.

    Reply
  9. Harold A. Scott

    Great article! I am working on an executive overview that I need to present to my manager, can anybody point me to some other high-level discussions on this topic, I’m not a great writer (except when it comes to code :)) and I would like to see how some people describe it in a way that’s easy for non-technical folks … Thanks

    Reply
  10. Ramesh

    Nice article. I have been thinking to render the page with front-end frameworks like AngularJS but was in the impression that it would impact my SEO. Looks like Google bots understand these frameworks and read the content in the same manner.

    Reply
  11. Pingback: maven, ivy, ant | mvnblog

  12. hr

    Can you please share some information about how Angular files can be hosted as a separate presentation layer in Apache or CDN after migrating existing Spring MVC JSP based application to Angular 2.0 (JSP being completely replaced by Angular2.0).

    Reply

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s