Five minutes to learn about the history of Internet Web technology

Author: Charryhuang, Tencent CSIG front-end development engineer

Source: Tencent Technology Engineering

In August 1991, the first static page was created, published by Tim Berners-Lee, to tell people what the World Wide Web is. From static pages to Ajax technology, from Server Side To React Server Components, the wheels of history roll forward, one technology after another, and silence.

preface

Our journey began in 1994 when the World Wide Web Consortium was established and hypertext markup language (HTML, Hyper Text Markup Language) was officially established as the standard language for web pages.

This article will follow the timeline, from the "discovery of problems - solve problems" perspective, to lead you to understand the key course of the development of Web technology, to understand the birth of typical technology and the causes of technological change, thinking about the reasons for technological development.

Tim Berners-Lee

Tim Berners-Lee, a British scientist and father of the World Wide Web, formally conceived the World Wide Web in 1989 at the European Organization for Nuclear Research (CERN). The network was originally designed and developed to meet the need for automated information sharing among scientists at universities and research institutes around the world, which is why HTML's top-level declaration is document, and the label name, and the name of the document object model.

In December 1990, he developed the world's first web browser. On 30 April 1993, CERN placed the World Wide Web software in the public domain and extended the World Wide Web to the world, enabling the rapid development of World Wide Web technology and profoundly changing the face of human life.

He created hypertext markup language (HTML) and created the first website in history. Of course, only a copy of the site recovered by CERN remains: info.cern.ch.

The age of static web pages

Early static pages had only the most basic single-column layout, and HTML supported tags , < p>, . Later, in order to enrich the content of the web page, < img >, < table > tags were born.

At this stage, the Web server is basically just a static resource server, and whenever a client browser sends an access request, it does not refuse to establish a connection, find the static page to which the URL points, and then return it to the client.

With the rapid development of web pages, people find it very difficult and time-consuming to manually implement all the information.

Imagine that if a page has two areas where the content presented is independent of each other, then you need to cover all possible possibilities, and the number of pages that need to be written is a product of the number of content in two areas!

In addition, static sites can only return pointing pages based on a user's request, and there is no way to do any interaction other than hyperlink jumps.

At this point, people want it

• Web pages can be displayed dynamically
• Use the data in the database directly
• Web pages implement some user interaction
• Make the page more beautiful

The birth of JavaScript

In 1994, Netscape released the Navigator browser, but they urgently needed a web scripting language so that they could interact with the web page.

In 1995, Netscape's Brendan Eich, under pressure from the company, spent just ten days designing the original version of JS, named Mocha. N etscape later changed its name to JavaScript in order to keep Java hot. But the reality is that Netscape and Sun formed an alliance to change their name to JavaScript.

From this page there are some simple user interactions, such as form validation, and some JS-based dynamics, such as walking lights.

But what really got the page into the dynamic web age is back-end web technology represented by PHP.

Extensions: The first browser war

When Netscape launched JavaScript, Microsoft wrote JScript and VBScript as browser languages based on JS, and IE 1.0 was launched in August 1995.

Because Microsoft bundles browsers in the system and 90% of people use the Windows operating system, a large number of users passively choose IE. Faced with Microsoft's rapid capture of browser share, Netscape was helpless to quickly submit JavaScript to ECMA, which was developed.

During this time, there was also an anecdote that Netscape employees on the day of IE 4.0's release noticed a large IE icon on the company's lawn, which was clearly a provocative move. I n response, Netscape placed his mascot, Mozilla, on the icon of IE and hung a badge that read "Netscape 72, Microsoft 18" - at the time, IE's market share was really not as good as Netscape Navigator's.

But that didn't solve the problem, and Netscape ultimately lost its first browser battle, being bought by AOL for $4.2 billion in 1998.

Before Netscape was acquired in 1998, Netscape disclosed the Navigator source code in an attempt to regain market share through the involvement of a wide range of programmers. N avigator changed its name to Mozilla. This is also the origin of Firefox, but also the second browser war pen.

