Should You Use a JavaScript MVC Framework to Build Your Web Application?

This article will explain the differences between server-side applications and client-side applications (single-page applications) to help readers understand what sort their project should be built in. Server-side applications are built with languages such as Ruby on Rails, while Single-Page Applications are built with JavaScript using frameworks such as AngularJS, Ember.js, and Backbone.js.

The text summary is written by the Codementor team and is based on the Office Hours hosted by Craig McKeachie, who authored the JavaScript Framework Guide. The summary may vary from the original video and if you see any issues, please let us know!

Codementor JS Frameworks Office hours

Before we look into what sorts of projects are suitable for server-side or client-side web applications, let us first examine the architecture of both types.

How We Build Server-Side Web Applications

Here is how we traditionally build server-side web applications. A simplified explanation of what happens is an HTTP request gets made from the user’s browser to the web server, you get data back to your web server, and it’s dynamically put into an HTML template on the server. The HTML then goes back into the client.

How We Build Client-Side Web Applications (aka a Single Page Applications)

In a client-side web application, you make the same request to the server, but this time JavaScript sort of hijacks that request for a new page. At some point, either at the beginning of the application’s life cycle or when the page changes, the JavaScript pulls down an HTML template to the client as static HTML. The server’s job becomes sending down static templates and RESTful APIs to the browser, and sending back some JSON.

In other words, when somebody changes pages on a client-side application or clicks a button, JavaScript intercepts and determines what template is needed, whether an XMLHttpRequest (XHR) request should be made to get that template, and the data that goes into the template. Then JavaScript makes an AJAX call and an XHR request to the server to get the data back. As the templating engine has moved to the client, the data and template gets put together in the client’s browser.

There are a lot of ways to do a SPA. You can send tidbits of HTML back, but AngularJS, Ember.js, and Backbone.js all take the same architectural approach of combining data and the template in JavaScript on the client.

Which One Should You Use to Build Your Web Application?

When I’m thinking about whether I should do a server-side app, I ask myself if SEO is important. If SEO is integral to the app, I would shy away from using MV* frameworks. This is kind of a bold statement, but it is based on the fact that the Google search engine does not do a good job crawling JavaScript, even though AngularJS comes from Google itself. You’d usually have to build in a process that runs PhantomJS or some sort of JavaScript on the server to render your page statically and send that back when the user’s agent is Google. Thus, you can easily mess this up and in turn ruin your SEO.

I’m not saying not to use MV* Frameworks if you have a shopping cart application, as it’s perfectly fine using AngularJS, for example, in the checkout for a great user experience. However, I would really think about it before using MV* frameworks to built product pages. SEO is the common weakness for these JavaScript frameworks.

It all boils down to whether you need a hand-crafted, awesome wooden chair that’s a work of art, or if you need chairs from IKEA. If the latter, consider keeping your web app on the server. If you need that hand-crafted awesomeness and someone’s paying you to do a really responsive app with an experience akin to a desktop application, then you will be much happier using an MVC framework.

There is a slight exception with Ember, though it is a bit confusing. They have a newer HTML and templating engine, HTMLbars, that’s faster than what they previously had because it’s not string-based right now. This means there is no need for an in-memory phantom browser like PhantomJS to render your pages on the server. However, every time you configure your server you have to make sure your SEO is right and there is a chance you’d end up screwing it all up, which can make some people nervous.

In sort, the SEO downfall of JavaScript frameworks is lessened in Ember because you still have to do the server-side work, but it’s not as much setup compared to other frameworks that still have to use PhantomJS. Furthermore, it’s pretty easy as a developer to forget about URLs when you’re building an app and forget that people sometimes deep-link into certain pages. This is impossible to forget in Ember because the route comes first—you always have to declare your route object first when working on Ember apps, which is a reason it has strength over AngularJS in terms of SEO compatibility.

If Someone Already Built an AngularJS App and Want to Make it More SEO-Friendly, Is There Any Solution?

As mentioned before, SPA/JavaScript Frameworks and SEO are not very compatible. However, this is a Software-as-a-Service (SaaS) at prerender.io which basically pre-renders your pages on their server, so when web bots crawl you, your page will still be rendered. This is the simplest way to cope with general SPA problems.