Inside a fast CSS engine • Hacker News Board

Re: Inside a fast CSS engine

#141

Post by matt_kantor » Wed, Aug 23, 2017, 7:34 PM UTC

lucideer wrote: post #6

It's great to see any company going into detail about their technical implementation, so I'm extremely hesitant to be critical, but I'm really curious who the target audience for this one particular article is. It's a very very odd mix of language that sounds like it's directed at a very young child and standard technical speak. Not the usual for the Hacks blog. Not to fault the article too much, but I just found the…

There were only two small parts that rubbed me this way, and they may just be related to my own knowledge/interests/biases:

1. The brief diversion about registers vs RAM and the brain analogy seemed a bit silly. I feel like anyone who would be interested in this article would find it completely unnecessary. It was just a tiny paragraph and one doodle though so it didn't really detract from the article.

2. Going the other way, Lin could have spent another few sentences talking about the compositing step and how GPUs enter into the picture (also why some CSS properties are "compositor-only"). I know compositing is tangential to the core of the article, but there were other brief tangents like the Rust stuff so a similar blurb about compositing wouldn't have been out of place (plus I find it super interesting).

Those are my only two nitpicks and the rest of the article did an excellent job threading the needle between informativeness and approachability without being too fluffy or verbose (e.g. Lin rightly didn't waste words explaining what the DOM is).

Re: Inside a fast CSS engine

#142

Post by bholley » Wed, Aug 23, 2017, 8:34 PM UTC

taeric wrote: post #126

taeric wrote: post #102

Earlier quoted context omitted.

I was basically restating the restriction for the parallel scan. It goes from parent down so that during the scan you don't do something that causes the scan to have to restart. I was also shooting from the hip for things I'm interested in, here. I'm not sure it matters. But, if on scanning, you pick relevant rules to apply based on the path to a node, then I could see some trickiness on having to consider both the t…

Coming back to this before I finally sleep. I missed your point about selector matching and style application. I think that is ultimately where my hip shot missed on this. (I have never had to reserve the right to be wrong. Just to assume it. :) I still feel there is some danger there, but I think that is just clinging to an initial shot. I am curious why rust's help was needed to get this, now. A basic thread pool s…

Yeah, the key reason Rust is necessary here is that there is an insane amount of complexity in the heart of modern web engines. Injecting concurrency into the intersection of DOM and Layout is only realistic with some kind of static guarantees against data races, and Rust is the only tool I'm aware of to do that.

One neat thing is that we use rust-bindgen to walk C++ data structures, which extends Rust's concurrency guarantees into C++. We also have an FFI layer for invoking C++ code, and we have some careful static analysis of that callgraph from the entry points to be sure we're not mutating anything.

Re: Inside a fast CSS engine

#143

Post by lucideer » Thu, Aug 24, 2017, 1:37 PM UTC

crescentfresh wrote: post #84

I always wonder, who puts together nifty little blog posts on this kind of thing complete with graphics just for the article? By that I mean, literally what title do they have? Myself and my colleagues would/could write up a technical breakdown of something neat or innovative we might have done to solve some problem at work, but we sure as shit can't make cool little graphics interspersed between opportune paragraphs…

In my experience, it's happenstance that varies on an author-by-author basis. I've worked in places where one author would put up a mostly text article which would be immediately followed by something incredibly creative like this from another colleague.

It's a bit of a pity really, as it would be nice to take some of the insight of the not-quite-so-graphically-gifted engineers and have them collaborate with colleagues to present it in a great accessible format, but I've not seen this happen in practice.

Re: Inside a fast CSS engine

#144

Post by altotrees » Thu, Aug 24, 2017, 2:33 PM UTC

Really late to this discussion but wow. Having worked as a web developer/tech writer and editor, this writeup pushed all my buttons. High-level concepts broken down in an exciting way. Nothing turns me off quite as much as clicking on a tech blog post and suddenly feeling like I am reading a whitepaper or portion of someone's Ph.D. dissertation. This is the kind of post I love — stripping things down to the nuts and bolts but keeping me engaged in a way that gives me that excited feeling in the pit of my stomach like I am watching something important take shape.

This is a fantastic technology and I feel like Servo has a pretty amazing future ahead of it. Exciting stuff.