From the Web to the Future
Published: 2018-05-30
This article is an edited transcript of a talk I gave during a departmental presentation at my company.
The article follows a chronological thread, starting from the history of a familiar internet technology form (the browser). By reconstructing key milestones and drawing lessons from history, it summarizes instructive principles to help us collectively anticipate future directions in technology.
Birth of the web
In March 1989, while working at the European Organization for Nuclear ResearchTim Berners-Leewrote down hisoriginal concept of the World Wide Web (Web)He proposed the idea of the Web as a global hyperlinked space for information sharing — an abstract (hypothetical) information space that serves as an application architecture on top of the Internet.The primary purpose of the web is to provide people with information and information services.From the start it was open to everyone, welcoming contributions and participation: anyone could create and share content on the Web, and everyone could distribute, access, and use information.
From a technical perspective, the essence of the Web architecture has three parts:
Using hypertext technology (HTML) to connect pieces of information;
Using a uniform resource locator technology (URI) to precisely locate information globally;
Using a new application-layer protocol (HTTP) to enable distributed information sharing.
Each of these three features directly relates to the distribution, retrieval, and use of information.
Since the web is an abstract, imaginary space, it naturally required a tool to access that space. So in 1990 Berners-Lee wrote the world’s first web browser.
1990 – the world's first web browser
The World Wide Web (WWW) was created by a group of scientists at CERN to make it easier to view documents and share papers. It consisted of HTML pages written with markup and hyperlinks composed of text and images. As web pages moved from academic institutions to the public sphere, their functions expanded beyond academic use, and the early limitations of web pages gradually became apparent.
All web pages were based on HTML pages.Because there was no way to control the display or hiding of local content, any local change—even a single punctuation mark—required downloading an entirely new page.
Computational tasks could only be performed on the server side.Due to limited network speeds, communication with servers was very slow and synchronous blocking. This led to scenarios like form validation: a user submits a form, the entire page disappears and the browser shows a blank screen; after a long wait the browser renders an identical page with only a small red error message next to an input field: "username incorrect."
All pages were static.This meant that an e-commerce site with a thousand products, even if the page layout was identical, had to create a thousand separate pages.
P.S. In 1994 PHP enabled interaction with databases and provided template engines for generating dynamic pages, becoming the most mainstream server-side language in the Web domain. In 1995 Netscape introduced JavaScript, enabling client-side computation (e.g., form validation). In 1999 Microsoft introduced ActiveX for asynchronous data transfer, which led to the later technologies that allowed web pages to become web applications, notably Ajax. Ajax gained huge attention especially after Google used it to build Gmail (2004) and Google Maps (2005). It marked the arrival of Web 2.0. (Web 1.0: static pages, pure content display. Web 2.0: dynamic pages, rich interaction, client-side data processing.) In 2006, XMLHttpRequest was formally incorporated into the W3C standards.
By this point, the early Document had finally evolved into the Web page, and the three limitations mentioned above were properly addressed.
The extraordinary year 1994
1994 can be seen as the starting point of front-end history; on October 13 of that year Netscape released the first version of Navigator;
That year Tim Berners-Lee founded the W3C; today,various web-related technical standards are managed and maintained by the well-known World Wide Web Consortium (W3C).
That year Tim’s close friend released CSS. Also that year, the server-side scripting language PHP, designed for dynamic web pages, appeared.
Here an important company is mentioned –Netscape, whose history mirrors the early development of the web.
Silicon Valley legend - Netscape
Besides JavaScript, Netscape also catalyzed Java. Netscape Navigator defined other features of modern browsers, such as cookies, HTML frames, automatic proxying, and more. Before 1995 Netscape set browser standards. With so many advanced features, Netscape Navigator was once the world’s most popular browser.
But Netscape’s life was short. Founded in 1994, it was acquired by AOL in November 1998 and dissolved in 2003. This was related to two major setbacks: the dot-com bubble and the browser wars.
The dot-com bubble
The 2000 dot-com bubble story starts with Netscape’s IPO. The IPO’s unexpectedly strong performance greatly stimulated market investment enthusiasm. In August 1995,Netscape’s stock on Nasdaq rose as much as 154% intraday and closed up 86%.Netscape’s astonishing stock performance helped spark the venture capital frenzy of the late 1990s in the U.S. Most capital rushed into the internet industry. Popular stocks like Amazon and eBay rose tens of times. Starting in January 2000, the previously sought-after internet stocks were suddenly heavily sold off, eventually causing a crash in the Nasdaq market.
The browser wars
Netscape pioneered the consumer browser market. Just as they were expanding, Microsoft — the dominant force on computer platforms — launched an all-out attack on Netscape with Internet Explorer (IE), starting the "first browser war" (1995–1999). IE 1.0 was released in August 1995, and bundled with Windows it used that advantage to overwhelm Netscape, achieving a market share of about 90%. For most people, the browser became the blue “e” on the desktop — Microsoft’s IE was for years practically synonymous with browsers.
Netscape later open-sourced Navigator, creating Mozilla and spawning the Firefox browser. In the second browser war from 2005 to 2007, IE’s share was eroded. After that conflict, Firefox’s share in North America and Europe approached or exceeded 20%, and Microsoft’s global share fell from IE6’s peak of 96% down to about 85% and eventually stabilized around 60% by the end of 2007. IE was no longer the "only browser." Although Firefox’s performance was far superior to the stagnant IE, Windows’ bundling advantage remained so strong that Firefox never fully caught up.
Until 2008, when Google launched Chrome. With excellent performance, a clean interface, and the advantage of bundling Google Search, Chrome rapidly gained market share, eroding both Firefox’s share and attacking the aging Microsoft IE. By 2012 it became the market leader.
The mobile internet era
2007 the firstiPhonewas released;
2008 the firstAndroidwas released;
2014the fifth generation HTML standardwas released;
HTML5 (H5) is a set of web application specifications led by browser vendors (Opera, Apple) in cooperation with the W3C, and it continues to be supplemented with new drafts. You can clearly sense the ambition behind these specifications: to occupy every screen.
Google Chrome’s greatest competitor was no longer other browsers but an adversary outside the browser —native applications (Native App).
Thus emerged the debate between Web App and Native App. Before discussing that, it’s useful to review the history of HTML5, because it reveals basic principles that shape the direction of technological development.
Deriving development principles from HTML5’s evolution
Openness
From HTML5’s historical development we learn: versions after HTML 2.0 were drafted and maintained by the W3C. From 1997 to 1999 HTML rapidly iterated from 3.2 to 4.01. The problem was that by the time of 4.01, the W3C’s perspective regressed: they didn’t stop developing the language, but they lost interest in HTML.They proposed the concept of XHTML, which required marking documents as XML. XML and HTML are both markup languages; the difference is XML’s stricter syntax (theoretically more perfect), such as requiring lowercase attributes and quoted values.The fatal flaw was XML’s error-handling model: if the parser encounters an error, it stops parsing.As a result, any single error could crash the browser and the user would see no page content.
This violated an important design principle, namely the famousRobustness principle (Postel's law): be conservative in what you send, be liberal in what you accept.Being liberal in what you accept is the foundation of the Web. Browser developers must be open-minded and accept anything sent to the browser, including content that is not fully standard or well-formed — that tolerance drives the Web’s growth. In a sense,the Web followed a chaotic development path that, though messy, was incredibly productive and appealing.As professionals, we should be conservative when sending documents — follow best practices and ensure good document formatting. But from the browser’s perspective they must accept any document. An overly strict error-handling model contradicts the principle of being liberal in acceptance and thus opposes Postel’s law.
User-first
Because of these philosophical differences, in 2004 vendors led by Opera left the W3C to formWHATWG, re-engaging in HTML’s development. Later the W3C and Tim Berners-Lee realized the directional mistake, abandoned the impractical XHTML standard, and returned to HTML standardization. Now they work in harmony, largely because they share a unified design philosophy for HTML5. The most instructive and important of these is:prioritizing the end user. This principle is essentiallya mechanism for resolving conflictsIn other words, when facing a problem and W3C and WHATWG propose different solutions, conflicts are resolved by placing the end user first, then the author, then the implementer, then the standards body, and lastly theoretical perfection. Theoretical perfection aims to create the most perfect format. The standards bodies are WHATWG and W3C, implementers are browser vendors, authors are developers, and users come first.
According to this order, developers rank above implementers and therefore carry more weight. This matters because it recognizes the user’s power: whether designing a format or software, this principle guarantees the user a voice. It also reflects the true operating order of things:users have more power than authors; authors have more power than implementers; implementers have more power than standards bodies.By contrast, other specifications like XHTML2 took the opposite approach, placing theoretical perfection first and users last, which requires strict error handling and creates various problems. This is a fundamentally different mindset.
Openness and user-first are foundational principles that everyone — whether designing a format or software — should follow.
Web VS Native
This section discusses the debate between Native Apps and Web Apps in the mobile internet era.
Advantages of Native Apps:
Native controls deliver better experiences, such as push notifications and offline use on weak networks;
Native offers better gesture recognition;
Native has a more suitable threading model. Although Web Worker can solve part of this, tasks like image decoding and text rendering still cannot be multi-threaded in many cases, which impacts Web smoothness.
Native can achieve richer, more nuanced animations; ultimately, at present Native offers superior human-computer interaction.
Advantages of Web Apps:
Search engine entry points. If a product is content-driven, much traffic may come from search engines, which is one reason mobile web can receive more visits.
Instant updates. For native apps, each version update involves review, listing, and user updates, creating delays. Users may not update and continue using an old version, missing new features. If a shipped version has issues, many users might be lost, whereas mobile web allows quicker remediation. Therefore, standards for shipping native apps tend to be higher.
Design and development costs. Native apps require design and development for different platforms with different guidelines and languages; mobile web requires far less work in this regard.
In summary, the Web’s advantage is reaching more users, while Native provides better user experience and stronger retention.
In practice, mobile Web can reach three times as many users as apps, but user retention on the Web is much lower. Native app users spend 18 times more time per month than mobile web users.
For Native Apps, their biggest weakness is exactly what makes Web Apps strong: their closed nature prevents content from being indexed, which creates downstream problems. For example, a user seeking a recipe for braised pork would first need to know the app’s name, download the app, and then access the content — an unreasonable flow. As mobile internet evolved, enthusiasm for downloading apps waned, and since 80% of user time is spent in the top three super apps, products must consider whether they can become a top-three app or remain in the long tail competing for the remaining minutes. Distribution costs for apps have thus risen.
Mobile’s development mirrored the PC’s history: it began as Native’s domain. But browsers’ ambition to supplant operating systems never faded. Compared with native apps, the Web offers many benefits: no need to develop multiple platform versions, no installation, no manual upgrades, no review processes… andthe biggest benefit and the main driver of shifting software form factors is cost reduction.
Way forward & current status
Accordingly, many tech companies have tried various approaches, which can be summarized into two paths.
One path isto integrate the natives. Current hybrid approaches, React Native, Weex, etc., can be seen as attempts for Web Apps to approach Native in performance. A key milestone was Facebook open-sourcing React Native at F8 on March 26, 2015. It offers Native-level user experience while retaining React’s development efficiency. This idea addresses an industry pain point: although native development costs are higher, Native remains necessary because Web’s user experience still can’t surpass Native. There are drawbacks, such as heavy dependency on Facebook, which introduces policy risks, among others.
P.S. React’s victory was primarily ideological. Compiler construction is becoming easier; the cost of building translators between languages is falling. In the future, JavaScript (ES5) may become an intermediate language on top of which languages like Reason, TypeScript, ES6, Java, and Objective-C can be compiled. While JS may not dominate everything, compilers reduce cross-language costs.
The other path isembracing the web. Examples include mini-programs (easy to migrate from the Web) and PWA. Compared to the closed nature of Native Apps, PWAs are completely open — all PWA technologies follow W3C standards and are fully open, making them easy for sites to adopt and for browsers to support quickly.
2015 – PWA
Unwilling to accept early setbacks, the Web needed a key to unlock its shackles — Progressive Web Apps (PWA) and a set of supporting technologies emerged. Service Worker is a critical technology among them. W3C published drafts for Service Worker as early as 2014, but production support in Chrome arrived in 2015. If we take the appearance of Service Worker as the birth of PWA, then PWA effectively began in 2015.
PWA does not refer to a single technology; it is a Web App that applies multiple technologies.Its core technologies include App Manifest, Service Worker, Web Push, Credential Management API, and others.Its core goal is to improve Web App performance and enhance Web App user experience.
It provides strong solutions for both user experience and retention. PWA can combine the strengths of Web and App: progressive enhancement, responsiveness, offline capability, app-like interactions, instant updates, security, searchability, push notifications, installability, and deep linking.
Notably, the App Manifest enables websites to be added to the phone’s home screen, addressing the long path users must take to reach a site; Service Worker enables websites to function offline and, together with Web Push, allows users to receive site messages while offline — both worth close attention.
When PWA was introduced it quickly gained support from many large sites. For example, Flipkart, India’s largest e-commerce site and a Tencent strategic investment, was an early large-scale adopter of PWA and saw very positive results: user session time tripled.
The future belongs to the web
Native carries an inherently closed gene, a stubborn and irreversible characteristic.
There are many constraints on Web Apps, but we can see thatWeb Apps have been steadily fixing defects and overcoming limitations. Web pages now access system features via Geolocation API, Camera API, and so on. You might say web pages lack app icons — Safari long supported adding website shortcuts to the home screen. You might say web pages require network access — there are many offline solutions now. You might say Web App performance is poor — that’s a fair point and explains why Native remains mainstream for a while, but what if Web App performance gradually catches up with Native?
Even if the future isn’t entirely the web’s, it will belong to an open, user-first, cost-reducing technological form.
Last updated