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:

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?

Advertisements

3 thoughts on “To SPA, or not to SPA?

  1. I’m writing a follow-up post that will hopefully help elucidate some of the very minimal comments I’ve made in this article. The main point is that we should think in terms of actual use and responsibility rather than just picking a framework or deciding thoughtlessly that we should just build a SPA.

    Liked by 1 person

  2. SPA is pushing browser limitations and giving monolithic server side frameworks big challenges. Your server side first option on the Microsoft stack for web apps (the supported main-stream enterprise choice) is ASP.Net MVC, Entity Framework, WebApi, a SQL database, all hosted on Windows servers. Basically a dependency on System.Web, even though they are trying to pull back from that in the next version. Legacy web apps run in that environment and will for a long time. SPA on the other hand is in fact a great choice to break vendor lock-in on the server side for new applications. The ecosystem surrounding it is fantastic. The fact that I can fork a repo and maintain it myself or reach out to the owner and do a pull request to fix something is the one big reason I don’t fear so many JavaScript frameworks being used for SPA. The automation practices are mature and it is up to you how far you want to take it. Monolithic server side frameworks tend to want you to do it their way. Microsoft is in fact playing catch up to SPA. The fact that they are changing ASP.Net so much and in ways that mirror SPA development approaches makes me think that they think client side SPA is the future. Have we taken it too far? Probably. The browser DOM is still with us and we are falling over backwards to keep making apps for it. This puzzles me.

    Liked by 3 people

Comments are closed.