Building a Better Web Browser - James Mickens - Harvard CS Colloquium 2015

By: Paul Irish

316   3   20163

Uploaded on 12/11/2015

2015-02-26. CS Colloquium at Harvard School of Engineering and Applied Sciences.

Notes from this talk:
* http://blog.rossry.net/notes-james-mickens/

Abstract
Web browsers are defining increasingly rich APIs for networking, multimedia, and local storage. This is good in the sense that web applications can now approach the sophistication of traditional desktop applications. Unfortunately, in the race to add new browser features, discussions about clean interface design are often relegated to second-class status. The result is browsers that are difficult to make robust and secure. Browsers execute so many important applications, and expose so much complex functionality, that they should be treated as operating systems. I will discuss the implications of this claim, using case studies to motivate some core abstractions that browsers should export. I will also discuss some research challenges for building the next generation of browsers.

Bio
James Mickens is an associate professor of computer science at Harvard. Often described as The Hardest Working Man In Computer Science, his research spans genres, fields, and verb tenses. His seminal paper on byzantine fault tolerant proofreading has been mistakenly cited over 3000 times, and his 1987 paper “We Need More and Better Computers” provided the foundation for cloud computing, mobile computing, and any type of computing that benefits from more and/or better computers.

More Mickens:
* http://mickens.seas.harvard.edu/wisdom-james-mickens
* http://research.microsoft.com/apps/search/default.aspx?q=mickens&s=pu
* http://research.microsoft.com/pubs/251792/149-li.pdf
Domino: Understanding Wide-Area, Asynchronous
Event Causality in Web Applications
* https://vimeo.com/95066828 so so good

Comments (1):

By maxharris    2019-09-18

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: https://www.youtube.com/watch?v=1uflg7LDmzI

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: https://github.com/maxharris9/layout/tree/master/test/screen... - 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 arbitrary polygons, hyphenating on syllable breaks and everything.

I just lost my job a couple of weeks ago, and I've been taking time off to work more on this thing. Tomorrow I hope to get mouse click events tracked through the component tree. And at some point in a week or two, when that's done, I really should write the application that I had in mind for it!

I know a lot of people have concerns about accessibility with the approach I've taken, and all I can say to that is, please help me work on that instead of criticizing me. I know there is talk about an accessibility DOM coming in browsers, but I fear that I'll just have to fall back to rendering plain HTML in order to drive screen readers, which is a terribly inefficient and indirect way of doing things. Also I don't even know where to begin with screen readers, what's the most popular software for that, etc.

Original Thread