Clever Geek Handbook

The engine that could: how Chromium managed to capture 90% of the browser market



From the browser engine that was initially a little-known alternative used in an unpopular browser, to the champion that took over the entire market.



Probably, sometimes you come across the concept of browser diversity in texts.... It refers to the equilibrium on the web platform in which there are many browser implementations in the world, sufficient to stimulate innovation and competition between them. The alternative is browser monoculture, in which one browser or browser implementation controls the entire market, and therefore drives the development of the web. When someone promotes browser diversity, they often do so for the sake of a process of creating independent web standards maintained by the W3C, which only works when no browser can dictate the features that are included in the web platform.



The web community has enough reason to fear the lack of browser diversity. After Internet Explorer captured 90% of the browser market in the early 2000s, it took its developers a good half decade to release a new browser. During this period, the development of the web stopped and security problems began to arise. This has made the web worse, so we often want browsers to compete rather than monopolize the web.



But this problem also has a downside. Because of the existence of multiple browser makers, web developers need to ensure that all platforms are compatible. There can be minor inconsistencies between browsers, which can complicate development for the web.



This worried web creator Tim Berners-Lee. Even in the early 90s, when the web was very young, dozens of browsers began to appear around the world as software developers experimented. Berners-Lee worried that too many browsers would make it harder to test sites and reach consensus on how to parse and deliver HTML to users.



In 1992, Tim Berners-Lee voiced his concerns on the hypertext mailing list.



8 12 , . (, , ! , , (, ), . , ; , , , .


Berners-Lee recognized that multiple implementations can take too much effort on the part of the web developer, so developers might be tempted to avoid this problem entirely and only test in the most popular browser (he had no idea that a similar problem would occur frequently on the web.) -development ). That is, even without a monopoly, too many browsers can flood the market and create an actual winner against which standards will be created without taking into account all the others. Ensuring the consistency of all browser implementations was the reason for the creation of the W3C and the promotion of a set of common standards in web technologies.



Berners-Lee's concern was well founded. There have been times when browsers have gone their own way, forcing web designers to tinker with pages to make pages look the same everywhere. In recent years, a well-established standardization process has largely resolved the problem of inconsistencies between browsers by creating a clear process for adding new features to the web, ensuring balance in the decision-making process.



The fundamental basis for creating a diverse group of browsers is the development of completely different browser engines. The browser engine is the code inside the browser that takes the code you write and renders it on the page. On a more technical level, it parses HTML, CSS and JavaScript to handle the structure and rendering of web pages.... The engine usually includes a JavaScript engine that handles interactivity. Most often, when discussing a browser engine, they talk about the associated JavaScript engine, but this is not always the case.



Before browser makers started using web standards, during the "browser wars," there was a decade of dominance over Microsoft's Internet Explorer browser. Internet Explorer used a proprietary Microsoft browser engine called Trident. Internet Explorer was distributed free of charge and was installed by default on all Windows computers. Due to its speed of distribution, Trident has become the most widely used browser engine for many years.



However, several smaller open source browsers soon began to gain popularity. The most popular of these was Mozilla Firefox (based on Netscape), which used an engine called Gecko. Opera lagged slightly behind it with its Presto browser engine. A small community fell in love with Konqueror's KHTML browser, which had a tiny share of the browser market.



The source code of all of these browser engines, with the exception of Presto, was open source, meaning it was available to anyone and could be used in any project. This stimulated collaboration and healthy competition between these new browsers, which favored the W3C-led web standards process. And thanks to open source, a large number of small, niche browsers have appeared on the market, built on the basis of the same browser engines.



Apple's absence from this list is noteworthy. In 2003, it seemed like the company had completely overlooked the web platform. She tried unsuccessfully to create her own browser called Cyberdog. Without a browser native to their OS, Apple computers came with Internet Explorer, which tied them to one of their most serious competitors - Microsoft.



But then rumors began to circulate that Apple was working on a new browser. Several veterans from Mozilla joined the company, contributing on behalf of Apple to the open source Mac version of Firefox. And after the first experiment that failed, the tools and implementations are much better. There were already many mature open source solutions.



Initially, it was assumed that Apple would choose Mozilla Gecko as its browser engine. She already had the right people and experience with it, and the engine was used in the vast majority of browser projects, including a Mac browser called Camino, developed by an independent non-Apple team. Some believed that Apple could choose Presto through some sort of licensing agreement.



Steve Jobs concluded his keynote speech at Macworld 2003 with a long-awaited announcement: Apple is creating its own browser called Safari. And to everyone's surprise, it will use the engine from Konqueror. Not Gecko, not Presto. KHTML. The news was big, and over the next two decades, it changed the trajectory of the web.





The Konqueror Browser Running on the KDE Desktop



