5 ways web apps and sites are the same–and different

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.

The Web, though, didn’t build on MVC. It built on HTML (content structured with markup), CSS (style), and JavaScript (action). If you squint, you can very roughly describe HTML as model, CSS as view, and JavaScript as controller. HCJ isn’t a pretty acronym, and doesn’t come up easily in Google, but it’s the foundation on which web sites have been built for decades. In particular, site management expectations have driven much of the structure of CSS.

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.

Meanwhile, jQuery took less control, building on the expectation that the browser would do the work of building a page. jQuery would get busy when it was $(document).ready(). Though app builders have certainly used it, jQuery was built around the expectation of decorating a document the browser had loaded, rather than creating a document tree from scratch in JavaScript. That fit beautifully with the perspective of site builders, but wasn’t ideal for app builders, who needed something more.

The lines here are blurring again, though. Angular and Ember continue their march, but React—”a JavaScript library for building interfaces”—has gone back to the library approach. It doesn’t attempt to do as much as Angular or Ember. Like jQuery, React abstracts away much of the pain of working with the Document Object Model (DOM), but takes a very different approach to it.

(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.

The Web demands resilience from those who develop for it. As Jen Simmons pointed out in a 2014 keynote, the Web can break when developers take a JavaScript-centric approach. Progressive enhancement, building up from the simplest thing that can work, offers a path to a fault-tolerant Web.

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.

Many of those developers, instead, have opted for control: load code in an environment, figure out what that environment is, who the user is, and build a custom experience right there. React developers in particular seem to be adopting an approach that shifts style information closer to the code, for maximum programmer control. JavaScript is powerful!

It doesn’t always work, though. The JavaScript incident of 2011 was an early sign of what could go wrong, with sites that built their content from a blank page with JavaScript staying blank when a jQuery link was categorized as malware and blocked. More recently, some environments are becoming less friendly to the JavaScript that drives SPAs.

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.

On the other hand, I look at Progressive Apps and wonder if there might be a future combining traditional progressive enhancement with the power of JavaScript and ServiceWorkers. Perhaps. (It’s also not clear that SPAs and progressive enhancement are genuinely incompatible.)

What next?

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.