To SPA, or not to SPA?

The hot topic in JavaScript right now typically involves which SPA framework one should use. These discussions tend to focus on one of the following:

• Web Components (e.g. Polymer)
• AngularJS
• Backbone.js Marionette.js
• Durandal
• Ember.js
• Kendo UI
• React + Flux (or Reflux)
• and a host of others

Complexity

Do you really need everything a framework provides? Frameworks typically attempt to provide everything someone may want, which means you are probably loading more JS than you need or want to use.

Maintenance

You have to maintain your own code, and frameworks can often reduce your code. However, in some cases you may find you are maintaining the framework code, either while discovering a bug or once the maintainers of the framework have gone on to greener pastures.

Performance

This can go either way. Frameworks often have developers who love to optimize, so you can gain in terms of runtime performance. However, you are also sacrificing modularity and giving in to potentially large, initial file uploads when the app is refreshed or started.

Security

In many cases, your application’s security is dependent on the solidity of the framework on which you build. If you don’t use a framework, you must deal with security aspects yourself. Of course many security issues may be addressed by small libraries that focus on that specific problem. This is never an easy problem, so no matter which direction you take, you need to plan for and build security mechanisms.

When you need a SPA

The best use of a SPA is for heavy interactions against a single concern. A good example would be to the Windows Store model, where you may find multiple applications work well together, but few apps do a lot of unique tasks. Good examples are GMail, Asana, Outlook.com, etc. These apps all do one thing, so a SPA makes sense there.

One point in particular stands out as odd to me. Why do we want to leverage browser history as a model for marking favorites or driving UI navigation? If you are doing that, you are merely moving things like rendering to the client side and away from the server. I don’t suppose there’s anything wrong with that, but is it really worth it? (Note: I think it’s fine to provide a unique app state link, but that should likely look like a SHA1 hash or GUID, not a Cool URI.)

Recall that desktop applications display multiple screens within a single window. I think that should be the goal of a SPA. In that case, bookmarking, layouts, etc. have little to do with the browser URL. If you want those, you should probably build in an app-specific mechanism for bookmarking or layout state; the browser provides poor substitutes.

When you don’t need a SPA

Am I suggesting that most apps should return to a state of no JavaScript? Certainly not! If you look at tools like Atlassian’s JIRA, you will find that most navigations use a page refresh. The only static page elements that don’t change much are the top nav bar, so you hardly notice any flicker, yet you still get a rich, interactive experience. The complexity of SPA routing, however, is removed entirely. Were you to take such an approach, you could more easily adopt an approach like progressive enhancement, as the app is not dependent upon JavaScript for its very core.

When you don’t want the complexity but don’t want to refresh static elements

You may also go a long way using a tool like pjax, which provides a means of asynchronously retrieving and replacing content using server-generated markup. This is actually quite a good use of HTTP’s hypermedia mechanism.

Conclusion

What do you think? Have we generally taken to using SPA too far? Should we scale back? Do you wish you would have considered your options more on your current or previous applications? What will you use in future applications?