CSS

In 1994, Hkon Wium Lie first came up with the idea for CSS. In December 1996, W3C introduced the first version of the CSS specification.

Beauty is the pursuit of all. S ince html was born, web pages have been basically a crude, rich text container. D ue to the lack of layout and beautification, early pages were popular with table tags. To solve the problem of "ugly" web pages, Hkon Wium Lie and Bert Bos co-drafted the CSS proposal, and W3C was interested in it.

The appearance of early pages

There were several versions of CSS in the early days, and you could even use logical expressions in the PSL96 version. But because it's too easy to expand, browser vendors are so many that it becomes difficult to unify and eventually be abandoned.

Among the many proposals, the CHSS (Cascading HTML Style Sheets) of Håkon W Lie first proposed the concept of style sheets being superimposed.

The percentage at the end of the line represents the weight of the style, and the final value is ultimately calculated based on the weight. The figure will calculate 30pt x 40% x 20pt x 60% as the final value of the h2 font size.

To address CSS compatibility issues, Netscape even wrote CSS with JS.

CSS has been associated with a large number of bugs since its inception, and different browsers have behaved differently, killing countless programmers. Today we can use a relatively reliable css, I have to say it is a miracle.

Dynamic web technology

In 1995, the PHP created by Rasmus Lerdof became active on major websites, making the web accessible to databases, and PHP enabled the dynamic web pages that people crave.

The dynamic page here does not refer to the dynamic effect of the page, but refers to the dynamic display of the content, rich user interaction. PHP is like opening a window into the online world, dynamic web technologies (such as ASPs, JSPs) are springing up, the World Wide Web is starting to develop at a high speed, and MVC mode is beginning to appear in back-end web technology.

Dynamic web technology solves all sorts of breathless pains before, and life is always getting better and better:

• You can use a database as a basis for presenting web content
• Forms and some simple interactions can be implemented
• You don't have to write a bunch of static pages anymore

PhP and other dynamic web technology principles, in general, according to the request of the client, from the database to obtain the corresponding data, and then stuffed into the web page, returned to the client a filled content of the page. This stage is also front-end coupling.

Web development process

And when some basic needs are met, the shortcomings of dynamic web technology are gradually exposed:

• Web pages are always refreshed. Username password verification needs to be refreshed to show error prompts, content displayed because of different drop-down selector selections needs to be refreshed to be displayed, and each data interaction is bound to refresh the page.
• Web pages are mixed with back-end logic. I believe the old front ends have had this experience: after developing HTML, will send the page to the back end to modify, coupled with data injection logic;
• There is a large amount of duplicate code that cannot be reused. T o give a typical example, the Forum. A lot of times only the content has changed, menus, sidebars, etc. will hardly change, but each time you request, you have to transfer the entire page again. Not only will the pages be refreshed, slow, but they'll also consume traffic (the Internet is also a luxury in this day and age).

Then AJAX came forward.

AJAX

AJAX, Async JavaScript and XML, was initially used in 1998 and became popular in 2005. T he widespread use of AJAX marks the beginning of the web 2.0 era. T his is also the era of major browser competition.

Now we can get data dynamically through AJAX and dynamically update web content with DOM operations. Take a look at how pages that join AJAX work:

At this time the front-end routing has not yet emerged, and in most cases the back end returns an entire page, some of which is obtained through AJAX.

With the advent of smartphones, apps are sprouting. App requires only a data interface to work when written, compared to a Web page, which requires not only back-end writing business logic, control jumps, but also a portion of the interface for AJAX requests.

There are still very few things that can be done at this stage, and there is a nickname for "Chetu." With the introduction of the HTML5 draft, the front end can do more and more interaction, programmers urgently need to solve the following problems:

• Back-end business code mixes with data interfaces, as well as APP-compatible interfaces (many enterprises have both APPS and Web sites)
• The code complexity of the front end has increased dramatically

Can you make the front end look like an APP and just request a data interface to present content?

