3 ms·

> Firefox developers started porting components from XUL to HTML5 More specifically, Firefox's UI wasn't just ported to HTML5, but to web components. This mean

> Firefox developers started porting components from XUL to HTML5 More specifically, Firefox's UI wasn't just ported to HTML5, but to web components. This means much of two of the three major browsers (also parts of Chrome and Chrome OS) are using web components for the UI. Part of what enabled a move from XUL was that HTML finally got custom elements, where XUL/XBL had had custom components for a long time.

chrismorgan 4y ago
I don’t believe that Web Components had anything to do with it at all. When you control the scripting environment, and would be instantiating in scripting rather than in serialised markup, Custom Elements are one of the more superfluous features of the web platform: everything you can do with them, you can do every bit as effectively without them, at no meaningful cost or cost saving. The point where things get a little more interesting is when you introduce Shadow DOM, because then you do have genuine capabilities that can’t be expressed in other ways (though whether you want to may be another matter). But the real kicker, in my assessment and conclusion, is that both of these features landed after the migration from XUL to HTML began. (Not all that long after, and they have since been used variously, but the moving initiatives began before they were available.)
- bgrins 4y ago
  I worked on this project - Web Components had a lot to do with it. It's true they weren't feature complete in Firefox when we started the project (notably missing Shadow DOM) - but the first migration from late 2017 was XBL->Custom Element (https://bugzilla.mozilla.org/show_bug.cgi?id=1500626 https://bugzilla.mozilla.org/show_bug.cgi?id=1500626), and we used the migration project to inform performance and feature work for Web Components within Firefox. We could have converted the bindings to JS modules (and we did plenty of that too), but Web Components were key because they allowed us to migrate in-place with near API compatibility rather than rewriting the UI. I have a post at https://briangrinstead.com/blog/firefox-webcomponents/ https://briangrinstead.com/blog/firefox-webcomponents/ with more detail on that point.

chrismorgan 4y ago

I don’t believe that Web Components had anything to do with it at all. When you control the scripting environment, and would be instantiating in scripting rather than in serialised markup, Custom Elements are one of the more superfluous features of the web platform: everything you can do with them, you can do every bit as effectively without them, at no meaningful cost or cost saving. The point where things get a little more interesting is when you introduce Shadow DOM, because then you do have genuine capabilities that can’t be expressed in other ways (though whether you want to may be another matter). But the real kicker, in my assessment and conclusion, is that both of these features landed after the migration from XUL to HTML began. (Not all that long after, and they have since been used variously, but the moving initiatives began before they were available.)

bgrins 4y ago
I worked on this project - Web Components had a lot to do with it. It's true they weren't feature complete in Firefox when we started the project (notably missing Shadow DOM) - but the first migration from late 2017 was XBL->Custom Element (https://bugzilla.mozilla.org/show_bug.cgi?id=1500626 https://bugzilla.mozilla.org/show_bug.cgi?id=1500626), and we used the migration project to inform performance and feature work for Web Components within Firefox. We could have converted the bindings to JS modules (and we did plenty of that too), but Web Components were key because they allowed us to migrate in-place with near API compatibility rather than rewriting the UI. I have a post at https://briangrinstead.com/blog/firefox-webcomponents/ https://briangrinstead.com/blog/firefox-webcomponents/ with more detail on that point.