From the Web to the Future
Published: 2018-05-30
This article is an edited version of a speech I gave during a departmental presentation at my company.
The article follows a timeline, beginning with the history of the most familiar form of internet technology we use (the browser). By reconstructing key milestones and learning from history, it summarizes instructive principles from the evolution to guide our view of future technology trends.
Birth of the Web
In March 1989, while working at the European Organization for Nuclear Research (CERN),Tim Berners-Leewrote down hisinitial concept of the World Wide Web (Web).He proposed the idea of the Web as a global hyperlinked information-sharing space — an abstract (hypothetical) information space that serves as an application architecture on top of the Internet.The Web's primary mission is to provide people with information and information services.From the start it was open to everyone, welcoming contributions and participation. People could create and share content on the Web; anyone could distribute, access, and use information.
Technically, the Web architecture has three core elements:
Using hypertext technology (HTML) to link information to information;
Using Uniform Resource Identifiers (URI) to precisely locate information globally;
Using a new application-layer protocol (HTTP) to enable distributed information sharing.
Each of these features directly relates to the distribution, retrieval, and use of information.
Since the Web is an abstract hypothetical space, a tool was naturally needed to access it. 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 read 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 into the public sphere, the functions carried by pages expanded beyond academia and became richer, exposing the limitations of early web pages.
All pages were based on HTML documents.Because there was no way to control the display or hiding of local content, any local change — even a single added punctuation mark — required downloading an entirely new page.
Computations could only be performed on the server side.Due to slow network speeds, communication with the server was very slow and synchronous/blocking. This led to scenarios like form validation: a user submits a form, the whole page disappears and the browser shows a blank screen; after a long wait the browser renders a page identical to the previous one, except for a line of red text next to the input field: "username incorrect."
All pages were static.This meant that if an e-commerce site had a thousand products, even with identical layouts it required writing a thousand separate pages.
P.S. In 1994 PHP implemented database interactions and template engines for producing dynamic pages, becoming the most mainstream server-side language in the Web field. In 1995 Netscape introduced JavaScript, enabling client-side computation (such as form validation). In 1999 Microsoft introduced ActiveX for asynchronous data transfer, which led to the later key technology for web pages to become web applications: Ajax. Ajax gained massive attention after Google used it to build Gmail (2004) and Google Maps (2005), signaling the arrival of Web 2.0. (Web 1.0: static pages, content display only. Web 2.0: dynamic pages, rich interaction, front-end data processing.) In 2006, XMLHttpRequest was officially standardized by the W3C.
By then, early documents had finally evolved into web pages, and the three limitations mentioned above were properly addressed.
The remarkable 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 same year, Tim Berners-Lee founded the W3C; today,various web-related technical standards are managed and maintained by the renowned World Wide Web Consortium (W3C)..
That year Tim’s close colleague released CSS. Also that year, the server-side scripting language PHP for dynamic web pages was introduced.
Here I mention an important company —Netscape, whose history mirrors the early development of the web.
Silicon Valley legend — Netscape
Beyond JavaScript, Netscape also catalyzed Java. Netscape Navigator defined other modern browser features such as cookies, HTML frames, automatic proxy detection, and more. Before 1995, Netscape was the standard-setter for browsers. With so many advanced features, Netscape Navigator was once the world's most popular browser and enjoyed tremendous success.
However, Netscape's life was short. Founded in 1994, it was acquired by AOL in November 1998 and dissolved in 2003. Its downfall was tied to two major disruptions: the Internet bubble and the browser wars.
The Internet bubble
The 2000 internet bubble can be traced back to Netscape’s IPO. The IPO’s unexpectedly strong performance greatly stimulated market investment enthusiasm. In August 1995,Netscape's stock surged as much as 154% intraday on Nasdaq and closed up 86%.Netscape’s dramatic stock performance ignited a venture capital boom in the late 1990s in the U.S. Most capital flowed to the internet industry. Popular stocks like Amazon and eBay rose many times over. Starting in January 2000, the once-favored internet stocks were suddenly sold off en masse, ultimately causing the collapse of the Nasdaq market.
The browser wars
NetNavigator opened the consumer browser market. As they were expanding, the dominant PC platform player Microsoft launched an aggressive assault on Netscape with Internet Explorer (IE), starting the “first browser war” (1995–1999). IE 1.0 was released in August 1995, and because it was bundled with Windows, IE decimated Netscape and reached about 90% market share. For ordinary users, the browser became that blue "e" on the desktop; for years Microsoft's IE was almost synonymous with "browser."
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 market 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 then stabilized around 60% by the end of 2007. IE was no longer the "only browser." Although Firefox significantly outperformed IE in many respects, Windows’ bundling advantage remained so strong that Firefox never fully caught up.
Until 2008 when Google launched Chrome. Its superior performance, clean interface, and integration with Google Search enabled it to quickly capture market share, eroding both Firefox’s share and the aging IE. By 2012 Chrome had the largest market share.
The mobile internet era
2007 — first generationiPhonereleased;
2008 — firstAndroidreleased;
2014 —the fifth-generation HTML standardreleased;
HTML5 was driven by browser vendors (Opera, Apple) in collaboration with the W3C as a comprehensive set of Web application specifications and continues to evolve with new drafts. Behind these specifications you can clearly sense the ambition of their leaders: to occupy every screen.
Google Chrome’s main rival was no longer other browsers but competitors beyond the browser —native applications (Native Apps)..
This led to the debate between Web Apps and Native Apps. Before that, it’s important to review HTML5’s history, because it reveals basic principles that shaped technology development choices.
Deriving technology principles from HTML5’s development
Openness
From HTML5’s development we learn: after HTML 2.0, later versions were developed and maintained by the W3C. From 1997 to 1999, HTML evolved quickly from 3.2 to 4.01. The problem was that by the time 4.01 arrived, the W3C’s priorities regressed; they did not stop developing the language, but they lost interest in HTML.They proposed the concept of XHTML,which required documents to be marked as XML. XML and HTML are both markup languages, but XML’s syntax is stricter (theoretically more correct) — for example attributes must be lowercase and values must be quoted.A critical flaw was XML’s error-handling model: if the parser encountered an error, it would stop parsing.As a result, any single error could cause the browser to fail, leaving users unable to see any web content.
This violated an important design principle, namely the well-knownRobustness Principle: be conservative in what you send, liberal in what you accept.Being liberal in what you accept is the very foundation that allowed the Web to be built. Browser developers must open their arms to accept anything sent to the browser, including content that is not perfectly standard or well-formed — this tolerance is the driving force of the Web. In a sense,the Web followed a chaotic path of development; though chaotic, it was remarkably attractive.As professionals, we should be conservative when sending documents, follow best practices, and ensure well-formed formats. From the browser’s perspective, however, they must accept any document with an open stance. An overly strict error-handling model contradicts the principle of being liberal in acceptance and conflicts with the Robustness Principle.
User-first
Due to these conceptual differences, in 2004 vendors led by Opera left the W3C to formWHATWG,returning to HTML development. Later the W3C and Berners-Lee recognized the directional mistake, abandoned the unrealistic XHTML standard, and returned to building HTML standards. Now both groups work in alignment, primarily because they share a unified design philosophy for HTML5. The most instructive and important principle is:end users come first.This principle is essentiallya conflict-resolution mechanism.
In other words, when facing a problem and W3C and WHATWG propose different solutions, conflicts are resolved with users first, then authors, then implementers, and lastly the standards bodies and theoretical perfection. The latter refers to creating the most perfect format. Standards bodies are WHATWG and W3C; implementers are browser vendors; authors are developers; users have the highest priority.Accordingly, developers rank above implementers in the chain and carry greater weight. This is crucial because it recognizes user agency: whether designing a format or software, this principle ensures users have a voice. It also reveals how things actually operate: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 followed a completely opposite approach, prioritizing theoretical perfection and placing users at the bottom of the chain, requiring strict error handling and creating various practical problems. This is a fundamentally different mindset.
Openness and user-first are foundational principles that everyone should follow, whether designing a format or building software.
Web vs. Native
This section discusses the competition between Native Apps and Web Apps in the mobile internet era.
Advantages of Native Apps:
Native controls provide a better experience, such as push notifications and offline use in poor networks;
Native offers better gesture recognition;
Native has a more suitable threading model. Although Web Workers can solve some problems, tasks like image decoding and text rendering still cannot be multi-threaded, which affects the smoothness of the Web.
Native can achieve richer, more refined animations; fundamentally, Native currently delivers a better human-computer interaction experience.
Advantages of Web Apps:
Search engine entry points. If a product is content-driven, much traffic may come from search engines, which may be one reason mobile web receives more visits.
Instant updates. For native apps, each version update involves review, publishing, and user update delays. Users may not update and continue using an old version, missing new features. If a shipped version has issues, many users may be lost without quick remediation. Mobile web, however, allows faster fixes. Thus shipping standards for native apps tend to be higher.
Design and development cost. Native apps require design and development for different platforms with different standards and languages; mobile web requires much less work in this regard.
In summary, the Web’s advantage is reaching more users, while Native offers superior user experience and stronger retention.
In practice, mobile web can reach three times as many users as an app, but user retention time on the web is significantly lower than on apps. Native app users spend 18 times more time per month than mobile web users.
For Native Apps, their biggest pain point is precisely the Web App’s strengths: their inherently closed nature prevents content from being indexed, and this limitation is hard to overcome. This creates downstream problems. For example, a user wanting a braised pork recipe must first know the app’s name, download the app, and then access the content — a very inefficient flow. As mobile internet matured, users’ enthusiasm for downloading apps waned. With 80% of users’ time dominated by the top three super apps, products must consider whether they have potential to enter the top three or remain in the long tail competing for the remaining minutes. Distribution costs for apps therefore rose rapidly.Mobile’s development closely mirrors the PC era: initially dominated by Native. But browsers’ ambition to supplant operating systems never faded. Compared to native apps, the Web has many advantages: no need to build multiple platform versions, no installation, no manual upgrades, no review process… and.
the biggest advantage and the main driver for shifting software models is cost reduction.
Paths & current status
Accordingly, many tech companies resorted to various strategies, which can be summarized into two paths.One path isto unify native platforms.
P.S. Current approaches like hybrid frameworks, React Native, and Weex can be seen as attempts by Web Apps to approach Native in performance. A key milestone was Facebook open-sourcing React Native at the F8 conference on March 26, 2015. It aimed to deliver native-like user experience while retaining React’s development efficiency. This idea addressed a common industry pain point: although Native development costs more, Native remains necessary because the Web’s user experience still lags. There are drawbacks, such as heavy reliance on Facebook and associated policy risks.
React was effectively a conceptual victory. Compiler creation is becoming easier; the cost of translators between languages is dropping. In the future, JavaScript (ES5) might become an intermediate language on which languages like Reason, TypeScript, ES6, Java, and Objective-C can be transpiled. While JS may not dominate everything, translators reduce cross-language costs.The other path isto embrace the Web.
Examples include mini programs (which are easy to migrate from the Web) and Progressive Web Apps (PWA). Compared to the closed nature of native apps, PWAs are fully open — all PWA technologies follow W3C standards and are therefore open, allowing rapid adoption by sites and quick support from browsers.
2015 – PWA
Unwilling to concede early losses, the Web sought a key to break its chains: Progressive Web Apps (PWA) and a set of supporting technologies emerged. Service Worker is a critical technology. The W3C published Service Worker drafts in 2014, but Chrome supported it in production in 2015. If we mark the arrival of PWA by the appearance of Service Worker, then that point is 2015.PWA does not refer to a single technology but to a Web App that applies multiple technologies.Its core technologies include App Manifest, Service Worker, Web Push, Credential Management API, and more.
Its core goal is to improve Web App performance and user experience.
It offers strong solutions for both user experience and retention. PWA can combine the strengths of Web and App: progressive, responsive, offline-capable, app-like interactions, instant updates, secure, searchable by search engines, push-capable, installable, and linkable.
App Manifest allows websites to be added to the home screen, addressing the long path users must take to reach a site; Service Worker enables web sites to function offline and supports Web Push for delivering messages to users while offline — both are highly noteworthy.
When PWAs were first introduced, many major sites adopted them. For example, Flipkart, India’s largest e-commerce site which received strategic investment from Tencent, was among the first large-scale adopters of PWA and saw excellent results, with user session length tripling.
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 continuously fixing flaws and breaking limitations.
Web pages can call system features: Geolocation API, Camera API… You say pages don’t have icons like apps — Safari has long supported adding web links to the home screen; you say pages must be online — there are many offline solutions now; you say Web Apps perform poorly — true, which is why Native will remain mainstream for some time. But what if Web performance gradually catches up to Native?
Last updated