5 ways web apps and sites are the same–and different
How similarity can both unite and divide as developers seek greater control over delivery.
What’s the difference between a web site and a web app? It’s not the tools or the delivery mechanism. The differences are in the cultures and the priorities. Web development is pretty mixed up, but these are the pieces I regularly hear in the Web App vs. Web Site conversation.
1. MVC vs. HCJ
Model-View-Controller has been taking the programming side of the Web by storm since Rails brought it to prominence on the server. Rails’ vision of MVC isn’t quite canonical, but roughly models reflect data in a database, views (and their assets) are the stuff you send to the browser, and controllers provide the connecting logic.
As MVC became more familiar and as browsers became more powerful, MVC became popular on the client. I was a bit shocked the first time I heard about people building MVC-based clients on top of MVC-based servers, but Angular has made it clear that some version of MVC (MVVM in their case) will be around on the client for a long time to come.
When I hear conversations about web apps, I hear about MVC on a regular basis. Though web site folks don’t say “HCJ” all the time, it provides the foundation for those conversations. Both groups use the same tools, but the way they approach them is very different.
2. Activity vs. Content
Apps tend to be about doing something. Sites tend to be about telling something. It’s not nearly that simple of course, as sites and apps have to mix both of those aspects. The content of a catalog site tells what opportunities the site provides to buy things. Similarly, helping a user decide which action to take in a social media app requires providing content.
In that mixture, though, a basic question lurks: is the content structured around the action path, or is the action path structured around the content?
3. Interfaces vs. Pages
Within a site or an app are many individual experiences. Do we think about creating those as Web Design or User Interface (UI) design? Or do we shift gears entirely and move the conversation to User Experience (UX)?
In the early days of the Web, a site might just be one page, and grow to be a collection of pages. Templates appeared to help cover the repetition involved in those collections. The architecture of CSS evolved with those expectations, providing a way to present content across many templates. As developers learned that not everyone would visit the home page first, making sure that a site would stay navigable whatever the entry point drove much site architecture. (URLs give sites superpowers.)
Apps tend to have a single starting position that defines an interface for the whole app, though what appears there may change over time. Often all of the activity in an app runs within what for a site would seem like just a single HTML page, creating the Single-Page App (SPA) pattern. Many apps in both the Apple and Google stores are SPAs wrapped within a bit of native code, too.
While the site approach often preserves more URLs, it’s changing in ways that echo the component approach of many SPAs. The need to provide similar experiences across the infinite variety of devices on the Web has changed the notion of a page. As Ethan Marcotte points out, device-agnostic design means creating patterns rather than pages:
Over the last few years, the conversation around responsive design has shifted subtly, focusing not on designing pages, but on patterns: understanding the small, reusable elements that comprise a larger design system…. I’ve found that thinking about my design as existing in broad experience tiers—in layers—is one of the best ways of designing for the modern web.
Like the component models in so many of the app frameworks, this may lead us to Web Components—the W3C version or maybe something different.
4. Frameworks vs. Libraries
A few years ago I heard a putdown that didn’t seem to me like a putdown at first:
jQuery isn’t a framework—it’s just a library.
Google Closure and the Dojo Toolkit were the two frameworks the speaker had in mind. While I found them both interesting, they didn’t seem to have gone very far at the time, so I wasn’t sure why it was exciting. The speaker, though, was pointing to a future more firmly under the management of the programmer. That future looked largely like the “superheroic” Angular, or the “ambitious” Ember, and their many cousins.
(Also worth noting: the DIY approach of avoiding libraries and frameworks and doing your own work.)
5. Control vs. Resilience
The most important thing about the Web is that it reaches practically every platform with a connection to the Internet and a user interface. There are lots of different screen sizes, but there are also audio browsers, plain text browsers, and new interfaces as these tools find their ways into devices that don’t look like traditional computers.
Site developers tend to cheer when reminded that plain old HTML renders quickly and responsively across multiple devices. App developers have asked me a few times at conferences why anyone would care about that.
Technology may be making this divide less relevant, however. For performance reasons and to support often hostile environments, some app developers are shifting to isomorphic (or universal) development, which renders more HTML on the server when needed. It’s a technical solution for part of the problem, and probably doesn’t actually address the split in the conversation. Going the other way, Google’s AMP initiative seems like an effort to lure page-centric folks into a (deliberately limited!) app-based environment.
I would like these two paths to reunite. The first book I wrote—granted, not a good book—was on Dynamic HTML, the key first steps enabling the app world. I co-chair a conference that welcomes both app and site developers.
My forecast for the near future, though, is further separation. App developers are a smaller but rapidly growing and often highly compensated group. There are many more site developers, but much of that work is now considered ordinary, often a part of a job rather than a central focus. It is possible that new shifts in how we build them will bring them closer together, but for now I can’t see a strong reason for that to happen.