Stop Making Webapps

Web applications have outlived their usefulness. Here's what should replace them.

Before the rise of the web browser, programs and documents were distinct. You developed and ran programs to make your computer do new things. You opened documents to see text, pictures, music, or whatever else you were making with your PC.

HTML is a kind of document, multimedia in nature, designed with portability in mind. It was a good choice for HTTP, a means of loading documents across a network onto a range of machines, each of which could present the document as it saw fit. For a time that’s all there was to the World Wide Web, but it didn’t last.

First the graphic designers got their hands into things and started fighting the intentionally abstract nature of HTML tags: they wanted their documents to look a particular way, down to the precise font sizes, word breaks, and other layout choices, machine differences be damned. Then someone put a JavaScript interpreter into a web browser. It was intended to do things like animate menus, but a legion of budding web developers decided to treat it as a general programming language. To them, programming meant stuffing unstructured JavaScript functions into web pages. Compilers, debuggers and the rest of the tools that served us for generations had no purpose in their world.

Today we’re in a terrible position. Users expect to run extremely large applications in their web browsers, which have become incredibly complex to accommodate them. JavaScript never matured into a real language, so we’ve had to resort to building new languages like React on top of it. Web browsers are not virtual machines, and web applications are hobbled by a myriad of performance and security restrictions that don’t affect regular software. Web developers fight a constant battle to ensure their apps remain compatible with all of the different browsers, operating systems and form factors people use.

Why do we put so much effort into making web applications work, when every computer already has a native operating system and a set of tools for developing real software?

There are two reasons. One is the “write once deploy everywhere” idea. Why make different apps for Windows and Mac, iPhone and Android, when a website will work on all of them at once? Managers and bean counters love this idea. Developers know better: in all but the simplest of cases, you’re going to put more effort into building the universal web application, and it’s going to do less. Sometimes less is OK, but if you want to build software that takes full advantage of a computer’s resources — something that can use hardware, consume network services, read and write files — you’re out of luck. Your web application isn’t going to connect to a heart rate monitor, drive a multichannel audio card, or run an LLM on the user’s GPU.

The other reason is friction. Software has to be installed. We used to install it from disks purchased at retail stores or sent to us in the mail. Now we can install software over the internet, but it’s still not as easy as typing in a web address. I blame the arbiters of the operating systems for this situation. Apple, Google and Microsoft could have made installing software as easy as typing an address or clicking a search result. The average user would never know the difference. Instead, they run app stores that require you to log in with a credit card. They make you go through a “buying” process, with multiple opportunities to bail out, even if you’re not actually being asked to spend money. And they put a burden on developers, too, forcing us to follow rules and seek approval for our apps to be listed. I cannot count the number of times I’ve heard, “people don’t want to install an app”. If it doesn’t simply appear on their screen, they can’t be bothered. I’ve had customers pay me to write mobile apps and pay me again to convert them to web sites, just to eliminate this barrier.

How do we fix this?

We must invent something: a new kind of browser, application-focused, that can host powerful software on multiple platforms with little or no installation overhead. Think JVM, except with a modern UI layer that supports touch screens and media devices, location services and bluetooth radios, accelerometers, push notifications, payments, and everything else we need to build the kinds of applications we want. This browser would not simply load pages and support scripting as an afterthought. It would load and run compiled code in a high performance, safe, cross-platform way.

What languages should it support? What programming paradigms? I won’t pretend to know. Better minds than mine will need to collaborate on the specifics.

I do know that we must design and build it ourselves, as a community, because the large tech companies won’t help. Whether as users or developers, Microsoft, Apple, and Google do not have our interests in mind. Each of them clings stubbornly to the idea that they can win market share by convincing developers to write solely for their platform. Never mind that this war has been happening for 40 years, and it’s never going to end. Perhaps it is an inevitable byproduct of the free market system, but that’s a topic for another essay.

I take no pleasure in reaching these conclusions. I learned iOS development the same year it became possible to write apps, and I still prefer it to anything else. If it were up to me, everyone would have an iPhone and a Mac and all I’d have to think about is Swift, plus whatever UI model is currently in fashion. But almost nobody can make a living selling software on only one platform, so this isn’t a commercially viable plan.

It’s been more than 30 years since the World Wide Web became a household product, and I have no problem with the continued development of web browsers and web sites that fulfill the browser’s original mission of document distribution.

Instead, I picture a world in which the web browser lives alongside a new platform designed exclusively for application development. I imagine a future in which most software is developed for this platform, running across every OS and device type without modification. There would be no CORS restrictions, no reams of third-party code libraries, no arbitrary restrictions on the use of system resources. Developers who currently code in Swift, Kotlin, c++, Python, c# or Java will be able to switch to this new kind of programming without giving up their favorite language. Teams won’t need to split their resources among two or three different product variants and managers won’t have to pay two or three times to get the same application developed.

Let’s make universal programming a reality and start working on it now!