What advantages are conferred by using server-side page rendering?

Question

I am developing a web app and I have currently written the entire website in html/js/css and on the backend I have servlets that host some RESTFUL services. All the presentation logic is done through getting json objects and modifying the view through javascript.

The application is essentially a search engine, but it will have user accounts with different roles.

I've been researching some frameworks such as Play and Spring. I'm fairly new to web development, so I was wondering what advantages using server side page rendering would provide?

Is it: Speed? Easier development and workflow? Access to existing libraries? More? All of the above?

Answer 1

Server-side HTML rendering:

• Fastest browser rendering
• Page caching is possible as a quick-and-dirty performance boost
• For "standard" apps, many UI features are pre-built
• Sometimes considered more stable because components are usually subject to compile-time validation
• Leans on backend expertise
• Sometimes faster to develop*

*When UI requirements fit the framework well.

---

Client-side HTML rendering:

• Lower bandwidth usage
• Slower initial page render. May not even be noticeable in modern desktop browsers. If you need to support IE6-7, or many mobile browsers (mobile webkit is not bad) you may encounter bottlenecks.
• Building API-first means the client can just as easily be an proprietary app, thin client, another web service, etc.
• Leans on JS expertise
• Sometimes faster to develop**

**When the UI is largely custom, with more interesting interactions. Also, I find coding in the browser with interpreted code noticeably speedier than waiting for compiles and server restarts.

---

You might also consider a hybrid model with a light backend implementation using a front-end/back-end templating system like mustache.

Answer 2

server-side HTML generation:

• easier to debug;
• no issues with browser compatibility;
• with classical full-page server side generation it's harder to cache HTML, even if it has large invariable parts; (solution is to fetch HTML fragments via AJAX calls);
• not taking advantage of caching-proxies and CDNs for dynamic HTML;

client-side HTML generation:

• harder to debug;
• some issues with obsolete browsers;
• no problems caching HTML-templates client-side;
• taking advantage of caching-proxies and CDNs for HTML-templates and JS code;
• much lower network usage;

Note, that client-side generation is the way it's done in case of successful mobile sites, as apparently it's way more efficient with modern browsers (WebKit based browsers have some 70-80% of mobile market).

LinkedIn has article about advantages of client-side approach using dust.js as an example: "Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates"

Answer 3

It depends on what your requirements are. If you need a high performance, low latency solution that depends on a lot of small tasks, you may go with a structure similiar to what you describe. The most common solutions, in Java, PHP, and C# don't default to this though.

Most web application depend very heavily on databases - most of them so much so that pages could not render without at least one call. Obviously you do not want to expose your database publicly, for several reasons:

• Security (as Oded mentions) - you definitely do not want to expose your network publicly! Ideally the only interface to your systems from the outside should be https to your server.
• Ease of development - you really, really, really don't want to write SQL in Javascript, and the languages designed for web presentation don't work well with RDBs. They have no concept of state, for instance.

So, when you need a database, you use languages that do play nice with them like Java, C#, PHP, etc. The easiest way to generate a page turns out to be as follows: You use a templating language (most famously PHP, but JSP and ASP are two other very common languages) to construct the page. The language provides constructs that call out to other modules. In PHP this is commonly in the page or in another PHP file, using the MVC pattern. In JSP you use scriptlets or the JSP Expression Language. These other modules can to the heavy work of connecting to the DB, performing logic, and returning values to your view layer. The end result is a generated HTML page, rendered on the server and sent to the client.

When your database is on the same network as your page renderer, you get better performance as well. The client only has to do one request and receives a page - you may need to do 10-15 DB requests before you have all the information the user needs. A latency of milliseconds on your network would be seconds to minutes if the client had to do them all.

When systems grow larger, separation of concerns and core competencies become crucial. HTML is good for display. Javascript is good for dynamic content. SQL is great for querying a database, and other languages are good at business logic. Our job as developers is to use all the tools available to us to build a maintainable system. Ease of development is a huge part of a good system. In my mind, it's almost as important as performance and usability. Great systems evolve over time. Poor systems were written badly from the start and never were improved.

Answer 4

Mobile clients are usually power-, bandwidth-, and memory-constrained. It's probably better to render pages for them on server.

For desktop clients you may consider sending js + json to render the page on client, make it dynamically updatable, etc.

Answer 5

One huge advantage of server-side rendering is accessibility -- javascript based apps are still a big issue for folks without sight. That and there is this blind guy called "googlebot" who you might want to cater to. He don't do javascript so well either.