Browser wars 2020

As Google Chrome crushes all its browser competition, Neil Mohr takes an in-depth look at what makes it so good and why you shouldn’t be using it.

FEATURE

We suspect most APC readers remember with bitterness and rolling of eyes the Browser Wars of the year 2000 (OK, perhaps it’s more like 1995, but we like round numbers). Back when websites were websites, adorned with user-unfriendly “Compatible with Netscape” logos and “Under Construction” animated GIFs, that took an age to load over crawling 56K modems. Entire websites that only worked with a flashy plug-in, and Microsoft breaking standards left, right, and center to gain market share. Great days, if by great you mean awful.

You have to hand it to Microsoft – and, indeed, Bill Gates – who foresaw the dominant role the web browser would play in the future, and yet still manage to entirely throw away that marketdominating position to some plucky underdog called, of all things, Google.

Why does it even matter which web browser we choose? Why has the browser become so powerful? What makes a web browser tick, and is there really any difference between them? All of these questions and more will be answered as we dive inside the web browser, benchmark a bunch of them, and ask experts, “Should we be sticking with the browser shoved in front of us by globespanning corporations?” Hint: No.

We’re not about to take you back to 1993 and explain the history of the world wide web, aka Web 1.0. That’s done and dusted – thanks, Tim Berners-Lee. We’re jumping straight into the “today” to explore what makes a modern web browser tick, because the differences are vast. The important question to ask is why? What has changed so much over the last 27 years or so that makes modern browsers so complex?

To kick things off, and to perhaps whet your appetite, just considering the basic high-level functions of a web browser reveals a corresponding high level of complexity. Part of this is the network connectivity to fetch all the HTTP and associated protocols, before you can even consider displaying anything.

Even at this stage in the explanations, what we need to understand is that the world wide web is a precarious stack of standards, piled on top of each other, and transmitted over an international-scale network. If any corporation or nation state decides that it wants to interfere with them, things quickly begin to fall apart. Just take DDoS attacks, or certain countries rerouting all traffic by abusing Border Group Protocol hijacking. On a more relevant level, if a major browser provider wants to undermine open standards, it certainly can – and definitely has done.

Inside a browser

The basic overview of a browser hasn’t changed much since the first ones launched in the mid-1990s, the main additions being support for processing JavaScript and local data persistence. Check out the diagram below to see how a browser is built. • Networking. There’s a lot of fetching

A single browser always dominates the desktop landscape.

and carrying with a web browser. HTTP(S) is the core, but there’s FTP for file transfers, SMTP for basic email, and DNS to look up URLs and request pages from the web server. Not to mention TCP/IP connections and packet transfers.

• User Interface. You probably take it for granted, but the interactive decorations around the browser and additional features it may offer – such as bookmarks, history, password storage, and more – are all part of the interface.

• Browser engine. This is less obvious than the rest, and refers to the intersection between the user interface element and the rendering and Java engine, while also linking to the data storage element. For maximum confusion, some projects refer to the browser engine, while others talk about the rendering engine.

• Data storage. While this started with cookies, local data storage is far more important in modern browsers for use in local applications. Web Storage

provides basic local variables, but Web SQL offers full local database features, with an Index database being a compromise between the two.

• JavaScript engine. The programming language of the web, JavaScript enables interactive websites and dynamic content. While it’s designed to be interpreted, modern browsers use a Just In Time (JIT) compiler that runs the code on demand, to be as fast as possible. Each major browser uses its own engine, which can offer a performance differential.

• Rendering engine. The core block of any modern browser – we’ll take the majority of our time digging into how this works, which will involve another block diagram. Effectively, this is two parsers: one processing the HTML and Document Object Model (DOM) elements, and the other parsing the Cascading Style Sheet data. From this, a rendering tree is generated, laid out, and painted to the display.

Same but different

We’re going to largely ignore parts of this model, such as networking, the user interface, browser engine, and data storage. It’s not that they’re unimportant – that’s absolutely not the case – but they’re more openly duplicated between systems. Accessing the TCP/IP networking stack and requesting/ sending HTTP is donkey work done by standard libraries. Finesses of a user interface are better left for a critical review or group test. And while we’ll mention browser storage, we’re not going into any deep analysis of it.

