The Firefox UI Is Now Built with Web Components

Post by interlocutor » Wed, Nov 20, 2019, 11:52 PM UTC

spankalee wrote: post #124

interlocutor wrote: post #121

Earlier quoted context omitted.

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.

Post by war1025 » Wed, Nov 20, 2019, 11:57 PM UTC

Lukas_Skywalker wrote: post #77

prima-facie wrote: post #62

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…

A bit of nostalgia: I created an application based on XULRunner at the end of high school. The project started out as a Firefox Extension, and since I wanted to create a standalone application, XULRunner was the obvious choice. I didn't know much programming, but it was, coupled with the excellent documentation on MDN, enough to get me started. What I remember best are the following few things: - XULRunner had an inc…

Post by dkonofalski » Thu, Nov 21, 2019, 12:00 AM UTC

jeremiahlee wrote: post #122

dkonofalski wrote: post #94

Earlier quoted context omitted.

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.

Post by ajxs » Thu, Nov 21, 2019, 12:13 AM UTC

pault wrote: post #103

ajxs wrote: 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…

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

Post by pault » Thu, Nov 21, 2019, 12:16 AM UTC

ajxs wrote: post #147

pault wrote: post #103

Earlier quoted context omitted.

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

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