The Konqueror browser is one of the many applications that are part of the KDE desktop environment for Linux computers. Strictly speaking, it is not an operating system, but a software package that looks and behaves like an OS. The acronym originally stood for Kool Desktop Environment, but then it was shortened simply to KDE. Konqueror is one of the programs inside KDE. And KHTML is the engine that Konqueror runs on. Like Linux itself, all of KDE is open source, including its browser, and the developer community has adhered to the principles of open source since its inception.



That is why it is important that Apple's announcement included this slide:





In its announcement of its choice of KHTML, Apple declared its commitment to open source ideas. The Safari development team has pledged to make the changes it makes to the KHTML project whenever possible. When adapting the engine, Apple broke it into two parts: WebCore, which deals with rendering and structure, and JavaScriptCore, which deals with JavaScript. Both of these parts became open source projects, but the Safari bug tracker and browser engine elements remained closed. Yet this level of transparency was surprising for a company well known for keeping its secrets.



The first public version of Safari was released at the same time as the announcement, in January 2003. Shortly thereafter, Safari began shipping as the default browser for all Macs. For one to two years, Safari has consistently occupied two to three percent of the browser market. It wasn't enough to dominate, but it gave weight to the Apple development team.



Despite the promise made to the open source community, the Safari developers initially found it difficult to port their changes back to the KTHML project. Some of the code was specific to the Mac operating system. Other parts were simply incompatible with the existing codebase. This led to a slight disagreement between the Apple team and the KHTML co-authors for a couple of years.



Over time, a compromise was found that suited everyone. In June 2005, Apple merged JavaScriptCore, Webcore and the rest of the browser engine, releasing them as a single open source project with a public bug tracker and a call to contribute. In this way, the company showed the KHTML community that it was ready to collaborate while maintaining code independence.



The project was named Webkit.



The moment was critical. The web as a platform developed rapidly and was at the Web 2.0 stage. Overall, Web 2.0 was just a nice marketing term, an attempt to give a name to the growing number of sophisticated applications that exist exclusively on the web. It includes Google's very first two web applications - Google Maps and Gmail. Google added YouTube to the list within a year.



In the mid-2000s, Google engineers took a closer look at browsers and found that they were unable to meet the need to build complex applications. This was especially true for older and unattended browsers like Internet Explorer (by the way, YouTube also had a hand in encouraging users to abandon IE6 ). But Google's top priority was speed. The co-founders of the company once expressed their desire to create "the web as fast as flipping through a paper magazine." That was the company's goal, and Google felt that even modern browsers like Firefox and Safari weren't getting close enough.



By 2006, the company began making plans to build its own browser. She wanted the fastest browser on the market. After experimenting with a variety of browser engines, Google developers turned their attention to the Webkit project, which moved to open source. Its code was compact and readable, and its resource intensity remained relatively low compared to engines with a rich history like Gecko or Trident (the latter was not considered anyway due to its closed source code). But most importantly, he was fast. As a starting point, it was faster than all other engines.



If the Safari team hadn't decided to open the source of their browser engine at this time, the story could have developed in a completely different direction. But the developers did this, so Google looked into this possibility and decided to use the engine. Over the next couple of years, she started working on a new, even faster implementation of Webkit.



Her first step was getting rid of JavaScriptCore and replacing it with its own JavaScript engine called the V8, named after the powerful piston engine. As the name suggests, the V8 was fast. At the time of release, it turned out to be ten times more performant than JavaScriptCore. He achieved this speed by running in a virtual machine and a slightly different way of executing the code, making it modular and independent of the rest of the browser engine. By the way, after a couple of years, this modularity made it possible to create the Node programming language: its developers took the V8 engine, got rid of the browser and put it on the server.



The second thing Google has done is to add multi-process architecture to its browser. There is a lot to be said about multiprocessing, but it is best explained using browser tabs as an example. Previously, when one tab crashed, the entire browser crashed. However, Google was able to force the processes in each tab to run independently so that only one tab crashed at a time. After the release of the browser, this became its main attractive quality. It also turned out to be an important decision because it was a major departure from the way Webkit used to work. Soon, this decision will come back to haunt the company.



In September 2008, Google officially announced its browser project to the public. The company combined the ad with Scott McCloud's Nerd webcomic, which detailed all the technical details of the project. The browser could process websites the fastest on the market, and thanks to its multiprocessing architecture, it was able to keep pages active even when another site was frozen. This was back in the days when browsers were still overloaded with toolbars and addons, as well as packages from big companies that included mail. The name Google gave to this project was also in line with the concept. In the world of browsers, the term "chrome" (chrome) means everything additional that surrounds a web page - the address bar, toolbars and file menus. Google got rid of most of this junk, which is why it called the browser Google Chrome, hoping that the focus on simplicity and performance will pay off.





The Web Comic Fragment That Started It All



Apart from the closed search algorithm, Google has contributed to open source projects and created new ones for many years. Having understood Apple's lesson, the company went even further in developing Chrome. On the same day that Google Chrome was announced, the company made the entire engine available as an open-source project called Chromium. These are not just a few Webkit extensions. It's not just a rendering engine. Everything became open: Webkit, the V8 JavaScript engine and all the code of the browser itself. With little effort, any developer could complement Chromium and release their own browser. After its release, it happened to many browsers .



