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.
Well done architecture has clearly defined separation of concerns (SoS). In most cases minimal high level configuration is:
- Data storage
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.
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.
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.
Server vs client side rendering
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).
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.
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.
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.
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.
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.
I am also a Full-stack developer, already for more than 15 years and I think AgularJS means: Angular Just Sucks! All the arguments why Angular is good, separation of concerns Bullshit etc. I don’t buy them. For me its important that I can develop a good working, maintainable and testing website for the Budget I get. That why ASP.NET Mvc Rocks! And thats why I don’t want AngularJS. I saw fellow developers putting far to much time in making Angular pages work. You don’t have to do that in Server pages.
Pingback: SERVER VS CLIENT SIDE RENDERING (ANGULARJS VS SERVER SIDE MVC) | Devspaper
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.
Thanks for your article. This was very informative. I’m planning to use a combination of two in a project of mine.
Reblogged this on nerd diaries.
Another issue for clientside rendering, is support for accessability (for blind people and other disabilities).
Pingback: Client-side Rendering Pros and Cons | Stacey Learns to Code
Very good article. Thank you.
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…
Client side is much faster for developing and mocking up.
Nice article. Thank you.
I think that MVC is a great pattern for simple web applications. However it doesn’t really help when building modern and rich web applications like Facebook or Gmail. Take a look at this post for more reasons why not to use MVC:
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
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.
Pingback: maven, ivy, ant | mvnblog
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).
Client frameworks suggest that almost everything in app is done in the browser and server is just … the database.
At least in MVC there are partial views, not only data. How can we cope with this in real world where we all need to protect our products which brings us our income?
I don’t think that servers are just databases. There are very good reasons (security being one of them) for having backend services between frontends and DBs.
Am I correct in assuming that I can build a whole full-stack website with AngularJS and APIs?. For example I would build an API with, say symfony, since I’m familiar with it, and build a front end with AngularJS. I would then simply call those APIs whenever i need to do something?
Yes. That’s the idea behind not only Angular but any communication between services.
Server side rendering may be very useful for applications that would need to display / access some remote hardware datas. however I have not found any example.
What type of “hardware data” are you trying to “display / access”? If you’re referring to hardware metrics, I’d suggest you Prometheus. You can find some info in https://technologyconversations.com/2016/11/07/collecting-metrics-and-monitoring-the-cluster/ and https://technologyconversations.com/2017/07/17/building-a-self-sufficient-docker-cluster/
Excellent post and nice way of explanation. Have you written any post of vaadin or webfirmframework?
I haven’t written anything on Vaadin (yet). Maybe I will in the near future. At the moment, I’m more focused on microservices, DevOps, containers, and CD.