Client-side Rendering vs JSP's for Spring MVC Front End Dev

Question

Firstly, a note on the app I'm about to discuss: It's quite large, on the order of magnitude of a service app like Airbnb -- i.e., it's not just a static web page, it is a full web application. It's in the early stages of development.

Here's the question:

I'm about to begin a rigorous dive into front-end dev and want to make sure I'm setting myself down the right track. The back-end is built with Spring MVC design, and the limited front-end work I've done so far uses Twitter Bootstrap in JSP's and some simple JavaScript. I haven't had any issues per se with that stack, but I have the following concerns:

Ease and/or Standardization of Development

The JSTL syntax required to make highly-interactive pages via JSP's is getting awfully unwieldy. I'm worried that, when we expand our project and bring on more engineers, there will be a steep-ish initial learning curve, followed by a persistent slow-down in the dev process due to verbosity of JSTL.

Using JSP's also seems like a less contemporary approach to front-end dev, in light of how many JS frameworks are popular. I'm imagining it'd be tougher to field a team of front-end or full-stack engineers if we build with JSP's.

Should I not worry so much about these issues? Are there pros of server-side rendering with JSP's that outweigh dev concerns? Can you offer a sense of how wide-spread familiarity with JSP dev is?

Performance

Server-side rendering has been great for my testing, so far -- but what happens when our app is a massive, historic, global success and downright phenomenon? Will the server get bogged down with all the rendering, if done in JSP's? Or are traffic concerns better addressed by load-balancing requests to the server and leaving the server-side rendering in place?

Maintenance Costs for Server-Side Rendering from a Cloud-hosted Server

Along the lines of the performance concerns above, if the app gets a lot of traffic and is rendering views server-side, won't our bandwidth usage go way up? We'll be deploying on AWS, which is semi-unfamiliar territory for me, but I'm presuming we'll pay according to how much bandwidth we consume. Pushing view rendering duties onto client browsers seems like a cost-effective strategy for a cloud-hosted app such as ours. Am I mistaken in that thinking?

Cross Browser Compatibility

Our app will be marketed to clients who are unfamiliar with technology. I think it's reasonable to assume that such clients will be disproportionately likely to have out-of-date browsers. Old browsers may have compatibility issues with JavaScript rendering -- and ever worse issues with the most modern JS frameworks.

Are there enough compatibility solutions in modern JS frameworks to resolve this concern? Or is server-side rendering the best-bet, in light of the likelihood of running on outdated browsers?

---

After doing some research on these issues, I've got four strategies in mind, for going forward:

1. Avoid client-side rendering. Learn to love the JSTL chunkiness, stay with all JSP's.

2. Mark up all static HTML elements in the JSP's, then populate dynamically generated values/properties/elements according to user interaction (lots of JS, AJAX).

3. Make a minimal HTML markup in the JSP's, then populate everything in the view with appends to the DOM when the page loads.

4. Completely migrate away from JSP's, use something like AngularJs.

Basically, all options represent varying degrees of moving away from server-side rendering and towards client-side rendering. Which of these sounds like the best course of action? Is there an option I've overlooked?

It's still early enough in the front-end dev process to integrate completely novel techs, and I'm new enough to web dev that any of the strategies will involve considerable self-teaching, so nothing should be considered off the table. I'm leaning towards solution strategy #2, so far, as this model would be the least drastic change from the current approach. But, in the interest of building in a way that'll make future builds easier, and be the most accessible for collaboration, #4 is also looking good.

Answer 1

The JSTL syntax required to make highly-interactive pages via JSP's is getting awfully unwieldy. I'm worried that, when we expand our project and bring on more engineers, there will be a steep-ish initial learning curve, followed by a persistent slow-down in the dev process due to verbosity of JSTL.

That is a legitimate concern.

Using JSP's also seems like a less contemporary approach to front-end dev, in light of how many JS frameworks are popular. I'm imagining it'd be tougher to field a team of front-end or full-stack engineers if we build with JSP's.

If you choose technologies that are suitable for your particular task in areas like ease of use, maintainability, sensible management of complexity, flexibility, and appropriateness for your application's specific functional and non-functional requirements, you will find people who know how to develop and maintain software using them.

Server-side rendering has been great for my testing, so far -- but what happens when our app is a massive, historic, global success and downright phenomenon?

If, and when, that happens, it will be a good problem, because then you'll have the money to fix it. Every large company has had to do this; they built their product on a platform that got them to market quickly, and re-built it (in some cases, from the ground-up) when the number of users became enormous.

