18 ms·
The Firefox UI Is Now Built with Web Components
- kick 7y agoRemember when a tab freezing didn't make Firefox's UI chrome unresponsive? I do, too.
- pessimizer 7y agoWeb 4.0 is the internet of race conditions. Thanks, javascript everywhere.
- hombre_fatal 7y agoI don't get it. Javascript would have categorically improved on this compared to more traditional multi-threaded solutions.
- GrayShade 7y agoYou can still have race conditions in single-threaded async code.
- cjones26 7y agoWell I don't think that could technically be considered a race condition, as it's clearly a design problem in the code causing what would appear to be a "pseudo" race condition.
- GrayShade 7y agoWhy not? It is a race condition, just like TOCTTOU is a race condition that doesn't necessarily involve threads. Note the difference between race conditions in general and data races that involve unsynchronized access to shared memory.
- minitech 7y agoAnd “Javascript would have categorically improved on this compared to more traditional multi-threaded solutions” remains true nevertheless.
- cjones26 7y agoWhat? JavaScript is a single threaded language...
- Yoric 7y agoAnd despite this, I've encountered lots of race conditions in JavaScript, thanks to the magic of async programming. Harder to debug than multi-threaded ones, too.
- amelius 7y agoEvery tab's UI (and the main UI) can still run in a different thread or process, I suppose ...
- skrebbel 7y agoI'd assume that the Firefox chrome runs in its own process. Why would the switch to web components for the chrome change that?
- MikusR 7y agoWhen was that?
- floatboth 7y agoI remember when it did — before the "Electrolysis" project, when everything ran in one process. This was quite a long time ago already.
- breatheoften 7y agoWow - that must be an incredibly messy UI codebase by now ...
- ergo14 7y agoYou know, chrome UI is also web components in many places.
- mosselman 7y agoDo you mean that it is OK to have messy code as long as your competitors do too or do you mean that since chrome is doing it, it can't result in messy code?
- ergo14 7y agoI see no connection between WC's and messy code. Can bo good, can be bad.
- breatheoften 7y agoJust saying -- transitioning a large project from one component system to another -- while also developing/evolving the new component system ... I can just imagine it would be easy to build up a very large mess ...
- deleted 7y ago[deleted]
- emilsedgh 7y agoHonestly, how can a project of that magnitude _not_ be messy?
- BlackLotus89 7y agoDoes this mean the missing extension icons I got for a few days now are because of this? (I use nightly) or is this an uncorrelated bug and I now think that the rewrite is at fault because I combine unrelated information?
- dependenttypes 7y agoPeople seem to love laggy web-sights, let's port the lag into the browser's UI!
- daotoad 7y agoIt's not just the rendering that makes a website slow.
- saagarjha 7y agoThe web is not inherently slow.
- dependenttypes 7y agoThe modern web certainly is.
- 7y ago
- amelius 7y agoSecurity implications? Does this strip away a layer of security?
- BubRoss 7y agoWhy would there be security implications?
- capableweb 7y agoThere is always (most times) _some_ sort of security implications in most larger decisions we take when building software. Especially when receiving generally untrusted input from the internet (websites, extensions, web-workers in this case) and you're suppose to display/use that somehow.
- BubRoss 7y agoIn this case specifically though, what security problems do you think there might be?
- mcpherrinm 7y agoFirefox used to be built in a custom markup language called XUL, which had a number of security issues over the years as it got less attention than the HTML, etc used to render page contents. So this should help Firefox be more secure, by decreasing attack surface.
- ravenstine 7y agoPoor web components. Everybody rags on them.
- ng12 7y agoBecause the API is really ugly. I can't see them ever taking off except maybe as an implementation of another library with a cleaner API.
- cmpolis 7y agoThis is one of the goals of Polymer- a cleaner API/abstraction layer on top of web components, right?
- floatboth 7y agoWell, forget about "Polymer the library", it served us well but it's very legacy at this point. The successor is https://lit-element.polymer-project.org https://lit-element.polymer-project.org and it's awesome.
- interlocutor 7y agoWhy on earth do you need something that heavy? How about this 200-line lib instead: https://github.com/wisercoder/uibuilder https://github.com/wisercoder/uibuilder It lets you TSX format (same to React) to implement as well as to use web components.
- spankalee 7y ago> Unlike React.js UIBuilder does not do incremental screen updates LitElement + lit-html give you very efficient updates, and don't require non-standard JS like JSX.
- interlocutor 7y agolit-html is no more of a standard than JSX. In fact JSX is better because tools like VSCode is able to validate both HTML and embedded JavaScript.
- pfraze 7y agoIncidentally, so is Beaker browser's. We use lit-elements, which I like a lot.
- hunterloftis 7y agoI've also been enormously impressed with the design of lit-element, which carefully balances ease with simplicity. Just enough abstraction to automate the hard stuff without dictating your architecture.
- BoumTAC 7y agocan it cause perfomance issue ? I know for example the devtool is written in react and it's a lot slower than chrome devtools (I don't know how chrome devtool is written) and the javascript debugger is sometime not even usable because it's so slow.
- warpech 7y agoChrome DevTools use Web Components: https://github.com/ChromeDevTools/devtools-frontend https://github.com/ChromeDevTools/devtools-frontend
- saagarjha 7y agoI believe the developer consoles for all three major desktop browsers (Chrome, Firefox, and Safari) are written using web technologies.
- Touche 7y agoUsing web components or something else is only one small part of the performance question. They could be using both web components and React for all we know. They could be using any number of JavaScript libraries that could be harming performance. They could be using raw DOM manipulation which could be either very fast or somewhat slow depending on how well it was implemented. All we can say is that using JavaScript in general is slower than using C++ but they weren't using C++ before anyways.
- thayne 7y ago
- bryanh 7y agoJust peeking through the tracker history https://bugzilla.mozilla.org/show_bug.cgi?id=1397874 https://bugzilla.mozilla.org/show_bug.cgi?id=1397874 and you can see the effort it took to land this magnitude of a change -- pretty astounding. Big hat tip to Brian and the FF crew!
- potiuper 7y ago'There was also a case where a user with over 1500 tabs open (scientifically considered a “tab hoarder”)' - by what metric?
- gilrain 7y agoThat's the joke.
- chc 7y agoBy number of tabs open, it sounds like.
- potiuper 7y agoTo be a hoarder, one would need to accumulate the hoard over a period of time, which "the number of tabs open" is not a measure of. Also, as stated in the article, an issue with a large number of tabs was found, yet it was not declared that the tester(s) were also hoarders by the metric of the "number of tabs open".
- dudidu 7y agoThis is awesome!
- Hamuko 7y agoI'm waiting for Firefox to start using a native context menu on macOS instead of the garbage that they are now using and which doesn't behave anything like any other context menu on macOS. It's luckily on Bugzilla, so I can keep monitoring progress daily. https://bugzilla.mozilla.org/show_bug.cgi?id=34572 https://bugzilla.mozilla.org/show_bug.cgi?id=34572
- user_50123890 7y agoTicket opened 20 years ago, damn.
- ziftface 7y ago> i can't argue, but it's a time thing You have no idea
- 0-_-0 7y agoI remember the time when I never came across anything on the Internet that was older than 3 years
- michaelbazos 7y agoThat would be the first three years of the Internet.
- 0-_-0 7y agoI'm pretty sure it was after 1972 :P
- bashinator 7y agoWow, that predates OS X.
- aasasd 7y agoYup. > Does this bug affect OS X? If not, it should be WONTFIX. > It does affect Mac OS X.
- agumonkey 7y agoReminds me of the firefox.html protothingie someone showed a few years ago.
- sp332 7y agoBrowser.html, a Servo demo. https://github.com/browserhtml/browserhtml https://github.com/browserhtml/browserhtml
- paulrouget 7y agoLooked like this: http://paulrouget.com/bhtml/ http://paulrouget.com/bhtml/ but the project died.
- paulrouget 7y agoYeah. It never took off. Really wanted to have a Firefox clone in with Servo + HTML UI. It looked very neat: http://paulrouget.com/bhtml/ http://paulrouget.com/bhtml/
- jabl 7y agoJust like Servo never replaced Firefox outright, but components thereof were (and still are?) ported to Firefox, isn't this what effectively will happen eventually when they continue to get rid of XUL in favor of HTML?
- mosburger 7y agoI wrote an open-source cross platform app entirely in XUL + Javascript once and it was an awful experience - incredibly hard to debug and get all the bindings working right. Congrats to the Mozilla team on what has to be a very satisfying improvement!
- wooptoo 7y agoXUL was ahead of its time when it was introduced by Netscape/Mozilla many years ago. It was a capable XML based language used to describe rich graphical user interfaces. Together with XULRunner this was supposed to be a generic framework for creating graphical applications. This was long before HTML became what it is today. Back then people still thought Java would take off on the desktop. I believe that most Mozilla products such as the Mozilla suite, Thunderbird and Firefox used this for a very long time. https://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul https://www.mozilla.org/keymaster/gatekeeper/there.is.only.x...
- brailsafe 7y agoAn app I use called Zotero uses XUL, though I believe they're trying to transition to Electron. It seemed like a potentially robust platform, but damn if I couldn't figure how it worked enough to even contribute a minor fix.
- jabl 7y agoI think Zotero started out as a Firefox extension, and when Firefox deprecated those in favor of the new-style WebExtensions they saw the writing on the wall and converted it to a standalone XUL application. The same team behind Zotero has another newer application called tropy (https://tropy.org/ https://tropy.org/), which is based on Electron, and apparently they were happy with that and are indeed planning to transition Zotero to Electron as well.
- gnomewascool 7y ago> I think Zotero started out as a Firefox extension, and when Firefox deprecated those in favor of the new-style WebExtensions they saw the writing on the wall and converted it to a standalone XUL application. To add a bit more detail / a slight correction: Zotero did indeed start purely as a Firefox extension, but Zotero Standalone was released in 2011[0], far before the switch to WebExtensions. For a while, the Firefox extension and Zotero standalone were equally featured — i.e. you could use just the Firefox extension, or use Zotero standalone + the Chromium connector extension, and in both cases you'd get the same functionality. After the switch to WebExtensions, the Firefox extension was reduced to being purely a connector, just like the Chromium one. [0] https://en.wikipedia.org/wiki/Zotero#Zotero_Standalone https://en.wikipedia.org/wiki/Zotero#Zotero_Standalone
- matheist 7y agoI built a userChrome.js replacement [+] back when FF 57 came around, that uses an XBL loophole to permit users to add custom javascript to their profiles that would run in the browser context. I wanted to be able to use pre-OS X Lion fullscreen mode, and couldn't find any other way to do it. I'm a little bummed that this loophole is going away in FF 72 (I still can't get pre-Lion fullscreen!). On the other hand, it has always been super clear that this is a loophole that will eventually go away, and I did get 2 years of use out of it, so I'm not complaining too loudly. Congrats to the team for removing XBL! [+] https://github.com/nuchi/firefox-quantum-userchromejs https://github.com/nuchi/firefox-quantum-userchromejs
- girvo 7y agoIt’s been so long that I genuinely can’t remember what that full screen mode looked like! Do you have a screenshot by any chance?
- tomc1985 7y agoEveryone celebrates this, as if it were something worth celebrating. Yet all I see is another stake through the heart of desktop and native UI.
- marcosdumay 7y agoMost people don't like native desktop UIs. What is a shame, because we still didn't get something as nice to program for the web.
- tomc1985 7y agoMost people who? Under 25s?
- fnordsensei 7y agoOh boy, I've seen nothing to confirm this. /user researcher (etc.)
- Yoric 7y agoPersonally, I'm not a big fan of native UIs, so fine by me.
- tomc1985 7y agoNative UI has an austere, functional beauty that graphic-designer-infected web-native UI lacks Plus I don't need half a dozen chromium processes just to run it
- Yoric 7y ago> Native UI has an austere, functional beauty that graphic-designer-infected web-native UI lacks Let's just say that beauty is in the eye of the beholder :) > Plus I don't need half a dozen chromium processes just to run it Yeah, I'll grant you that. Native UI is mostly likely more memory and cpu efficient.
- spankalee 7y ago
- etse 7y agoI don't know if the move to web components somehow resulted in superior font rendering for Firefox on Mac, but I just checked version 71.0b11 and it looks great – at least as good as Safari. I just couldn't stand the blurry text, so now I'll give it a go and switch back to Firefox. Although, the colors look far more saturated than they should be, like the orange Hacker News navigation bar.
- ajxs 7y agoIsn't this the kind of thing we've been looking to move away from? I personally think that this modern trend of implementing, or even worse -porting-, important functionality in Javascript is very worrying. There was another recent controversial discussion of Electron on HN where I and many others shared our reservations about badly Electron apps perform overall. They're disproportionately resource intensive, shred battery life, hog resources etc. I don't think that deprecating XUL is a bad thing, but is moving to another JS based solution really a good idea? I've been a supporter of Firefox for a long time and intend to continue to do so. I tend to favor lightweight programs and while I want to continue to give FF my support, I'm concerned with how bloated and slow it's becoming.
- pault 7y agoThe problem with electron isn't JavaScript, it's running an entirely seperate instance of an infamously memory hogging web browser, that comes with an enormous amount of features that aren't utilized by the application. The JavaScript runtime itself is not going to cause noticable slowdowns or memory use, especially so if you already have one running anyway as is the case for Firefox.
- judge2020 7y agoThe Chrome "apps" feature is turning out pretty well for me when using it for YT Music and YT TV, it runs in the same process as the existing chrome tabs do, and you can have dedicated windows for them in Windows/MacOS.
- ajxs 7y ago> running an entirely seperate instance of an infamously memory hogging web browser Without looking at the source-code: Doesn't this problem still exist, just in a different form? You're still running some kind of browser instance to render the UI, rather than using native methods.
- pault 7y agoBut you're using the browser already!
- FpUser 7y agoBah, I was wondering why it suddenly feels less snappy. Generally I am against Electron and other web based UI layers. However since browser must have built in web GUI framework by definition it does make mush sense from the architectural and business standpoint to use the same thing for browser own GUI as well.
- gnomewascool 7y ago> Bah, I was wondering why it suddenly feels less snappy. Were you using Nightly? If not, then it's most probably unrelated.
- jhatax 7y agoHere’s my XUL development story: I built and managed (2009-2011) the XUL-based Elasticfox extension for Firefox that allowed users of EC2 to manage their compute resources on AWS. The extension pre-dated the AWS Console and introduced features such as resource tagging and search before they were part of the SDK. The extension wouldn’t have been possible without XUL. In fact, it isn’t possible today. MDN documentation was really great even in those days, as was the community which answered a number of my questions. I was doing something really new, especially with calling into EC2 APIs, background refreshes, using Prefs.js to save tag information, etc., and the community was really responsive and supportive of my work. Quirks aside, my experience with XUL was great. Users truly appreciated the extension over the Java-based CLI, and a number of ideas (mine or those from the community) eventually made their way into the AWS Console. I spent my last year at AWS working on the S3 Console using web technologies. I found XUL development to be easier than hacking CSS that year (circa 2010-11). Edit: Added a note up top that this is my XUL story.
- zem 7y agothat sounds like a massively satisfying project to be involved with!
- deleted 7y ago[deleted]
- johnpowell 7y agoI read the blog post and wasn't able to figure out if this would break userChrome.css. I'm not that weird about change and normally accept it and end up not caring. But I have tried to get used to tabs on top and it just isn't happening. If I can no longer have that I guess I will need to get used to Safari. Or I will just keep using Firefox and not update and accept the security implications.
- severine 7y agoI use Firefox Nightly and a couple of the latest updates broke my userChrome.css. On the other jand, it took me just minutes to fix, by asking in r/FirefoxCSS, where there are some kind and helpful CSS ninjas. Link: https://www.reddit.com/r/FirefoxCSS/ https://www.reddit.com/r/FirefoxCSS/
- musicale 7y agoAnd the FireFox UI still sucks. It's ugly and clunky. The look and feel is just off, and it isn't responsive. One of the reasons I prefer Safari on macOS is that it actually has a native Cocoa UI.
- cerberusss 7y agoYes, the Safari UI basically defines the look and feel for macOS. However Firefox has some advantages in other areas, like ad blocking.
- musicale 7y agoYeah, I appreciate Apple's attempts to sandbox content blockers for security and privacy reasons, but I still miss ublock origin.
- lloydatkinson 7y agoThat’s great and all but I’m still waiting on a spell checker. How can this still not be a thing?
- sho 7y ago> There was also a case where a user with over 1500 tabs open (scientifically considered a “tab hoarder”) noticed extreme slowness when opening the “all tabs” dropdown. It turned out that he had tripped on an O(N²) edge case, and the issue was fixed. Good god.I've seen some ridiculous tab collections but that is next level.
- afiori 7y agoI essentially use tabs as dynamic bookmarks; as a stack almost. I never use multiple windows in any browser because they are unreliable with tab reloading.
- axilmar 7y agoWas there a reason for XUL in the first place? Why wasn't Firefox built using some GUI library? I've read what the posted page said, and the comments in here, and the first results from Google don't give any reason why XUL was necessary. To me it seems many hundreds, if not thousand, man years spent on something totally unnecessary.