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.