That said, I think you can make some sensible choices early on. Unless your system requirements demand large, overblown architectures (they don't), avoiding them and choosing more nimble and flexible technologies will generally give you better overall performance and better adaptability.

Pushing view rendering duties onto client browsers seems like a cost-effective strategy for a cloud-hosted app such as ours. Am I mistaken in that thinking?

No. However, have a look at this Basecamp article.

Our app will be marketed to clients who are unfamiliar with technology. I think it's reasonable to assume that such clients will be disproportionately likely to have out-of-date browsers. Old browsers may have compatibility issues with JavaScript rendering -- and ever worse issues with the most modern JS frameworks.

There's just no excuse for this anymore. If your clients want to use computers in the 21st century, they need a modern browser, and it's easier than it's ever been to get one and allow it to maintain and update itself automatically and indefinitely.

After doing some research on these issues, I've got four strategies in mind...

The way of the future is so-called microservices and client-side UI such as Angular. And no, I don't think this just a fad. Users demand high interactivity with their software applications, and this arrangement can give it to them. Your back-end JSON web services can be built with anything you like; Node.JS, ASP.NET Web API, whatever. Maintaining this sort of modularity will make it possible to change out one component without affecting the others.

Answer 2

Although, the question may be answered and you decided to accept this answer, I want to highlight the topic from another side.

1) JSP as a templating system

As a templating language, I think, JSPs are good like any other. You may find, that Thymeleaf suits your needs better, but that's subjective. JSPs are an old - or better mature - technique to get content to the client. In that it is comparable to ASP or even PHP.

The main downside to JSP as a language is, that it is XML-based and as such has a lot of visual overhead or noise. In thus it is comparable to Chameleon (a Python template engine). That makes it sometimes hard to understand.

A much more cleaner way of doing this is, e.g. Pebble.

2) Server-side-rendering

As of 2016 serverside rendering is not dead. On the contrary, if you take Twitter as an example:

The bottom line is that a client-side architecture leads to slower performance because most of the code is being executed on our users’ machines rather than our own.

Of course, there are client-side frameworks like: React, Angular or even Vue.Js. But what they have all in common is, that they are bloated. And I am saying this not, because I do not like them, but I want to emphasize, that using a Javascript framework like Angular comes at a cost, which might not be realized at first sight - our desktops are fast and our connection is stable and fast too - but if you look at mobile, the whole picture changes.

There are mainly three costs on mobile:

1) Rendering

2) Performing

3) Battery drain

Performing bad in any one of these categories, makes you loose customers. Performing in more of these is even worse.

So there are three ways to solve this problem:

1) Getting started really fast

2) Make as less calls after the page is initially loaded as necessary

3) Reduce fanciness without renouncing an appealing design

This is, where server-side rendering comes (again) into play. To get the page initially up and running, it is necessary to deliver as many information (is necessary) at the first load of your page. Who said, that your server needs only to render your HTML? You could render a startup portion of JS on page with a script-tag. Of course we were told, years ago, to separate Javascript into its own files, but in need of performance, you have to blurry the lines a bit.

So what about JSPs? With expression language and some JSTL (e.g. <c:if>) you have all, you'll ever need.

3) Regarding your concerns

The JSTL syntax required to make highly-interactive pages via JSP's is getting awfully unwieldy. I'm worried that, when we expand our project and bring on more engineers, there will be a steep-ish initial learning curve, followed by a persistent slow-down in the dev process due to verbosity of JSTL.

From what was said: Yes, there is a big degree of verbosity if you excessively want to use every feature JSPs offer, but if you reduce your language set, JSPs are not that different from other templating engines.

Server-side rendering has been great for my testing, so far -- but what happens when our app is a massive, historic, global success and downright phenomenon? Will the server get bogged down with all the rendering, if done in JSP's? Or are traffic concerns better addressed by load-balancing requests to the server and leaving the server-side rendering in place?

The question makes wrong assumptions about how a webpage is assembled and deliverd to the client. In terms of 2000 there was the big fat web server, serving all of the hundreds of thousands of users a website had at that point. If you needed more performance scaling up was the way to go. But as we know today, this only works to a limited degree. Instead of scaling up we scale out, having more and more smaller servers taking off the load.

In the context of 2000 your question made sense: If you have one fat server, serving millions of requests and doing all the business logic alone, you had a performance problem- but not due to website templating (remember: JSPs are precompiled and that makes stuff really fast).

Today you are separating functionalities and refactor portions of your application to separate services (some call them microservices, I like the term focussed service or self contained systems better.

So you balance the load by design. And the effect of templating is still marginal.

Along the lines of the performance concerns above, if the app gets a lot of traffic and is rendering views server-side, won't our bandwidth usage go way up? We'll be deploying on AWS, which is semi-unfamiliar territory for me, but I'm presuming we'll pay according to how much bandwidth we consume. Pushing view rendering duties onto client browsers seems like a cost-effective strategy for a cloud-hosted app such as ours. Am I mistaken in that thinking?

If delivering gzipped content eats your bandwith and so your budget, you are clearly in the wrong business.

Are there enough compatibility solutions in modern JS frameworks to resolve this concern? Or is server-side rendering the best-bet, in light of the likelihood of running on outdated browsers?

Answering that would lead too much off topic. But let me mention a nice architecture style which embraces the fact, that not all of your users are up to date or have turned JS off; it is a new take on progressive enhancement: ROCA - http://roca-style.org/