There and Back Again — Thoughts on SPAs

I’ve been doing this software thing for quite a while now. My first software job was in web development back in 1998. Since then, I’ve traveled through Simulation Systems, Embedded Systems, Tooling, Desktop Applications, Rich Internet Applications (RIA), some mobile and today I am back where I started, developing Web Applications.

Productivity Highs with RIA Frameworks

After traveling out and back, I see everything from a different perspective. Web applications, today, are incredibly different from the way they were in the 90s. The biggest difference, from my perspective, is the way we develop them. Coming from the RIA perspective, using Silverlight and Flex, I am accustomed to a certain productivity that I pine for now that I am developing for the web again.

If you know me, you know that I was a big fan of Silverlight and Flex. They were frameworks which let me develop amazing desktop experiences in the browser. I was doing things in 2007 that to this day is still impossible to do with HTML5 today. Those frameworks had one flaw, however. They required plug-ins to run.

Death to the Plug-In

I’ve never been much of an apologist for plug-ins. I saw them as a necessary evil. An evil that became unsustainable in this brave new world of mobile computing. When Apple, Microsoft and Adobe killed Silverlight and Flex, I wasn’t sad because I loved those platforms. I was sad because I knew I couldn’t be as productive writing the same kinds of applications in HTML/JavaScript/CSS.

First Generation SPA Frameworks

This is where the Single-Paged Application (SPA) frameworks came to my aid. There are too many to count, but from my vantage point, it has felt like Backbone.js and Knockout.js have been the primary options in the SPA market. I landed on Backbone.js as my go-to choice because it was a more complete solution than Knockout.js with its client-side route handling and model synchronization. I found myself at home with building SPAs because they were so similar to RIAs.

Unfortunately, my productivity never came close to that of the plug-in frameworks. Backbone.js and Knockout.js simply aren’t high enough of an abstraction for them to provide the same abilities to me. They are the first generation of SPA tools and with that brings the pains of a first-generation technology.

Filling in the Gaps

We’re starting to see some pretty nice add-ons to our first-generation tools. These add-ons fill the gaps that the frameworks leave by attempting to make you more productive. Specifically, Backbone.js has a poor view abstraction, making things like collection views and deeply nested views difficult. Marionette.js builds upon Backbone.js to provide more structure, guidance and capabilities. Using Marionette.js boosted my productivity significantly by taking care of much of the boiler-plate code that I found myself writing with Backbone.js alone. It is still not ideal, mostly because the abstractions are not extremely strong. They are strongER, but nothing compared to the capabilities I pine for. Knockout.js has a similar packaging called Hot Towel. Hot Towel fills in the holes that Knockout.js left by providing model synchronization, route handling and child view handling.

Unfortunately, these approaches only take us as far as the base technologies allow us to. Without a strong abstraction to begin with, these add-ons can only ever takes us to generation 1.5.

Second Generation SPA Frameworks

At the same time, the second generation of the SPA frameworks are coming forward. They come from a higher level of abstraction and the code you write demonstrates it by being significantly less (half or less). These frameworks (Angular.js and Ember.js) provide everything we wanted from our first generation tools but they also bring more capabilities like convention-based development paradigms and dependency injection. What’s more, we are starting to see tooling (such as Batarang) built around these abstractions which let our development lifecycle be that much smoother.

I am focusing my efforts on these second-generation tool sets for now. I am not abandoning my Backbone.js/Marionette.js tools completely, but I am not planning to invest much more time in them. Instead of patching the holes that the first generation tools created, I am choosing to spend my time using (and recommending) the next generation of tools. Specifically, I am focusing my efforts on Angular.js. It fits my development style better and I feel like the abstractions make more sense to me. I’m not knocking on Ember.js in any way. It is a fine choice, in my opinion.

The Future of SPA Development

But this isn’t where we are settling. I think it will require a third generation of tools before the SPA space really takes off. I have no idea what these frameworks will be, but I expect they will approach the productivity that I grew accustomed to with Silverlight and Flex. The levels of abstractions will be higher and the tooling will be richer. I expect that we will start to approach similar developer/designer workflows that were so amazing in the SPA days. I expect we will see multiple language integration, including debugging and profiling tools built around these frameworks. They will feel much less like a web framework and more like a desktop development framework. The user experiences we create will be comparable to the experiences we created with Flex and Silverlight.

Paying Back the Debt

The funny thing is that we will have taken 5 years to get there. It will be 5 years of stepping out of the plug-ins and into the browser so that we can achieve the same quality of application that we were already producing. In some ways, it feels like a regression, but we have to realize that the plug-ins were really just a disguised form of technical debt. They provided a one-off environment so that we were able to do things that weren’t possible in the browser, but they did so by not investing in the browser. Ultimately, the browser is the platform we were headed towards so we incurred debt. We just have to pay it off before we can really innovate again.

Conclusion

I’m excited to see where the future of front-end development goes. I’m excited to see that great strides are being made and I am happy to be at the front of the wave. The community is starting to get excited too. Here in Ann Arbor, we will be kicking off a JavaScript user group very soon which will give us a place to discuss these technologies and approaches. I look forward to chatting it up!

On a personal note

This is my last blog post written for SRT Solutions. I am moving on to something new. More on that soon.

5 Responses to “There and Back Again — Thoughts on SPAs”

  1. It doesn’t appear that you looked very closely at Durandal…I would certainly put it in the same category as Angular and Ember…but I think it let’s you write even less code because it establishes some very basic conventions; and it layers everything on top of a very robust module and composition system.

  2. Samir says:

    Thank god, I thought I was the only one that was reluctant to embrace the HTML5/JS world because of the diminished capabilities and productivity! I just hope this third generation of tools arrive soon…

  3. admin says:

    Rob, If it is anything like your other systems you have built (thinking of Caliburn in specific) then I expect great things from Durandal. I haven’t spent any time looking at it. I will now.

  4. mattjcowan says:

    Great post! I was talking to a fellow dev the other day about how we shouldn’t lock ourselves into specific frameworks, rather use the opportunity we have today to push the boundaries of what can be done (using perhaps frameworks and libraries available to spur further innovation). I do like angularjs, and am getting familiar with it more now. But I think we are now at the cusp of much newer things, that will transform HTML/CSS as we know it, even javascript. I wouldn’t be surprised if HTML itself becomes antiquated in the next few years. Why will we even need it if browsers eventually let us create our own tags and semantics (a good thing). If I can define my own tags with layout rules (size/shape/relative coordinates), observable behaviors and scope and contextual rules (angular is just the beginning IMO), we could now have a much cleaner canvas to work from. I also feel that there’s much more that could be done with ‘layers’ and ‘dimensions’ in the browser, and it would be fun to see innovation in that space as well.

  5. Todd says:

    I am just getting my toes wet with PhoneGap. I built quite a few web apps with ASP and ASP.NET eons ago. The SPA concept, the heavy use of JavaScript (compared to the simple form validation we used to do), and the mind-boggling number of JavaScript frameworks and libraries is a bit disorienting!

    Would you recommend I start building mobile web apps with bare-bones JavaScript to start out with? Or will my re-learning be easier using one of these frameworks? Is there one that might be a better fit with PhoneGap than others?

    Thanks in advance for your advice!

Leave a Reply