To say the Web’s origins were humble would be an understatement.
Considered by hypertext experts at its beginning to be markedly inferior to the then state of the art, its ambitions were in many ways limited. A way to view documents, and link them together, it supported a small number of elements for structuring these documents (a few levels of heading, paragraphs, lists, and not much else) at a time when desktop publishing was making the use of fonts, images, colour, layout straightforward, even simple. The web meanwhile had none on these.
But nevertheless the Web prevailed. Why exactly is the topic of discussion for another day. Over the ensuing decade the web gained images (not entirely to the satisfaction of its inventor), the ability to style text in numerous ways, to use initially the fonts available on a user’s system, then embedded fonts (all this in the 1990s, long before the likes of Typekit), and sophisticated layout.
By the late 1990s, we were thinking of the Web as a fully fledged publication system (often tying ourselves into knots trying to smooth out the ways it differed, quite intentionally, from WYSIWYG desktop publishing).
The idea of the Web as a platform for applications that might replace the desktop computer and operating systems like Windows and Mac OS might have been the dream of at least some of us working on the Web in the late 1990s, but in truth more a pipe dream.
Fast forward to 2020, and that pipedream is a reality. On the desktop (by which I also, of course, mean the laptop) the web is the primary way by which people interact–users spend on average more time using a browser than all other apps combined on their desktop devices.
After all does anyone use a Facebook or Netflix app on their Windows or Mac computer?
On the desktop, the Web won
And yet the Web currently faces a crisis of relevance. Because the desktop is a legacy and niche platform now. And when it comes to mobile and tablet platforms that dominate computing today, the platform technologies developers have access to, the ones that matter and really make the mobile experience completely different from the desktop–device sensors and capabilities, cameras, microphones, magnetometers, geolocation, Bluetooth, NFC–are all extremely limited or simply unavailable.
Does this matter? After all, the Web did fine on the desktop even when it has never had some of the key technologies available to native desktop apps–like access to the filesystem?
the web thrives or declines to the extent it can accomplish the lion’s share of the things we expect most computers to doPlatform Adjacency Theory
On the desktop, even with limited access to the file system, by the mid 2000s, as pioneered by the likes of Gmail and Google Maps, the web could “accomplish the lion’s share of the things we expect most computers to do”.
But it can’t today. What we expect computers to do has changed.
Alex’s article was prompted in part by recent communications from the people involved in Apple’s WebKit project, as well as Marcos Caceres at Mozilla, himself a significant long-term contributor to the development of Web standards at the W3C, that due to (it must be acknowledged very real and genuine) concerns about the impact on user privacy and security, these browsers (Safari and Firefox) will not (yet) implement a raft of platform capabilities for Web developers to access, including (among others) Bluetooth, NFC, Ambient Light sensors, background geolocation, and proximity sensors.
There have been some, if not exactly heated, then let’s say uncomfortable conversations in recent weeks with push back by developers like Maximiliano Firtman, who has called this decision ‘lazy’.
It so happens I personally know Alex, Marcos and Maximiliano, the first two very well, as well as folks from the Webkit team at Apple. I genuinely believe all have the best interests of the Web at heart. I really don’t have any truck with suggestions that decisions are made at the level of browser feature implementation for overall corporate strategic reasons (for example to reduce the capability of a web browser to ensure the primacy of native apps on a platform. Your opinion may differ, but I simply don’t find this all that useful to speculate about).
But that’s not to say these decisions don’t have significant impact on the prospects for the Web, and as the title of this article makes clear, I think this is a pivotal time in the history of the evolution of the Web. I think too this is why these conversations have become a little strained. Will the Web continue to evolve, and keep up with the evolution of the underlying platforms, or will it essentially become a legacy way of developing for the desktop, and viewing content on mobile?
Imagine if the web never got CSS. Never got a way to style content in sophisticated ways. It’s hard to imagine its rise to prominence in the early 2000s. I’d not be alone in arguing a similar lack of access to the sort of features inherent to the mobile experience that WebKit and the folks at Mozilla have expressed concern about would (not might) largely consign the Web to an increasingly marginal role.
Alex Russell speaks to this issue with far greater complexity and depth in Platform Adjacency Theory, and I very much recommend you read this if it’s of interest to you.
While this issue came to a head in recent weeks around Apple’s World Wide Developer Conference, it so happens months ago we programmed our upcoming Code://Remote conference to open with Marcos Caceres and Kenneth Rohde Christiansen (currently a software engineer at Intel who’s worked for years on browser platforms, including at Nokia at the dawn of the mobile Web), who like Alex and Marcos has contributed significantly to the development of the Web (all three are or were members of the W3C’s Technical Architecture Group, an elected group at the W3C “responsible for stewardship of the Web architecture”.)
Kenneth is a driving force behind Project Fugu, “an effort to close gaps in the web’s capabilities enabling new classes of applications to run on the web”.
At Code://Remote Kenneth will be providing a detailed overview of Project Fugu, then Marcos will address in some depth the thinking behind limiting these capabilities, as well as share ways in which the underlying platform capabilities can be exposed to Web developers without compromising the privacy and security of users.
A Challenge and Opportunity for the Web
I do feel this is a crossroads for the Web. These are genuinely challenging issues. But I also feel it represents a huge opportunity for the Web as a platform.
Native Apps, available through a platform’s App Store, once promised to safeguard the user’s privacy and security, but numerous breaches, not simply by shady developers flying under the radar, but by some of the most widely used apps in the world, have exposed the fragility of the security-though-platform-gatekeeping approach.
The Web’s approach, of baking security and privacy protection into the platform itself (one simple example is only giving access to new device APIs over HTTPS connections) is a hands down a better strategy.
But the platform can’t be left to languish, which given WebKit’s browser engine monopoly on iOS, and the WebKit team’s reticence to implement access to many device capabilities, there is a very real danger of.
Discuss and learn more at Code://Remote
We’re fortunate to have several of the people at the forefront of this issue speaking at Code://Remote, one that may well determine how relevant the Web will continue to be in the coming decade.
In the late 1990s and early 2000 the idea that the Web would become the dominant platform for desktop computing seemed unlikely, just as the idea that it may become the dominant platform for mobile computing is today. And yet it happened. Will history repeat?
Conveniently timed for attendees from the North American West Coast, right across the pacific to Hong Kong and Singapore, Japan and beyond connect–with your peers at Code.