SPA, the bad things?

Question

I've been reading lately about SPA and how good it is.. I was wondering if someone could tell when should I use or even better when shouldn't I use SPA as go with regular MVC

Answer 1

I've been reading lately about SPA and how good it is..

SPAs just invert the responsibilities of the browser-client. Traditional server-side applications do most of the work in the backend. SPAs do most of the work on the front-end.

The good thing is, generating views in the client means front-end devs can do all of their design in the browser without having to worry about touching the backend.

Decoupling View from Model (ie controllers exist on both ends) means that the data can be exposed as a REST API on the server and re-used for clients that target other platforms (ex mobile, tablet, smart tv).

Eliminating the need to refresh every time a page is loaded makes for a better user experience.

I was wondering if someone could tell when should I use or even better when shouldn't I use SPA as go with regular MVC

Switching over to building SPAs from server-side MVC architectures can be very challenging for some. Many devs who work exclusive in a server-side language may just hate having to deal with Javascript (esp devs who program exclusively in statically-typed languages).

Making SPA's work requires some url-rewriting and redirect workarounds. This may be a very confusing/harrowing experience to get working for those who don't have a lower-level understanding of the server.

Users that have Javascript off by default will not be able to load the site.

A SPA introduces a lot more load on the client, with everything running in the main context this can make the UI slow/unresponsive. There are workarounds to solve this issue in newer SPA frameworks but it's good to keep it in mind.

Writing code code for the browser is a lot different than writing code for the server. There is a lot more complexity (ex the DOM) in the browser.

The toolchain for front-end development is drastically different from what you'd find being used to develop most server-side languages. Some programmers live-and-die by their IDEs.

Fetching data dynamically via Ajax can be extremely difficult at first for some. Especially, devs who don't have a solid understanding of HTTP.

---

Really, it comes down to one question. Do you want to take the time to learn how to build SPAs?

Answer 2

This blog post gives a good overview of some of the potential issues with SPAs, along with some suggestions for workarounds.

The potential issues include:

• Browsers are not the best species in memory handling and garbage collection. Specially when it comes to DOM handling. For example, elements removed from DOM are stil held in memory. If we let users to work on DOM for a long time without a refresh, Browser might struggle to cop up with memory issues

• We should ideally reuse as much as DOM elements without disposing. But even with that approach, if the user creates thousands of reusable DOM elements as she uses the application, browser may suffer in coping up. On the other hand, the memory leaks created by bad coding practices will too pile up in a long lived DOM.

• If we need the complete product suite functionality to be available as a single page application, it can be too much of JS/CSS code to be loaded at once impacting the initial load time.

Answer 3

The tooling for MVC (Rails, MVC4) is much more mature. There is far more documentation focusing on the development of traditional MVC sites. Single Page Application development is HARD. JavaScript-dense applications are difficult to write and can be extremely difficult to debug.

If you want to jump into SPA, look into John Papa's video training series on Pluralsight.com - which, to my knowledge, offers the best starting point for developing SPA apps. Or study Backbone, but that's simply not for the faint (feint?) of heart.

One futher suggestion: if you're a ASP.Net developer, look into BreezeJS (http://www.breezejs.com) for data management.