Hello again :) Appreciate the great feedback so far!
So I'd like to clear a few things up. There are many unknowns here which need exploring before moving further. Particularly we want to retain as much of the semantic model of the web while still allowing native-like frame rates. I'd like to spend some time breaking the document up and listing things we can do to preserve as much of the semantic model as we can, so please hold off for a bit while I do that. Thanks everyone! Victor On Mon, Apr 30, 2018 at 7:03 PM, Victor Porof <vpo...@mozilla.com> wrote: > Hey folks, > > Last quarter I've been drafting a roadmap to explore the advantages of a > new web API, fundamentally different from the DOM. It's aiming to expose > similar core web features, but with predictible cost and performance, in a > declarative immediate-mode manner. > > This research was driven by a desire to reconcile the growing set of > differences between today's development practices and existing browser > APIs. At the very least, "the UI is a function of state" is a preferred > abstraction trend, different from what browsers directly provide yet > incredibly prevalent among modern frameworks, so it's worth discussing the > implications. > > "Project Metalhead" is a proposed vector to address that disconnect. It's > an alternative to canvas 2D and WebGL, which: > * retains accessibility and internationalisation > * efficiently renders a direct mapping of existing CSS primitives > * supports form controls with native look and feel > * makes it easier for web apps to live inside web workers > * is specifically designed to work well with frameworks employing a > virtual DOM (e.g. React) > * can give Mozilla the driving seat for the next round of web performance > wins > > The proposed core graphics API is just a subset of the bigger > architectural solution. Investigation is required in order to understand > exactly how accessibility, layout and other existing browser behaviour can > be a concrete part of this new API. Prior research has given possible but > not definitive answers towards making sure there's no room for unintended > loss of user control. > > Obviously such a vector takes us into currently unknown territory, which > I'd like us to explore before moving further. I've written a document > describing the roadmap, along with details about a proof of concept > technical implementation in more detail: https://docs.google. > com/document/d/1YLM1_jlTKYvNa04rEHWw6RBEFQO5aAd8vd-S3yXJjI8 There's a lot > of info there, so be sure to check out the FAQ, alternatives and > implementation. The document is open to everyone at Mozilla, but if you > need access to it let me know. > > Here's a video showcasing the expected performance improvements in action: > https://www.youtube.com/watch?v=kDrUfmXLrIU > > Among other things, the above demo is showing WebRender rendering content > running in browsers other than Firefox, powered by a proof of concept of > the proposed API. This approach intends to mimic a real world native > implementation across various browsers, instead of just a simple polyfill. > > I'd love getting some opinions and a roadmap review for this. Even though > what we have right now is a technically flawed proof of concept > implementation and incomplete solution, is it worth pursuing this further? > > If anyone's interested, I'd also be happy to have a conversation on vidyo > about how everything works in more detail. > > Thanks! > Victor > > *This proposal has been circulating outside of browser-arch last week; in > the hopes of getting broader feedback I'm posting it here instead. > Apologies if you've seen it already.* > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
