Live data from Hacker News

The Firefox UI Is Now Built with Web Components

briangrinstead.com

121–130 of 260 posts

Re: The Firefox UI Is Now Built with Web Components

#121
post #34

Earlier quoted context omitted.

This is one of the goals of Polymer- a cleaner API/abstraction layer on top of web components, right?

Well, 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 and it's awesome .

Why on earth do you need something that heavy? How about this 200-line lib instead: https://github.com/wisercoder/uibuilder It lets you TSX format (same to React) to implement as well as to use web components.

Re: The Firefox UI Is Now Built with Web Components

#122
post #88

Earlier quoted context omitted.

They don't close when you release right-click, they don't contain services, they don't select the word you are on. That's the stuff I've noticed in the couple of days I've been using Firefox.

One of the things that I use a lot that isn't on there is the "Look up" function/service to get the definitions of words from the dictionary, wiki, etc. Super useful and I miss it so much after switching from Safari.

If you hover the cursor over the word and hit command control d, you’ll get the definition in Firefox.

Re: The Firefox UI Is Now Built with Web Components

#123
post #98

Isn'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 b…

Unfortunately OS/WM/DE makers didn't provide a common API, so now web browsers are the "Lowest Common Denominator" for cross-platform apps.

Qt exists.

Re: The Firefox UI Is Now Built with Web Components

#124

Earlier quoted context omitted.

Well, 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 and it's awesome .

Why on earth do you need something that heavy? How about this 200-line lib instead: https://github.com/wisercoder/uibuilder It lets you TSX format (same to React) to implement as well as to use web components.

> 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.

Re: The Firefox UI Is Now Built with Web Components

#125
post #99

Bah, 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.

> Bah, I was wondering why it suddenly feels less snappy.

Were you using Nightly?

If not, then it's most probably unrelated.

Re: The Firefox UI Is Now Built with Web Components

#127

XUL 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…

Evergreen ILS used the heck out of this XULRunner

Re: The Firefox UI Is Now Built with Web Components

#128
post #98

Isn'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 b…

Unfortunately OS/WM/DE makers didn't provide a common API, so now web browsers are the "Lowest Common Denominator" for cross-platform apps.

There are a ton of cross-platform GUI libraries

Re: The Firefox UI Is Now Built with Web Components

#129
post #51

I'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

I see people (legitimately) complaining about the longstanding lack of support for Mac OS native widgets but personnally I'm equally annoyed with the new behavior of menus.

The standard of basically every OS is that hovering the pointer over an item opens a submenu (if there's one). In Firefox, I have to click, for instance to open "Help" in the burger menu. The sub-menu then appears by replacing the parent, instead of forming a cascade near it. It's non-standard and it's slower.

The only rationale I can see for it is avoiding complex mouse paths and accidental closing of menus for absolute beginners, but still. It's not like it's not an old, solved HCI problem (see question 8). https://www.asktog.com/columns/022DesignedToGiveFitts.html

Re: The Firefox UI Is Now Built with Web Components

#130
post #123

Earlier quoted context omitted.

Unfortunately OS/WM/DE makers didn't provide a common API, so now web browsers are the "Lowest Common Denominator" for cross-platform apps.

Qt exists.

I think Electron is popular because you can hire web devs to make a desktop product. With JS you can write code that runs on your server (NodeJS) desktop (Electron), browser and mobile app (Cordova). It's not a great experience but it is good for rapid development, easier hiring of skills (just need some web devs!) and the code reuse might be helpful for bug reduction.
Post reply on HN