Shifting states: modular Javascript

A few weeks ago I attended the 2013 Portland JQuery Conference, which was centered around AMD (Asynchronous Module Definition) and MVC frameworks (Model View Controller), as well as build tools that are geared toward application development. While certainly relevant to a room full of Javascript developers, it wasn’t necessarily what I was expecting from a JQuery conference. However, it got me thinking about the fine line between web pages and single page applications, and how our approach to development changes between the two.

Alex McPherson, a javascript developer at Quick Left and a contributor to many JS projects, gave a talk centered around the idea of “leveling up” your site—essentially he outlined five different approaches to development and complexity, ranging from sites with a simple slider plugin, to writing object oriented JS, to full fledged MVC single page apps. I liked his general rule of thumb—when you start having multiple document.ready calls you should start using objects, and when you start having issues with cross-class dependency and get confused about the best place to put event bindings, it’s time to modularize.

Spending the time to sit down and incorporate build tools like RequireJS and Grunt can seem like overkill if you’re developing a website and not an app. But the lines can get pretty blurry when you start manipulating the DOM and making Ajax calls to do “app-like” behavior like sorting, filtering, form submissions or drag and drop manipulation on the client-side. Web-savvy audiences expect websites to act more and more like the native apps on our phones, and we must “level-up” our approach to development.

This begs the question—how do we approach an “app” differently in the design process from a “site”? Typically, when coding up a site with a few interactive features, they end up getting tacked on one-by-one, which can make debugging and maintenance a nightmare.

An app, on the other hand, is usually built on top of a single framework with a well thought-out design pattern. Third party code is isolated and modularized, perhaps even brought into the app with an API, as mentioned by Eric Shepherd in his talk about using a library called MomentJS to handle timing utilities. Rather then referencing the calls directly inside of the app, which could lead to bugs across the app in the future should they upgrade the software, they wrapped the plugin in an API that not only matched the rest of their code, but also protected it from any potential changes that may occur with a software upgrade.

Is it really worth the effort to write our own API wrapper for a slider? As per usual, the answer is “it depends.” If you have a large ongoing project with a lot of modules running, it’s probably a good idea. But perhaps the bigger question is: Should we think of our sites as apps? Certainly there’s something to be said for decoupling everything into reusable objects, and on more complex projects, AMD modules. But on a higher-level, having a more app-centered approach, which means a more state-based/module-based approach to web development, is where the web is headed. The days of the “web page” are numbered.