Extensions: The Second Browser War

Firefox was released in 2004, kicking off the second browser war. In the same period, a variety of emerging browsers, such as Safari, Chrome, etc., also joined the war.

Microsoft even disbanded most of the browser's employees, leaving only a few symbolically to maintain a bug patch because the XP system was so hot that IE 6 had no competitors. This is very painful for developers.

At this point Firefox, with superior performance over IE and very friendly programming tools, quickly rescued web developers who had been messed up by IE6, leading to front-end engineers becoming loyal first users and then spreading them to the general user base through these experienced developers.

Webkit kernel-based Safari quickly harvests mobile and mac market share with the monopoly of its own products (iOS, MacOS), and Chrome, also based on the webkit kernel, takes advantage of Microsoft's ease of guard and quickly expands its market share with the same performance as Genghis Khan in China's history.

Microsoft knows that it has lost the opportunity to dominate in the first place, this time it does not want to lose, IE began to iterate again, the major browser vendors began to ignore the standards, the iteration began again, in order to unify the standards, W3C developed HTML5, but has been slow to get Microsoft's approval. After other browsers backed HTML5, Microsoft found itself alone again, and its share was shrinking.

In 2016, Chrome surpassed IE in the share of browsers, ending the second browser war.

The browser wars have greatly driven technological advances, and it is Google's V8 engine that has greatly improved the efficiency of JS's operations that gives NodeJS a chance to be born and the front end to the full stack. JS isn't as slow as you think.

SPA

The 2008 draft HTML5 proposes that browsers compete for HTML5 capabilities. Because HTML5 brings increased front-end code complexity, the front end had to refer to back-end MVC for design and splitting in search of good maintainability and reusability, and three front-end frameworks emerged: Vue (2014), (2010), and AngularJS (2009).

The single-page app returns a blank HTML and dynamically generates content through JS scripts, from which to refresh the page.

The backend is no longer responsible for template rendering, the front end and app are starting to peer, and the back-end API can be generalized. T he front and rear ends are finally separated. (PS: The ultimate goal is to be a backend)

But spa because it returns empty HTML, all JS is packaged as a file, and all resources need to be loaded at the beginning.

• The white screen takes longer to request a page than a traditional page
• The reptile crawls to a blank page and can't do SEO
• In complex business situations, the request file is large and rendering is very slow.

This forced the front end to split overly large single-page applications, with the emergence of a multi-page concept of the framework and a variety of solutions.

Many pages don't really need much when they load for the first time, such as forum home pages and post details pages, which can be completely unwrapped, and users can read new pages and experience better (multi-page apps).

Another example is the management background, which can be removed from the page frame and dynamically loaded (import) for each menu.

Server Side Render

Server Side Render, service-side rendering, or SSR for short, isomorphic, out-of-the-way, generally implemented using NodeJS.

The service side rendering here is not the same as before, SSR will use the first screen data that has been "dehydrated" to render the first screen page back to the client, to the browser re-inject browser events, and retain the ability of single-page applications, very SEO-friendly. However, the cost of learning is high, more restrictions.

Let's look at the difference between a traditional SPA and a SPA that joins the SSR:

The client renders the gesture

The service side renders the gesture

Traditional SPAs return to pages faster, request response times are shorter, JS is loaded before rendering begins, white screens take longer, and users perceive relatively interactive time earlier after loading ends.

When SSR receives a browser request, the first screen data rendering from the back end is returned within the page, and the request response time is longer; D ue to the asynchronous loading of JS, the user perceives a relatively late interaction time. But SSRs are generally better in experience.

In extreme cases, traditional SPAs are always displayed in the user's eyes, and pages that use SSRs are "pointless."

Most of the time the SSR experience is better because the service side does most of the rendering work, which also results in a higher load on the service side. However, in complex business situations, SSR first-screen requests have a large number of interfaces, resulting in slower html returns.

At the end of the day, SSRs don't handle business complexities well, and there's still too much to load on the first screen. So how do we make the white screen time that users perceive shorter?

