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?

  • 4
    Security is a big one. In particular when the application is dynamic and needs to communicate with a database.
    – Oded
    Commented Apr 5, 2012 at 18:36
  • 2
    @Oded - Why is security easier to do when you render the page vs. in the API? I've always thought that what you have to program is equivalent either way, but it's easier (at least for me) psychologically to remember not to trust the client when doing an API. I'm asking because if I'm overlooking something I really want to know.
    – psr
    Commented Apr 5, 2012 at 18:45
  • 1
    @psr He may not be referring to data security so much as user security (Eg. MITM exploits). Just a guess though.
    – maple_shaft
    Commented Apr 5, 2012 at 18:47
  • 1
    @psr - Agreed. However, just yesterday I answered a question where the OP had the connection string embedded in JS...
    – Oded
    Commented Apr 5, 2012 at 18:49
  • 2
    Michel K and maple_shaft - You can have an API locked down to one entry point and deliver over https. Of course you sanitize. Just as you have to sanitize when you serve HTTP. Also, it's somewhat easier to sanitize pure JSON than HTML/JavaScript, just because parsing is easier. Not sure why it would be easier to inject API code, given that you have a real parser.
    – psr
    Commented Apr 5, 2012 at 19:04

5 Answers 5


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.

  • 1
    "For "standard" apps, many UI features are pre-built" That's irrelevant, both server and client have that.
    – Raynos
    Commented Apr 5, 2012 at 19:09
  • @Raynos He hadn't mentioned using a client-side framework, but if he is using one, that's a good point. Commented Apr 5, 2012 at 19:13
  • 1
    Thanks, this is mostly the answer I was looking for. I haven't done too much with client side frameworks, but I was doing some research on dust.js based on LinkedIn's choice. I know that mustache is an alternative, but i will research it more. I will likely do some sort of hybrid, primarily I would want to push things to the server side if that can improve performance. Thanks again. Commented Apr 5, 2012 at 19:30
  • I wouldn't really consider anything listed for "Client-side HTML rendering" as an advantage. "Sometimes faster to develop" flies out the window once more than bleeding-edge browsers are considered (IE 8, etc.).
    – null
    Commented Apr 5, 2012 at 19:33
  • @peteorpeter: "Slower initial page render" - can you reference that?
    – vartec
    Commented Apr 5, 2012 at 19:46

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"

  • 1
    +1 On modern smartphones (using webkit mobile primarily), JS is not likely to bottleneck, whereas cell-network bandwidth is. Commented Apr 5, 2012 at 20:27

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.

  • you can't write SQL in Javascript Really?! Have you ever looked at StackOverflow questions for Javascript? I would beg to differ unfortunately. Granted it is the single worst thing you could possibly do in client code but...
    – maple_shaft
    Commented Apr 5, 2012 at 19:01
  • ... also I forgot about Node.JS, but then thats server JS which is a completely different animal altogether.
    – maple_shaft
    Commented Apr 5, 2012 at 19:02
  • Apparently you can - TIL! Just...wow, though. Talk about abuse of the language, though!
    – Michael K
    Commented Apr 5, 2012 at 19:03
  • 2
    The REST interface is how the client currently accesses database data via json objects. It doesn't expose everything and this application is part of a private enterprise network. One advantage of the interfaces is the ability for other applications in the enterprise to leverage any service they would like. From a development perspective, I can let front end developers do as they please in html/js/css and then they can just ping off the RESTful interface designed by the java developers. However, most of us have a blended skill set and that division may not be necessary. Commented Apr 5, 2012 at 19:34
  • 3
    -1: @MichaelK: you're discussing with a straw-man you've imagined, but has absolutely nothing to do with real life. RESTful does use HTTP. No one needs to write SQL in JS, that's what RESTful interface is for. Also RESTful does not mean, there is 1-to-1 mapping with DB queries. Your answer might have been valid in 1990's but we're in 2012 now.
    – vartec
    Commented Apr 5, 2012 at 19:51

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.

  • In practice however the exact opposite is often true. The jQuery Mobile project, in fact, is completely based on the idea of client-side rendering.
    – Pointy
    Commented Apr 5, 2012 at 18:39
  • @Pointy: yes, this can be the other way around. One should test how particular pages behave in on particular clients. Providing a link to an alternative (like 'mobile' and 'desktop' version links) may be helpful for the user, too.
    – 9000
    Commented Apr 5, 2012 at 18:43
  • Mobile today is characterized far more by high latency than low bandwidth or processing power. In the project I worked on recently, we were more concerned with page size then rendering speed - modern phones are pretty good.
    – Michael K
    Commented Apr 5, 2012 at 19:04
  • @Pointy the jQuery Mobile project is also a big pile of horrible code that shouldn't be used. Popularity !== value
    – Raynos
    Commented Apr 5, 2012 at 19:21
  • @Raynos We're actually using Jquery Mobile, with pretty good success too. Do you know something we don't? ;)
    – Michael K
    Commented Apr 5, 2012 at 19:36

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.

  • Good point, although this application doesn't require SEO because it is private, I am also developing some personal apps and that is a consideration in that arena. Commented Apr 5, 2012 at 19:39
  • Googlebot does interpret JS/AJAX for quite some time: searchenginewatch.com/article/2122137/…
    – vartec
    Commented Apr 5, 2012 at 19:53
  • @vartec : I think the key sentance in that article is "can now read and understand certain dynamic comments implemented through AJAX and JavaScript." My suspicion is it covers disqus and facebook but not your custom ajax setup. Commented Apr 5, 2012 at 21:00

Not the answer you're looking for? Browse other questions tagged or ask your own question.