This leaves us with the two main elements that dictate performance and compliance: the JavaScript engine and the rendering engine.

We’re going to focus on the rendering engine because it’s big and complex. But why all the fuss in the first place – isn’t HTML just HTML? As we alluded to, the web and online applications are built on standards; in the case of HTML, it’s the World Wide Web Consortium, aka W3C, that defines the guidelines on what each

An at-a-glance guide to the building blocks of browsers laid bare.

HTML tag should do.

The problem is, as with so many aspects of life, guidelines and rules are open to interpretation, and what one browser might do with a certain set of tags, another does not, and dumb humans do a whole other set of things, too. As the rendering engine is in charge of interpreting and displaying content, and as different browsers use different engines, that content can end up being displayed differently from browser to browser. Usually, this is minimal, but sometimes it can lead to positional changes or, at the extreme end, entire pages failing to display.

Oddly, many quirks of rendering are down to how engines handle error conditions, because this behavior is not standardized. HTML editors and humans can output all manner of crazy, noncompliant

code that the poor browser engine then has to parse and interpret as best as possible, as we’ll now examine.

Skinning cats

The network engine is doing its thing and fetching web page content, then passing it to the rendering engine. At this point, there are two main ways of handling the content. We’re going to look at how WebKit and Blink deal with the process, but be aware that Gecko, used by Firefox (and derivatives), approaches things in a slightly different order.

Both, however, split the website data into HTML and CSS data – these will be processed separately by their own parsers. What’s that, then? Roughly speaking, a parser takes in the incoming bitstream and translates the data into a node tree; the structure of that tree is

Why should you care about privacy? Well, Google, Amazon, and Facebook know everything about you – probably because you told them. Google, because it owns your life now; Amazon, because it owns your shopping habits; and Facebook, as it owns your social networks. The idea that you should use a Google-branded browser that helps you to log into your Google account before you browse anywhere should be ringing alarm bells. The same should go for a browser produced by the company that also developed your operating system. This sort of duality of function is begging for total surveillance.

In terms of privacy, Mozilla’s Firefox is hard to beat. Firefox, based on the Gecko engine, has been around in one form or another since 1998. Mozilla is an open-source organisation dedicated to protecting an open Internet and user privacy. So, with Firefox’s combination of cutting-edge performance, sweet suite of features, and mindfulness of privacy, you’d be foolish not to be using it as your daily driver.

There is a step beyond this, though: the Tor browser. It’s based on Firefox, but utilises the anonymizing Onion network to hide your browsing inside a bundle of encryption. The downside is that it’s slower and has various issues confusing web hosts. It’s also worth considering one of the feature browsers; as none is connected to a large corporation, they’re far more likely to take your privacy into consideration.

“The basic overview of a browser hasn’t changed much since the first ones launched in the mid-1990s, the main additions being support for processing JavaScript and local data persistence”

Browser benchmarks have been around for a good many years; you might remember SunSpider – released in 2007 and very much outdated now – which is still available. It’s been superseded by Mozilla Kraken in terms of providing a similar suite of tests, while JetStream, developed by Apple, is a dedicated JavaScript benchmark tool, with version 2.0 housing a Web Assembly benchmark; it’s in part based on the previous benchmark, Octane 2.0.

Both of these measure how quickly the JavaScript engine can manage a suite of basic tasks. By using a wide range of different types of loads, it protects the benchmark against engine optimisations. If you look into the tests, you generally find they’re math-heavy, compiling libraries, testing crypto libraries, ray tracing, and compression tests.

As you’d expect, the newer the browser, the faster the results, but due to the more recent Web Assembly elements of JetStream 2, this benchmark failed to complete on “older” browsers, but that even includes the EdgeHTML browser that stalled on the final test. We added Internet Explorer 11, as it’s still supported, and the Blink-based keyboardoriented Qute.

Browsing the web, 2005-style. Not fun.