• Reduce the load volume
• Reduce the number of interface requests
• PWA cache
• Block rendering
• ...

IMWEB's Penguin Coaching landed on the SSR-PWA and reached a level of almost seconds open.

NodeJS

When you're done with SSRs, you have to say NodeJS. N ow, 11 years after NodeJS was officially launched in 2010, NodeJS was inspired by Ryan Dahl (below). He wants to do everything in a non-blocking way, handling a very large number of requests (high concurring) in a completely asynchronous way.

The emergence of NodeJS is a significant step forward for the front end toward the whole stack. A lot of companies started doing BFF with NodeJS, and we started putting the Controller layer into NodeJS, where the back end was only responsible for the underlying business data. This is the current three-tier architecture:

This architecture is well adapted across ends, allowing us to design different Controllers and Views for different ends based on our business needs, without changing them in the background. This architecture eliminates a lot of communication costs, with the front end focusing on page presentation and the back end focusing on business logic.

Of course, NodeJS can also pre-process back-end data, the front end designs its own data structure according to its own needs, and the page development and interface debugging form a closed loop, which also shares the pressure on the back end.

Extensions: The third browser war

With the rapid development of smartphones, this picture shows the most vividly. The third browser war is the battle for mobile market share, but also the current war.

Benedict Evans: “Mobile is eating the world.” ( Mobile devices are eating into the world) "Mobile remakes the Internet." (Mobile devices are refactoring the Internet)

In the future, browsers will no longer be the real rivals of browsers, but small programs that combine the benefits of apps and web pages.

future

Back in 2009, Facebook engineers developed bigPipe, which tripled the speed at which Facebook pages opened. B igPipe uses the idea of block rendering to turn the rendering of a Web page into a small piece, and the server renders a page and sends it to the client. They took the cask straight away, breaking the short board effect.

Service-side rendering VS streaming block rendering

Eleven years later, in December 2020, the React team presented React Server Components as a scalable front-end convergence solution. T he concept is similar to bigPipe, with components rendered on the service side, saving money on data requests from the browser, and some runtimes that can be used without being placed in the browser, reducing the package size (for example, markdown renders on the server side, eliminating the need to send the tool library to the browser). The introduction of React Server Components also synchronously enables automated Code Split.

React Server Components principle

The difference is that React Server Components returns not HTML, but custom class JSON data with structure and data.

This structure, which abstracts the core of service-side rendering (structure plus data), combines react with how it works, such as Suspense, smoothly transitions from the server side to the client, maintains component state, and allows for freer assembly of server and client components.

A mix of client-side and service-side components

About splitting this idea, let me think of the micro front end, although there are still many problems in the micro front end, but micro-application as a service is also a solution. In the future, the front end may move in the direction of "small and beautiful", or even form a package manager in service-side components, web packaging size will be smaller and smaller, more components are obtained directly from the network.

In addition, I am also looking forward to the development of Web Components, with native support, 0kb runtime is not impossible. L ong time must be divided, many existing front-end frameworks can also be unified. Now, of course, Web Components wants to go live without browser support, and must have a smooth transition, and compatibility is a big problem (and finally, it's the programmers).

epilogue

From the birth of JavaScript all the way, from the "discover problem-solve" point of view, we see the causes and inevitability of technological development. 2 021 - Web APP is still some distance from the native APP experience. Perhaps a small program desktop APP will appear in the future, the small program can be unified, perhaps on the road to PWA further and further, or the browser open more native system APIs, using a variety of loading methods, and then simulate the various experiences of the APP, to achieve the effect of app app.

Every era has been born a lot of technology, big waves of sand, but left only exist in this era of the king. T echnology is always changing, it is important not to panic to catch up with the pace of technology, but to think about why technology has evolved so much, thinking about the pros and cons of such an evolution. If it were you, how would you solve the problem of contemporary technology?

Want to system self-taught front-end development recommended collection "W3Cschool front-end development learning route"