- Web Components (e.g. Polymer)
- Backbone.js Marionette.js
- Kendo UI
- React + Flux (or Reflux)
- and a host of others
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.
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.
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.
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
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.
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?