defined by the syntax (rules) of the language (HTML or CSS). If you’re aware of basic HTML tags, it should make sense to say the parsing process is split into:

• A lexer. This breaks the input into known tokens (tags) based on the vocabulary rules.

• A parser. This constructs the document tree following the grammar rules. A token is requested from the lexer; if it matches a known rule, it’s added to the tree, else it’s stored and another token is requested. If no match is found for a stored token, an error is raised.

HTML is interesting in terms of languages. It has a loosely defined grammar, because it has to be backward compatible and fault tolerant, while it has to deal with dynamic code (via scripts) that can add tokens back in while it’s being parsed. This means its parser can’t use a systematic top-down or bottom-up approach to parsing. In the language world, people say it’s not a context-free grammar – we might call it other things, given half a chance.

To give you a taste of what a web parser has to deal with, let’s quickly look at a very rough day-in-the-life of an HTML lexer. It starts in its default “data state” mode, when a < is encountered that switches to “tag open state” mode. Characters a–z encountered next create a “start tag” token and a “tag name state.” This continues until a closing > is hit and “data state” mode is back. If a / is encountered after a < then an “end tag token” is created until the > is hit.

These tokens are passed to the HTML parser to be constructed into the document tree, as and when each suitable HTML tag is encountered, from to to and .

What we find more interesting than this is what the heck browsers do when they encounter not just badly formatted HTML documents, but downright illegally formatted documents. A browser parser has to be “fault tolerant,” else web pages would just fall over and

Edge is dead, long live Edge (Blink-powered).

fail to load. At a minimum, a browser needs to know what to do if a isn’t closed correctly, which happens all the time. Beyond this trivial example, it needs to know what to do if it encounters an unknown tag, an out-ofdate tag, or tags used in a non-compliant manner.

There’s no official definition of how to handle erroneous HTML code, but Apple’s WebKit code has a number of interesting comments that explain its approach to various classic mistakes, including unclosed or incorrectly closed tags, badly nested tables, highly nested tags, and incorrectly terminated tags.

Ultimately, the HTML processed by the parser will result in a Document Object Model, aka a DOM tree. Separately from the HTML, the CSS element of the page will also be parsed into a CSS Object Model tree. Unlike HTML, CSS is a context-free grammar, which makes it more difficult to break by silly humans. The parser has to process the CSS to determine the style of each element.

We’ve alluded to dynamic content and scripts. Really, don’t change much, but browsers are supposed to handle scripts synchronously – parsing stops until the script has been executed. If networked resources are required, these need to be loaded, and everything should be halted until they have been. Script authors can add a to wait until the document is parsed before it’s executed.

However, WebKit and Gecko utilise speculative parsing to read ahead and load any network-based resources, such as scripts, images, and CSS, to avoid stalls in page loading. This is smart, as scripts that request network-loaded style sheets cause issues if they can’t be reached.

Render tree

Things are starting to heat up. We know where things are in the page from the DOM tree created from the HTML. We also know how things should be styled

from the CSS Object Model tree, created from the CSS. Each render object is a literal rectangular area of specified size and position, with an attached style. Many objects are actually constructed from many rendered rectangles; the important thing to remember is that the render tree is constructed from the DOM tree.

We should point out that matching a style to a render object isn’t as straightforward as you might think, depending on how rules are inherited. And how the browser has to process inherited style rules and match them to objects can take a great deal of traversing trees.

Now layout can begin. This is the process of calculating exactly where those rectangles will go with the applied style. HTML is devised so layout can be done in a single pass, moving left to right and top to bottom. Layout can be recalculated on a global level (such as a global style change or window resize), or if “child” objects flag that it needs recalculating. Finally, the render tree can be “painted,” and is handled by the UI elements of the browser, because it’s reliant on the OS.

Powering the web

We’ve already mentioned that all modern browsers run JavaScript, with a JIT compiler for maximum speed. Each browser has its own JavaScript engine, and this enables you to “program the web” and create all the advanced interactive online applications. But JavaScript has its origins back in the 1990s, when no one really knew what it was going to be used for – so, say hello to Web Assembly.

