Using Web’s Emulation Capabilities Effectively

Does it sound defeatist to “give up” on web apps?

Technically, it’s simple. The web cannot emulate native perfectly, and it never will. Native apps talk directly to the operating system, while web apps talk to the browser, which talks to the OS. Thus there’s an extra layer web apps have to pass, and that makes them slightly slower and coarser than native apps. This problem is unsolvable.

On mobile anyway, the trend certainly has continued, to the point where Facebook no longer thinks the mobile web browser is even good enough for text + photos.

The unnatural jerkiness of animations, the lack of good native support for notifications and gestures, and the increased load times for websites all make the web a subpar user experience. The counterargument has always been a reference to Moore’s law and the iteration of hardware power, but so far expectations for a good mobile experience have kept up with hardware improvements1.

Emulation

I want to take a slight detour and talk about software emulation, specifically emulating old consoles and operating systems and other pieces of legacy software. The general idea is to recreate old APIs and system-level components, and to have the old code run on top of a software-built facade for software/hardware no longer in commercial production.

The key takeaway here is that for emulators to run well, they have almost always required computing hardware an order of magnitude more powerful than the systems they were emulating; such is the cost of recreating hardware or even non-standard software as a software abstraction. Given sufficient hardware however, emulators have done an amazing job of preserving legacy software. In fact, the web browser itself has been a strong platform for emulation, from the Game Boy Advance to old Mac OSs.

The Modern Web Browser

Coming back to the modern web browser and its utility, reframing the discussion in terms of emulation provides opens up some new analogies. Outside of the aforementioned examples of actually emulating old systems, the web has mostly taken over application development on desktops, at least for programs that don’t tie into the operating system or hardware. The web browser does a good job of running as a platform which looks and feels like a 5-year-old operating system.

The reason why we run webapps on desktops and laptops is that we have not found good use for additional computing power for the past couple of years, outside of possibly high-end videography, photography and gaming. Chrome OS’s existence is based on the recognition that we’ve already peaked on the computing needs of everyday desktop software, and that baseline is now well within the web browser’s capabilities to “emulate” a desktop environment2.

In that light, it’s hardly a surprise that the web continues to suffer from a case of the uncanny UX valley and stutters just enough to collapse the entire native facade. As long as mobile hardware upgrades linearly and new software takes advantage of that added computing power3, web browsers cannot keep up with continuous evolution when everything comes with a web abstraction tax.

But once the use cases for mobile hardware stabilize, I suspect that the tradeoffs in accessibility and development costs will make the mobile web a viable platform.


  1. E.g., a mobile-optimized webapp can do a pretty good job of pretending to be a native iOS2/Android 2.x app on modern phones.

  2. Looking ahead, it may be that JavaScript will simply be the machine code for everything.

  3. This is not a given, especially as recent phones and tablets launches have focused on gaming as a core raison d’être for new hardware.

Share this article
Shareable URL
Prev Post

Building on Experience in an Engineering Career

Next Post

At the Mercy of Platforms

Leave a Reply

Your email address will not be published. Required fields are marked *

Read next