2008 was a big year for the web. In the same month that Chrome was released, Google showed a prototype of its Android mobile operating platform, assembled from several open source projects. It also included the mobile version of Google Chrome. This happened a little over a year after the official release of the iPhone, which came with a modified version of Safari. By the time Steve Jobs began killing Flash irrevocably and making the native web platform a top priority, these devices were already everywhere.



That is, now Safari or Chrome worked in every mobile smart device. Safari itself, entirely thanks to iPhone purchases, has doubled its market share in just a few years. Chrome's popularity grew even faster. By using Chromium, you have access to an ever-expanding list of independent browsers and browser projects. In addition, Chromium has become the backbone of the Node programming language and the Electron desktop application framework.



And all these projects worked thanks to Webkit. Over the years, he has gone from capturing a small share of the browser market to dominating it.



This state of rest was short-lived. In April 2013, Google unexpectedly announced that it would fork the Webkit project into a new engine called Blink. Google Chrome and the Chromium project will be moving to this new engine.



There were several reasons for this transition, but the most important one brings us back to the issue of multiprocessing. For several years Google has been extending Webkit to add multiprocessing to its browsers, which has become a critical feature and the basis for the performance growth of Chromium browsers. In 2013, the Webkit project was supposed to release a new version of the engine, which also improved multiprocessing. The problem was that its implementation would become completely different and incompatible with the implementation in Chrome. It already used a different JavaScript engine and this new change would have moved Chromium too far away from the original project. The core of Blink still had to and remains Webkit. But he will take a different path and create a new project for himself.



At this point, the web has become more complex than anyone imagined. The problem first posed by Berners-Lee — too many independent developers building their own browser engines — was no longer a problem. Large teams were now required to build and maintain the browser engine. With the expansion of the web platform and the strengthening of its standards, the complexity of rendering a website to a page has grown exponentially. The browser had to execute countless sites, coded in countless ways to more or less match all other browsers.



After that point, browser engines started to disappear.



Two months before the release of Blink, Opera announced that it would ditch its own Presto engine and move its browser to Chromium. When Google announced the fork, Opera joined it. In May 2013, she released her first Blink-based browser.



In the meantime, Microsoft has stuck with its own closed source engine for years. Trident has been converted to an engine called EdgeHTML built for the Microsoft Edge browser, first released in 2015. But investing in the development of an independent engine has proven too difficult in an already crowded browser market. In 2019, the company announced that it was also moving to Blink. Since then, this browser has also been released.



Descendants of KHTML, that is, browsers with engines from the Blink / Webkit family, are used by more than 90% of users. From practically oblivion to 90% market share in fifteen years, it's an amazing achievement. And it had consequences.



Blink and Webkit are two different engines, and there are quite a few differences in their source code. But they use the same approach to rendering web pages, and most of the code inside the project remains the same. This means that at the current stage, in fact, there are two groups of browser engines left - the Blink / Webkit family and the Firefox browser Gecko. Even if you separate Blink and Webkit, there are still only three left.



And that brings us back to the issue of browser diversity. Innovation in browser technology hasn't gone away, and fortunately, every serious browser is committed to the web standardization process. However, if the Blink and Webkit community decides they want to move the web in a certain direction, they have all the power they need to do so. This is true even today, despite the fact that Gecko is still holding on.



Jeffrey Zeldman summed it up well at the moment Microsoft decided to move to Blink:



When one company decides which ideas are worth supporting and which are not, which access issues are important and which are not, it stifles innovation, destroys competition and opens up opportunities to exclude people from working with digital information.


From a historical perspective, the development trajectory of Webkit is a miracle. And it came about thanks to the openness and support of the community. But it is just as important to maintain browser diversity and innovation.



This post covers five milestones in the history of the web.



  • April 3, 2013. Creating Blink as a fork of the Webkit project. The Blink rendering engine is used in Chromium-based browsers, including Google Chrome. The foundation of its codebase was laid by Webkit, but it handles multiprocessing tasks and contains the V8 JavaScript engine.
  • 2 2008 . Google Chrome, . , Google . , .
  • 7 2005 . Webkit — Apple , : WebCore JavaScript- JavaScriptCore. Apple, Google Webkit .
  • 7 2003 . Safari — Apple , . Mac Internet Explorer Microsoft. KHTML, Webkit.
  • 23 2000 . Konqueror — KDE Konqueror 2. KDE , Konqueror . , , Apple Safari Google Chrome.








Advertising



Our company offers secure servers with free DDoS protection . The ability to use a licensed Windows Server at plans with 2 GB of RAM or higher, creating server backups automatically or in one click.



We use extremely fast server drives from Intel and do not save on hardware - only branded equipment and some of the best data centers in Russia and the EU. Hurry up to check.





More articles:


All Articles