Building a Better Web Browser - James Mickens - Harvard CS Colloquium 2015
Paul IrishRecommended by 4 HN commenters across 5 months, 2017–2023
talk · advanced · evergreen · 2017–2023 on HN
James Mickens's 2015 Harvard colloquium argues that browsers are bloated and insecure because feature races trump clean interface design. He presents a cleaner, more secure browser architecture (Atlantis) with a much smaller API surface.
HN cites it whenever people discuss rebuilding the web platform or what a better browser architecture could look like.
Up next
2 mo on HNEisenhower Farewell Address (Best Quality) - 'Military Industrial Complex' WARNING
Ewafa
Recommended 2× on HN · 2018–2023
10 mo on HNBreakthrough in Nuclear Fusion? - Prof. Dennis Whyte
MIT Club of Northern California
Recommended 11× on HN · 2016–2024
12 mo on HNSugar: THE BITTER TRUTH
University of California Television (UCTV)
Recommended 13× on HN · 2010–2024
6 mo on HNAndrej Karpathy - AI for Full-Self Driving at Tesla
Matroid
Recommended 4× on HN · 2020–2022
4 mo on HNA Portal Special Presentation- Geometric Unity: A First Look
Eric Weinstein
Recommended 3× on HN · 2020–2022
5 mo on HNThe Future is a Dead Mall - Decentraland and the Metaverse
Folding Ideas
Recommended 6× on HN · 2023–2025
7 mo on HNThis is Financial Advice
Folding Ideas
Recommended 9× on HN · 2023–2026
14 mo on HNWhat the heck is the event loop anyway? | Philip Roberts | JSConf EU
JSConf
Recommended 16× on HN · 2015–2025
13 mo on HNRich Harris - Rethinking reactivity
You Gotta Love Frontend
Recommended 15× on HN · 2019–2026
10 mo on HNCrockford on JavaScript - Volume 1: The Early Years
YUI Library
Recommended 10× on HN · 2013–2022
10 mo on HNRailsConf 2016 - Turbolinks 5: I Can’t Believe It’s Not Native! by Sam Stephenson
Confreaks
Recommended 6× on HN · 2017–2020
10 mo on HNJavaScript: The Good Parts
Google TechTalks
Recommended 11× on HN · 2009–2020
8 comments from Hacker News
I used to get really angry at CSS because of all of the things that made it a bad fit with component-based systems like React. It made me so unhappy that I worked full-time for about nine months on this project, which was a React-like component system that rendered to canvas. link I got pretty far! But I gave up working on it when I realized that I was going to be pushing this boulder uphill for years. So what changed? I picked up Swift and SwiftUI, and it turns out that some of the ideas that I had were the same ones the SwiftUI folks went with! For all the web has given us, I think its APIs are holding us back now. I still think we need something open and decentralized that competes with the App store and Play store, but one that offers apps that use basically the same APIs and technology that the native apps use. Last thing: I know Apple cripples browsers on their platforms. I've run into all those issues personally in my work! That still doesn't make the web the right thing. Here's James Mickens telling us how to fix the browser's busted architecture: ▶ this video
James Mickens has a talk about doing exactly this [1]. It's a perfectly sensible proposal and the talk is well worth the time to listen to. He makes a solid argument for why this should be done. Problem: in reality, it is unworkable and will never happen, and even if it did the actual level of "development" that we actually see in the real world would end up in a situation just as bad as the situation we are in now. [1] ▶ this video
James Mickens at Microsoft Research presents Atlantis, which I definitely think this still the most forward-looking browser architecture out there: ▶ this video Ideas from this effort are going to be trickling into browsers for years to come. For example, if you squint a bit, you might see a conceptual resemblance between the Syphon interpreter in Atlantis and WASM in shipping browsers.
> Doesn't every freaking mainstream technology suck? I regularly come across rants from significant developers regarding this issue. There probably is no way to prevent this from happening. Because worse is unfortunately better. Web technology is fundamentally different in that you have a big standards body regulating everything from layout down to color blending, then leave it up to multiple vendors to implement all that stuff at great expense and with long delay. Worse, it's all shoehorned on top of some "document model" than was never designed with applications in mind. It's a waste. To see what a better platform could look like, consider this: link ▶ this video The key here is reducing surface area. It's entirely possible that WASM will bring us closer to that, but the web developers of today probably won't like that. > I regularly and seriously consider to leave software development because of this (as I'm really suffering) but then I remember how much power it gives me despite the horrible faults it has. I don't know what you do, but I find web development to be significantly more frustrating than other areas. That doesn't mean there isn't frustration elsewhere though and it's definitely part of the job.
James Mickens gave an interesting talk on what we could do to build a better browser: ▶ this video I'm hoping that WebAssembly might be a route towards allowing something like this to happen. If an alternative to HTML/CSS/JS could be developed in WebAssembly, then we could have a situation where HTML has competition, rather than being the only way to build a website. And browsers can become simpler as the rendering duties are moved out of the browser and to the website itself.
"Is this really the way forward?" No. The way forward for scale-free systems which implement a hierarchy of competence is to have "the factory smaller than the product" [1]. Instead of the Chrome Canary team and the various Working Groups dictating from above what passes as valid, let the rules be sent at the same time with the interpretation of the rules [2]. In the same manner DNA encodes proteins with no mention of the underlying morphology, but once the RNA starts building the morphology arises. [1] Jim Keller talking about DNA Origami at 19:18, link [2] Not even such a new idea, "Building a Better Web Browser - James Mickens - Harvard CS Colloquium 2015", on rendering at 04:20, ▶ this video
I'm working on a new framework that attempts to take what I think are the best ideas from the web (zero installation, easy to lay things out without tracking measurements yourself) and combines them with the best ideas from React (functions as components, ideally no mutable state). I want to solve what I see as the original sin of the web: inept separation of presentation from content. The other thing I aim to solve is the issue of the browser and corresponding web standards being a monolith so large that only Google and Apple can afford to implement them. By wrestling back control over layout, I hope to show that a next-generation browser could be much more like what James Mickens laid out with the research he presented in this talk: ▶ this video I decided to prototype it in JavaScript, and right now it just renders into a canvas element. I love working on it, because all the unit tests run really fast. It can do that because there's no browser in the way - node-canvas is much lighter weight. Once the design is settled down, I'd like to rewrite it in Rust. The other advantage of this is that it is incremental. It'll run in any existing web browser, and building a cut-down browser that isn't web-compatible is doable in a few weekends. The best way to see its capabilities so far is to look at the test screenshots: link - see especially text-actual.png, text-concave-cutout-actual.png, text-diamond-actual.png. I fell down a rabbit-hole with that a bit and made it wrap text around a
I always like to refer to Ian Hickson's Requirements for Replacing the Web [0] when this topic comes up. They seems to encapsulate well the social, technological and economic dynamics required when discussing replacing the Web. However, few attempts (Crockford's Seif Project [2], MS's Project Atlantis and Project Gazelle [2][3][4][5]) seemed have to heed this wisdom. [0] link [1] link [2] ▶ this video [3] link [4] link [5] link