https://jakelazaroff.com/words/the-website-vs-web-app-dichotomy-doesnt-exist/ Jake Lazaroff * Blog * Projects * About * Mastodon * Twitter * GitHub The Website vs. Web App Dichotomy Doesn't Exist January 3, 2024 --------------------------------------------------------------------- * #css * #html * #javascript Table of Contents Informational Websites Transactional Websites Realtime Websites Local Websites Declarative Dynamism Async; Await Optional What Next? You don't need to wade far into web development discourse to hear about the website vs. web app dichotomy. It posits that websites can be grouped into two categories: mostly static "documents" with little user interaction beyond following links, and "applications" that involve rich dynamic behavior. Usually, people invoke it to talk about the use, abuse or avoidance of JavaScript frameworks. A more nuanced view is that there's a spectrum between website and web app, and that where a project sits determines which technologies are appropriate to build it. The implication is that at some point, it makes sense to use a JavaScript framework rather than progressively enhanced HTML. Web developers tend to divide themselves into roughly two camps here -- and depending on which camp you ask, the location of that inflection point varies widely. One camp says that everything to the left of Google Docs is a website that should function without JavaScript if possible. The other camp says that anything to the right of a WordPress blog is a web app that should be built with a JavaScript framework. Svelte creator Rich Harris speaks to this in his 2021 talk Have Single-Page Apps Ruined the Web? [maxresdefa] Have Single-Page Apps Ruined the Web? | Transitional Apps with Rich Harris, NYTimes The backlash to modern front end development is gaining steam, with good reason: single-page apps have ruined the web. Can we rescue it without going backwar... [favicon] youtu.be/860d8usGC0o . His position is that neither camp is fully correct; that most websites span regions of the spectrum rather than single points. He proposes the term "transitional apps" to describe websites that are neither fully "document" nor "application". While I agree that most websites defy binary categorization, I don't buy the overall "website vs. web app" framing. They're both nebulous terms that attempt to describe what a site is rather than what it does. Moreover, I don't think a one-dimensional spectrum can sufficiently capture the tradeoffs involved in web development. I like to think about websites along two axes: * Static vs. dynamic -- how much of the page updates in response to user interaction? * Online vs. offline -- how much functionality requires a persistent Internet connection? Obviously, this is still a pretty crude survey, but I think it broadly captures the most important architectural constraints. Let's call the intersections informational, transactional, realtime and local. Everyone loves a good quadrant chart! Informational Websites We'll start at the bottom left, at the intersection of static and offline: informational websites. I've called out WordPress, Medium and Wikipedia, but most of the web lives here: pages of unmoving text and images, connected by hyperlinks. Our measure of static vs. dynamic is how much of the page updates in response to user interaction, and websites in this category tend to just swap the whole thing out at once. Blogs, business sites, newspapers and online courses all fall under this umbrella.^1 WordPress alone powers over 40% of all websites! The key technologies in this quadrant are HTML and CSS. When JavaScript is used, it's usually for features like animations or interactive visuals that complement the textual content. At that point, people often bring in a JavaScript framework -- vastly overpowered for the majority of the website -- to accommodate the most dynamic parts of the page. More on this later. One observation about this quadrant is that even though it doesn't require an Internet connection to be usable, precious little of it is actually available offline.^2 When you're off the grid, each browser tab teeters precariously on the brink of annihilation. One errant refresh and it's gone until you reconnect! Transactional Websites If we move up to the intersection of static and online, we get transactional websites. These are so named because interaction mostly takes the form of transactions with a web server: the user clicks a button or submits a form, an HTTP request triggers a state change on the server and the whole page updates to reflect the new state. For websites in this quadrant, the server is a necessary component of all meaningful interaction. Any service that involves literal financial transactions -- like Amazon, or your bank's website -- probably lives here. So do social networks and search engines. In fact, when we exclude informational websites, most remaining websites are transactional. This quadrant tends to be the most contentious. When the JavaScript community talks about web apps, they're often referring to transactional websites -- even though many are every bit as static as this blog. Maybe that's why the JavaScript community has spent the past couple years pouring resources into improving the user experience in this quadrant. At this point, every major frontend framework includes server-side rendering out of the box. Newer features like React Server Components [og-blog] React Labs: What We've Been Working On - March 2023 - React The library for web and native user interfaces [favicon] react.dev/blog/2023/03/22/ react-labs-what-we-have-been-working-on-march-2023# react-server-components and Qwik's resumability [og] Resumable | Concepts Qwik Documentation No hydration, auto lazy-loading, edge-optimized, and fun ! [favicon] qwik.builder.io/docs/concepts/ resumable/ push even further, blending client-side and server-side code to more easily express behavior that spans network boundaries. At the same time, a more traditional approach to building transactional websites is becoming en vogue again, treating HTML as a hypermedia Hypermedia - Wikipedia [wikipedia] en.wikipedia.org/wiki/ Hypermedia that describes interactions rather than just as a rendering target for JavaScript. In the essay When Should You Use Hypermedia? htmx ~ When Should You Use Hypermedia? [favicon] htmx.org/essays/when-to-use-hypermedia/ , HTMX creator Carson Gross describes the ideal use case as "text-and-image heavy, with coarse-grain [UI] updates". That certainly describes most transactional websites, where more immersive multimedia is rare and it's common to update large swaths of the page at once. Realtime Websites At the intersection of dynamic and online, we have realtime websites. These are websites that require faster and more fine-grained updates than HTTP requests to a web server can reasonably accommodate. In 2024, the realtime website with which we're all most familiar is probably Zoom. Another popular one is Discord. In the extreme top right corner is RuneScape [franchise-] The world of RuneScape Welcome to the world of RuneScape - One world, two amazing games! RuneScape is the original game that's been evolving for over 20 years! Old School RuneScape is the game as you remember it from 2007 - improved and expanded! [favicon] play.runescape.com , a massively multiplayer online 3D video game playable in a browser. Realtime websites often use persistent bidirectional connections like websockets or WebRTC in addition to the request/response model. The server's responsibility is mostly to transmit updates between clients and to ensure that its central database remains consistent. Whereas informational and transactional websites can get by without JavaScript if they really want to, realtime websites don't have that option: they are client-side apps by necessity, and JavaScript is the only game in town. This is where frontend frameworks shine, and I think even their most hardened critics would acknowledge that it's a justified use case. Local Websites The final quadrant is at the intersection of dynamic and offline: local websites. Before the Internet, these were just normal apps: programs where all computation happened on your computer, operating on data also stored on your computer. Infeasible before JavaScript became a powerful programming language, local websites are the newest quadrant. These are the true single-page apps: everything happens on one page, because there's no web server at all.^3 Believe it or not, these website are everywhere. Every counter app and todo list made to demo a JavaScript framework is a local website. Although they're harder to monetize, they share the same advantages that informational apps enjoy: namely, that the lack of outside infrastructure makes them cheaper and easier to maintain. In the age of software as a service, prominent local websites that aren't tech demos are harder to find. One fun example is Wordle [wordle_og_] Wordle - A daily word game Guess the hidden word in 6 tries. A new puzzle is available each day. [wordle-fav] www.nytimes.com/games/wordle/index.html ! Everything from the gameplay to the word list to the share functionality runs without a server.^4 Another is Photopea Photopea | Online Photo Editor Photopea Online Photo Editor lets you edit photos, apply effects, filters, add text, crop or resize pictures. Do Online Photo Editing in your browser for free! [icon512] www.photopea.com , a Photoshop-esque raster image editor that runs entirely in a web browser. Local websites are closely related to progressive web apps [lockup] What are Progressive Web Apps? | Articles | web.dev An introduction to Progressive Web Apps (PWAs) and the three pillars that separate them from other web apps. [favicon] web.dev/articles/ what-are-pwas -- a loose term for websites that can be installed on a device, work offline and integrate more deeply with operating system features. The promise was that these websites would combine the capabilities of native apps with the reach of web apps. In practice, though, the buzz has far outstripped actual adoption, and local websites remain a marginal category compared to the other three. Declarative Dynamism From a more traditional point of view, you'd reach for a JavaScript framework to build websites in this area of the chart: If you consider yourself a JavaScript developer, the area for which you'd use a JavaScript framework might look more like this: Either way, it's clear that dynamism -- real or perceived -- is a driver of JavaScript framework adoption.^5 Increasingly, though, we're seeing people experiment with ways to express more dynamic interactions declaratively in HTML and CSS. The foremost example here is probably HTMX htmx - high power tools for html [favicon] htmx.org , which extends HTML with attributes for controlling network exchanges with a web server. By making it easy to replace smaller regions of a page with new content, HTMX allows developers to add more dynamic interactions to their websites without replacing the entire stack. There's also precedent for how this hypermedia approach might extend to local interactions. One example is Lea Verou's Mavo [logo] Mavo: A new, approachable way to create Web applications [favicon] mavo.io , which lets developers use HTML attributes to create reactive single-page web apps. In a similar vein, the Invokers proposal [that-html-] The Invokers Are Coming Yet another game changer that will make building interactive UI on the web oh so much easier. [favicon-32] thathtml.blog/2023/11/invokers-are-coming/ -- which has been experimentally implemented by all three major browsers -- defines a declarative way to trigger events on HTML elements such as and