For the first time in years, someone is building a web browser from scratch

For more than two decades, building a new web browser from scratch has been practically unheard of. But a small company called Ekioh has its reasons.

The Cambridge, U.K.-based company is developing a browser called Flow, and unlike the vast majority of browsers that have arrived in recent years, it’s not based on Google’s Chromium or Apple’s WebKit open-source code. Instead, Flow is starting with a blank slate and building its own rendering engine. Its goal is to make web-based apps run smoothly even on cheap microcomputers such as the Raspberry Pi.

There’s a reason companies don’t do this anymore: Experts say building new browsers isn’t worth the trouble when anyone can just modify the work that Apple and Google are doing. But if Flow succeeds, it could rethink the way we browse the web and open the door to cheaper gadgets. That at least seems like a goal worth pursuing.

“It’s a huge task, but if you want something which is very small and very fast, you typically can’t start with one of the other engines,” says Stephen Reeder, Ekioh’s commercial director.

Made from scratch no more

Even if you don’t use Google Chrome, Apple Safari, or Mozilla Firefox, you’re almost certainly using those browsers’ rendering engines.

Vivaldi, Brave, Opera, and Microsoft’s Edge all rely on Google’s Blink engine and Chromium open-source code as the basis for their desktop and Android browsers. That’s because the web is much more complex than it used to be, and web browsers have become complicated pieces of software along with it. Chromium, for instance, has more than 25 million lines of code, according to Open Hub, and has received contributions from more than 8,100 developers.

As a result, most browser makers have backed away from building and maintaining their own engines. Microsoft famously gave up on its EdgeHTML engine a few years ago, switching to a version of Edge based on Chromium and the Blink engine in early 2020. Opera had done the same in 2013, abandoning its venerable Presto engine and adopting Chromium.

Compounding the matter is Apple, which requires all third-party browsers on iOS to use its own WebKit engine, ostensibly for security reasons. Even Mozilla, which develops its own Gecko engine for Firefox as a matter of principle, still has to use WebKit on iOS. Not being allowed to use a different browsing engine on one of the world’s biggest computing platforms could further dissuade developers from trying to make their own.

Chris Coyier, the cofounder of CodePen and creator of CSS-Tricks, says that due to the head start that big browsers already have, building a competitive browser engine would be a billion-dollar effort with no clear payoff. He’s argued that browser makers can focus on user-facing features, such as Brave with its focus on privacy or Vivaldi with its extreme customization, rather than behind-the-scenes rendering-engine improvements.

“It’s not a game that’s worth playing,” Coyier says via email. “A better game is: how can we make the [browsers] we already have better?”

New browser, new business

So why is Ekioh even bothering? With Flow, the company sees a chance to play a different game entirely. Instead of taking on big browsers directly, it’s building a browser around specific uses where a new rendering engine would have clear benefits.

Ekioh’s business is in providing web-based applications on embedded systems, such as connected TV boxes, smart displays, and car dashboards. On these kinds of devices, Ekioh believes that a feature called multithreaded layout could vastly improve performance, especially for things such as animations and effects.

“In a nutshell, what makes Flow different from the other browsers is its performance,” Ekioh’s Stephen Reeder says.

“We can lay the text out, change the size, and animate all that at the same time, so you get a richer UI,” he says.

In addition, Flow supports a feature called GPU rendering, in which a computer’s graphics processor is fully in charge of drawing objects on a page. This uses much less memory than having the computer’s main processor do some of the work, leading to faster performance on cheap devices where memory is limited.

While other browsing engines can tap into multithreading to juggle browser tabs, and some have started dabbling in GPU rendering, they’re not designed to throw multiple processor cores at a single web page. Reeder says that if they wanted to do that, they’d likely have to rewrite their code from the ground up.

“That actually is a redesign of the core browser engine,” he says. “It’s not something you can retrofit.”

Perhaps more importantly, Ekioh’s business model for Flow avoids the typical pitfalls of the browser business. Instead of trying to scale up and monetize an audience around search partners or advertising, it plans to license the software to electronics vendors, pitching it as a less expensive way to build faster and more responsive products.

“If there’s a product that’s got any form of graphical user interface on it, there’s a potential to use HTML,” Reeder says, referring to the language that all web pages rely on. “If you can create a product with slightly less memory and a slightly slower processor and still achieve the same customer experience, then that product is going to be cheaper.”

Not for desktop use (yet)

Ekioh hopes that Flow will start showing up in actual products later this year, but anyone can play around with it on a Raspberry Pi right now. (The company added support for versions older than the current Raspberry Pi 4 last week.)

Even so, it’s not something you’d want to use in place of Chrome or Firefox. The current version doesn’t support tabs, bookmarks, or extensions, and it depends on keyboard navigation for basic functions such as forward and back. Once you’ve navigated past Flow’s welcome page, you don’t even get an address bar.

Reeder says the company wants to focus on the core rendering engine before considering whether to add more user-facing features. The engine alone is a major undertaking, and every time Ekioh tests Flow on a batch of new websites, it finds new features that it needs to implement.

“The conclusion of where this could go could well be a desktop browser, but we’re not there yet,” he says.

Echoes of an earlier era

Still, the mere idea of a new rendering engine is exciting to some experts in the web browsing space.

Rachel Nabors, a former program manager on Microsoft’s Edge browser who also wrote a book on web animation, says that even amid a proliferation of web-based apps, graphics and animation can still seem like an afterthought for browser makers. To her, Flow’s multithreaded layout and GPU rendering are a breath of fresh air.

“Browser development is still very much steeped in the browser as a document reader,” she says. “It’s always been a little odd that browser makers have lagged behind in making performant graphics for the web.”

“From a social, civic and individual empowerment perspective ceding control of fundamental online infrastructure to a single company is terrible,” Beard wrote at the time.

In practice, that concern is a bit overblown these days. As a Chromium contributor, Microsoft itself now has some say over the browser’s direction, as do outside firms such as Igalia, a consulting group that helps companies get new features implemented in major browsers.

But as Brian Kardell, Igalia’s developer advocate, points out, a diverse browser culture still has its merits. Even with no shortage of outside input, building browser engines is an expensive, time-consuming process that tech giants such as Apple and Google are largely funding themselves. There’s no guarantee that they won’t eventually lose interest and underfund their efforts.

“There is something about diversity that is just inherently good,” he says. “For the same reason that you don’t only want to plant a single crop.”

While Flow is just a blip on the browser scene today, you never know where it might go. As web designer John Allsopp notes, Apple surprised a lot of pundits by using a little-known engine called KHTML when it launched Safari in 2003, rather than basing its code on Firefox. But as an Apple engineer noted at the time, KHTML was considerably less bloated and more lightweight, and Steve Jobs made a point of talking up Safari’s speed while demoing the browser at that year’s Macworld Expo.

Apple’s engine eventually turned into WebKit, which became the basis for Safari on iOS. Google then adopted WebKit for its Chrome browser before creating its own variant in Blink. The historical precedent isn’t lost on Allsopp, who sees a parallel in Flow’s focus on performance above all else.

“Maybe it’ll open up the web to a whole new class of device, where we haven’t seen it,” he says.