1 of 47

What I Talk About When I Talk About Running on the Web

Jack Moffitt // jack@metajack.im // @metajack

Mozilla Research

PolyConf 2017

2 of 47

One: Space Jam is forever

3 of 47

“Describing why the Web is horrible is like describing why it’s horrible to drown in an ocean composed of pufferfish that are pregnant with tiny Freddy Kruegers”

James Mickens, “To Wash It All Away”

4 of 47

Omnipresence

5 of 47

6 of 47

Low barrier to entry

most technology

the web

7 of 47

Most developers are web developers

Stack Overflow Developer Survey

8 of 47

Web developers want to make apps

9 of 47

Web developers are ambitious

10 of 47

11 of 47

Two: We were not tall enough

12 of 47

13 of 47

1994 Pentium

14 of 47

2002 Pentium IV

15 of 47

2008 Nehalem

16 of 47

Web pages are fractal

17 of 47

18 of 47

Let’s rewrite C++ from scratch so that we can rewrite a browser from scratch.

19 of 47

Rust triforce

Fast, reliable, productive: pick three.

20 of 47

A safer web with Rust

WebAudio implementation in Firefox had 34 security critical bugs
All were array out of bounds or use after free errors
All would have been prevented by the Rust compiler

21 of 47

How do we make Servo fast?

Parallel styling
Parallel layout
Constellation
WebRender
(more on the way)

22 of 47

Parallel layout visualized

23 of 47

Monolithic engine

24 of 47

Multi-process engine

25 of 47

Servo pipeline

26 of 47

Servo constellation

27 of 47

cross-domain iframe from as.jivox.com

28 of 47

2008 Nehalem

29 of 47

2016 Skylake

30 of 47

WebRender Key Ideas

Retained mode instead of immediate mode
Designed for rendering CSS content
Draw the whole frame every frame
Use GPU for tasks it’s better at; free up CPU

pub enum SpecificDisplayItem {

Rectangle(...),

Text(...),

Image(...),

YuvImage(...),

WebGL(...),

Border(...),

BoxShadow(...),

Gradient(...),

Iframe(...),

PushStackingContext(...),

PopStackingContext,

PushScrollLayer(...),

PopScrollLayer,

}

31 of 47

32 of 47

Three: Problems of many sizes and shapes

33 of 47

Browser

34 of 47

Browser.html

35 of 47

Webviews

36 of 47

Apps

37 of 47

More apps

38 of 47

Other craziness

39 of 47

Existing options

WebKit API
UIWebView (iOS), WebView (Android)
Chrome Custom Tabs (Android)
Chromium Embedded Framework (CEF)
xulrunner
Electron

40 of 47

What do we need?

Lower-level API suitable for things that aren’t browser-like
Higher-level API needed that web developers can use

41 of 47

Four: Never stop never stopping

42 of 47

Browser.html

43 of 47

Runtime design

Runtime engine

Added APIs

Servo engine

We started imagining a runtime based on the web engine. The runtime would execute JavaScript code, be able to manipulate the web engine, and also provide services the app can use that aren’t in the engine.

These could be window management, which is something an app needs to do. Or implementing new kinds of history management.

Runtimes like Electron exist, but aren’t actually suitable for all tasks, because they throw out the web security model. The team at Brave has run into this trying to build a browser on electron, as has the Browser Futures Group at Mozilla when they experimented with similar ideas.

It’s a complicated problem to figure out how the runtime should be designed to satisify all the constraints, and this is what the browser.html team has shifted to doing over the last year.

44 of 47

Starling

45 of 47

Atom with Markdown preview

Atom is a text editor written with web technology that runs on Electron.

It’s a pretty amazing example of the potential of the platform, but it also highlights some important problems.

It has a plugin for previewing Markdown files for example. While you’re working it will generate a rendered view of the document and display it so you can see the output. Unfortunately, for anthing but small documents, it takes a while to generate the output, and while it is doing that, the interface because unresponsive. You can’t type for a little bit.

This is a solvable problem, and VS Code for example managed to solve this one. However, you may not know you need to solve it until you hit it.

And if you program your application in sort of a standard way, you are very likely to run into problems similar to this. All the work we did to make Servo nice and responsive just goes out the window unless you are careful with how you architect your app.

46 of 47

Starling ideas

The easiest or obvious way is the right way
Integration with Rust
Structure apps as communicating async services
Built on top of Streams and Tokio
Optimize JS / Rust boundary

Our goal is to always be responsive, which means we can’t block the script thread.

We want to make it so that the obvious way to structure your application eliminates this problem from the beginning.

Also, some tasks, perhaps even Markdown rendering, are perhaps better done in a systems language like Rust. It should be easy to swap modules out with Rust modules when needed.

Different pieces of the app would be split into services that communicate asynchronously. These would communicate via the JS Streams API.

A similar API exists in Rust called Tokio, and these things can be bridged so that services can be written in Rust or JS.

Finally, we have some ideas on how to make interfacing JS and Rust much easier and much faster. This is work we were exploring for Servo anyway, to make DOM API calls faster. It turns out to be just as useful in this situation too.

We hope that the combination of a fast and safe web engine with a flexible embedding and runtime combined with a programming model suited for taking the most advantage of the platform will be compelling.

47 of 47

How to get involved

Repo - https://github.com/servo/servo
IRC - irc.mozilla.org #servo
dev-servo mailing list - https://lists.mozilla.org/listinfo/dev-servo
Nightlies (Linux, macOS, Windows) - https://dl.servo.org
Curated bugs for new contributors - https://starters.servo.org