randallu

The main benefit of using CSS Transitions and Animations on the accelerated properties (transform & opacity) is that the animation will be run by the compositor (at least in WebKit browsers; I think Blink's new animation engine changes this).

Running the animation in the compositor means:

1. You avoid a style recalc on every frame (which can be a big deal).

2. The animation keeps running even if the WebProcess gets contended (by painting new content, handling slow JavaScript, GC).

It's fine to mess with transform and opacity from JavaScript, and for gesture handling you have to, so it needs to be fast, but it has more overhead than a CSS Animation would have.

My understanding is that human-neanderthal interbreeding rarely resulted in viable offspring (though some did, and is where blonde/ginger hair and blue eyes come from in modern humans).

Is that similar here? Are there traits in modern goats or sheep that came from the other?

hterm -- the terminal implementation that the Chrome ssh plugin and crosh is based on is pretty hackable, too.

I imagine not shipping a derivative SDK is to prevent one vendor from making an incompatible "Android+" (and the next vendor, etc) which would cause fragmentation. Instead they get to expose extra APIs through the updater app in the one true Google Android SDK (and you use the same mechanism to get the Google APIs).

Yeah, the CSS OM is really horrible too. CSS Animations is another area where you end up feeding huge generated strings into the DOM -- in theory Web Animations is meant to improve this, though personally I feel like the API too high level and ends up being really large because of this :(.

In your example, I think it'd only be a small patch (for WebKit, where my experience is) to optimize "elem.style.transform = new WebKitCSSMatrix(a,b,c,d)" without intermediate stringification. Mozilla doesn't expose a CSSMatrix type unfortunately. I've done some similar things for other CSS properties in WebKit -- have you considered submitting a patch? I've found the WK guys super receptive to small optimizations which don't change observable behavior (i.e.: you can't tell if the WebKitCSSMatrix was stringified or not currently) like that.

No, that's not what I meant.

I'm saying that DOM through its relationship to HTML has weaknesses that make it unsuitable for building application components out of. "jQuery-enabled div-soup" is an example of how mixing presentation with model and logic yields unmaintainable results.

I have been interested in React.js recently, since it provides an interface to create reusable components and to use them inside a rich programming language with full types. I think that's a better example of a competing idea.

My experience is with building single page apps from scratch, so maybe there's a common use-case (embedding a twitter widget, or a 3rd party comment system in a blog) that Shadow DOM and Custom Components will address that I'm not familiar with.

I disagree that the Shadow DOM is pretty awesome. I think scoping style is valuable, but building components that are exposed as new tags is not appealing given the vast complexity of the implementation and the limitations of tags.

Markup has a very weak type system (strings and children) which makes building complex UIs more painful than it has to be (this also stands for markup driven toolkits like angular and knockout -- where the equivalent of main() is HTML markup and mostly declarative). Markup isn't a real programming language, and it's very weak compared to a true declarative programming language.

JavaScript however is a real programming language with all of the constructs you need for building extensible systems. For building anything complex (which is where Shadow DOM should shine) you will need to use extensive JS, you will need your Shadow DOM components to expose rich interfaces to JS... At which point, why are you still trying to do mark-up first -- it's something that's more "in your way" than helpful.

It's interesting that the advantage for LLVM is that it was used to create a compiler for a processor with a secret and proprietary instruction set.

If NVIDIA had to use GCC (surely they'd have just done their own instead, but for the sake of argument) then we'd all get to learn more about their architecture and maybe make compilers for different languages that natively target their processors...

Oh, nice! For some reason I thought that was only for canvas.

No, translateZ just makes it a composited layer. Hardware comes much later in the pipeline and possibly in another process.

The content of the layer isn't hardware rendered. It's rendered by the CPU and uploaded to a texture. In WebKit and probably Blink there's a fast path for images, canvas and video so that they can be directly uploaded or (on some platforms like Mac) bound to a texture avoiding an upload copy.

Microsoft and (maybe) Mozilla have a "hardware rendering" path via Direct2D, but Chrome and WebKit don't, they have compositors which can use the graphics hardware to perform compositing, but not rendering.

The "translateZ: 0" description is a bit misleading -- I wish he'd provided numbers for the improvement. In general using composited layers is more expensive (since the CPU still does rendering of the image, must upload it to texture, etc).

It might be a win if the thing you apply it to:

1. Never changes, but the content around it changes often.

2. Is hard to render (lots of shadows, etc).

The layout and paint thrashing is a really good optimization though. You should be able to insert as many things into the DOM as you like without triggering a layout SO long as you don't read back (like consulting offsetLeft). I think the Chrome inspector will mark read backs with a little exclamation point in the timeline with a tooltip "synchronous layout forced" and a backtrace to your JS...

Model S has a fast pulsing green light around the charge port when it's charging.

Chromium is _huge_. If I just wanted to use the HTTP library (with tls and spdy) then how would I build just that, and cleanly integrate the build into my own project in a way that won't require constant revisiting every time I update my chromium sources?

It's pretty depressing they spent all that money on apps and seemed to go nowhere with any of them.

If you have something hot then what can Yahoo possibly offer you to go and work there, knowing that everything else they touched went nowhere?