The Bytecode Alliance: Building a secure, composable future for WebAssembly
> We have a vision of a WebAssembly ecosystem that is secure by default, fixing cracks in today’s software foundations. And based on advances rapidly emerging in the WebAssembly community, we believe we can make this vision real.
> WebAssembly can provide the kind of isolation that makes it safe to run untrusted code. We can have an architecture that’s like Unix’s many small processes, or like containers and microservices. But this isolation is much lighter weight, and the communication between them isn’t much slower than a regular function call. This means you can use them to wrap a single WebAssembly module instance, or a small collection of module instances that want to share things like memory among themselves.
The Baseline Interpreter: a faster JS interpreter in Firefox 70
> The Baseline Interpreter sits between the C++ interpreter and the Baseline JIT and has elements from both. It executes all bytecode instructions with a fixed interpreter loop (like the C++ interpreter). In addition, it uses Inline Caches to improve performance and collect type information (like the Baseline JIT).
Technical Details on the Recent Firefox Add-on Outage
> Recently, Firefox had an incident in which most add-ons stopped working. This was due to an error on our end: we let one of the certificates used to sign add-ons expire which had the effect of disabling the vast majority of add-ons. Now that we’ve fixed the problem for most users and most people’s add-ons are restored, I wanted to walk through the details of what happened, why, and how we repaired it.
Standardizing WASI: A system interface to run WebAssembly outside the web
> WebAssembly is an assembly language for a conceptual machine, not a physical one. This is why it can be run across a variety of different machine architectures.
> Just as WebAssembly is an assembly language for a conceptual machine, WebAssembly needs a system interface for a conceptual operating system, not any single operating system. This way, it can be run across all different OSs.
> This is what WASI is — a system interface for the WebAssembly platform.
Implications of Rewriting a Browser Component in Rust
> The style component is the part of a browser that applies CSS rules to a page. This is a top-down process on the DOM tree: given the parent style, the styles of children can be calculated independently—a perfect use-case for parallel computation. By 2017, Mozilla had made two previous attempts to parallelize the style system using C++. Both had failed.
Entering the Quantum Era—How Firefox got fast again and where it’s going to get faster
> Over the past seven months, we’ve been rapidly replacing major parts of the engine, introducing Rust and parts of Servo to Firefox. Plus, we’ve had a browser performance strike force scouring the codebase for performance issues, both obvious and non-obvious. We call this Project Quantum, and the first general release of the reborn Firefox Quantum comes out tomorrow.
The whole web at maximum FPS: How WebRender gets rid of jank
> With WebRender, we want apps to run at a silky smooth 60 frames per second (FPS) or better no matter how big the display is or how much of the page is changing from frame to frame. And it works. Pages that chug along at 15 FPS in Chrome or today’s Firefox run at 60 FPS with WebRender. So how does WebRender do that? It fundamentally changes the way the rendering engine works to make it more like a 3D game engine.
Inside a super fast CSS engine: Quantum CSS (aka Stylo)
> This new engine brings together state-of-the-art innovations from four different browsers to create a new super CSS engine.
Firefox 54: E10S-Multi, WebExtension APIs, CSS clip-path
New stuff in new firefox.
A cartoon intro to WebAssembly
> WebAssembly is fast. You’ve probably heard this. But what is it that makes WebAssembly fast? In this series, I want to explain to you why WebAssembly is fast.
Firebug lives on in Firefox DevTools
Firebug is dead. Long live Firebug.