Launched in 2015, it was available in most browsers by 2017, and was standardized at the end of 2019. It enables a low-level, cross-platform language that runs natively on the hardware via the browser. You can compile C/C++ and Rust to Wasm (Web Assembly). It runs in the same sandbox as JavaScript, so can be leveraged by its libraries for effectively free speed-ups.

Web Assembly is available in all the mainstream browsers, and the fact that it runs on the native hardware should offer an indication of the speed-ups developers know it will deliver over interpreted JavaScript.

At this point, you have an HTML5compliant webpage, with all the dynamic Web 2.0 spinning wheels you could ask for. The world (Google, Apple, Microsoft) appears to be settling on a WebKit/ Blink-based browser world, which is good for compatibility, and doesn’t stop others offering spin-offs. We dearly hope Mozilla retains the independence of Firefox, but it feels like it’s now fighting an uphill battle. The browser wars will return.

With the major browsers all tending toward one or two rendering engines, and the advent of Web Assembly reducing the importance of any JavaScript engine superiority – though, again, many browsers also reuse the same JavaScript engine – the question does arise as to what differentiates browsers today.

We’ve already covered a key difference, and that’s privacy. Simply not being Microsoft or Google should be an attractive feature in itself. There’s a group of browsers out there that utilize the Google Blink engine and the V8 JavaScript engine, but offer a set of unique extra features to lure users in.

The original alternate browser is Opera. Still going strong, it switched from its own Presto engine to Blink around 2003, maintaining both options for some time. Opera has retained a 2.5 percent market share for most of its life, from the mid-1990s, so has a dedicated following.

Brave is one of the new generation of modern browsers. Its schtick is partly privacy, partly a shared ad revenue system, and it leans on the bonus that protecting privacy enhances device battery life and extends your data plan. It’s based on the Blink and V8 engine.

Vivaldi was launched in 2016 by the co-founder of the Opera browser, who wanted to reclaim features of Opera lost by its switch away from the Presto engine – though, ironically, Vivaldi uses the same Blink and V8 engines. It pushes a unique streamlined interface that many find refreshing and intuitive.

Let’s make one thing clear: We’re not scientists. We’re just slotting things into motherboards and praying it works, then writing words about it. We leave unraveling the mysteries of the universe to those smarter and better trained than us.

But we are pretty darn good at building PCs, and we’ve had requests from the more scientifically minded of our readership for a tutorial on how to build a powerful home PC designed to work on data analysis, statistical modelling, and any other scientific endeavor. With lockdowns in effect, many of us learned to work from home, which is fine and dandy if you’re a writer but a problem if you need access to a lab. Those among you with a need to process huge datasets asked for a machine that could do that work from the comfort of your study, and here’s our answer.

It’s going to be expensive! We need two key things here: A truckload of RAM, and a high-end processor with as many cores as we can muster. This will enable our system to handle millions of points of data, making it capable of performing heavy-duty tasks such as training deep-learning models on consumer data, or analysing massive amounts of data.

Graphics are an interesting point of debate when it comes to data-science systems. You need to know exactly what sort of programs you’re going to be using on the machine – if you’re running visualisation or 3D-rendering software, a more powerful GPU is a must. If you need a system to just perform thousands of complex mathematical calculations, the GPU becomes less important. We’ll be using a relatively high-end graphics card in this build, but our main focus is the CPU and memory.

What else do we need? Well, a pricey processor demands a pricey motherboard, and we also need a hefty power supply to keep this system running. Liquid cooling for our processor is also a must-have, and we’d advise that you do the same even if you want to spend less. If you’re handling lots of data, you’ll need plenty of storage, so we’ll be using a high-speed M.2 SSD as our boot drive, and also including a larger HDD for secondary storage. To contain all this, we need a professional-looking PC case with good airflow and USB-C support for faster data transfers.

So it’s darn expensive, like we said, but we’ll go over some more affordable alternatives later on. This is essentially the best version of this machine we can build, but it’s a build you can tailor to your needs; if it’s overkill, cheaper components will work just fine.

CHRISTIAN GUYTON