Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Firefox UI Is Now Built with Web Components

briangrinstead.com

Post reply on HN
Print view View original

241–250 of 260 posts

Re: The Firefox UI Is Now Built with Web Components

#241

Post by topspin »

jasode wrote: post #226
topspin wrote: post #186

Earlier quoted context omitted.

> Back then people still thought Java would take off on the desktop. You know, I find myself using a substantial amount of Java desktop software. I license JetBrains products and earn part of my living using them. DBeaver is another frequently used tool. I've spent no small amount of time in Minecraft (the Java implementation.) Java desktop software even pops up in hobbies; SimSmith is one example. There are others.…

>, so I'm not sure what unit of measure I'd need to observe the failure of Java desktop software. When people say "Java failed on the desktop", it's in relation to the initial massive hype in 1995 by Sun Microsystems as the "Microsoft evil empire killer". Microsoft took the desktop threat seriously and quickly reacted in 1996 with a Java-clone called the J++ language -- which resulted in Sun's lawsuit. There was a po…

> Microsoft took the desktop threat seriously and quickly reacted in 1996 with a Java-clone called the J++ language -- which resulted in Sun's lawsuit.

I'm fully aware of the history. I was there and watched it unfold at the time. I also don't think it's terribly relevant; 1995 was a quarter century ago. Sun is dead. I'm just objectively counting the number of Java desktop programs I presently use and wondering if this supposed "failure" on the desktop isn't really just a widespread misconception. The software that I cited isn't riding the coattails of a 24 year old marketing campaign; they thrive of their own merit.

Re: The Firefox UI Is Now Built with Web Components

#242

Post by tracker1 »

tzs wrote: post #156
Hamuko wrote: 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

There are a couple of other non-native things Firefox does that annoy me. 1. It has its own certificate system. That would be fine if it used that in addition to using the MacOS built in system, but it seems to use it exclusively. 2. It has its own spell checker, which is orders of magnitude worse than the one provided by the native MacOS spell check API. I can't think of any program I've used in the last few years o…

On the plus side, at least it allows for newer releases to move ahead of deprecated OS versions... it's a mixed bag.

Re: The Firefox UI Is Now Built with Web Components

#243

Post by jcelerier »

weberc2 wrote: post #238
jcelerier wrote: post #236

Earlier quoted context omitted.

> This misses my point. If I create a language and assign different semantics to the Python AST, but which semantic differences are you talking about ? It is plain C++. Function calls are function calls, the only difference being that some are auto-generated and some are your own code.

C++ has no notion of signals and slots or other metaobject utilities. Your editor cannot autocomplete those signals/slots like Qt Creator. Anyway, I encourage you to not get too hung up on this particular issue with Qt and consequently miss the broader point.

> Your editor cannot autocomplete those signals/slots like Qt Creator.

what do you mean ? signals and slots are just plain functions, there is no magic to understand ; the only thing that QtCreator does is to display a different icon in the autocompletion toolbox.

Do you have an example of an IDE that is not able to autocomplete a signal ? VS is able to, vscode is able to, Xcode is able to, code::blocks is able to, hell even notepad++ in all its "non-intelligence" manages to.

> Anyway, I encourage you to not get too hung up on this particular issue with Qt and consequently miss the broader point.

I am saying that this point does not make sense - else every library which has some concept not perfectly transmitted by raw C++ code (for instance : a library function whose correct execution / lack of UB depends on the programmer calling another function before that) would be problematic.

Re: The Firefox UI Is Now Built with Web Components

#244

Post by tomc1985 »

paulrouget wrote: post #199
tomc1985 wrote: post #164

Earlier quoted context omitted.

It was. It rendered to GTK which renders to native widgetry

Not more native than HTML.

Sure, when people didn't style buttons or text boxes, because those also used native widgets

Re: The Firefox UI Is Now Built with Web Components

#245

Post by Narishma »

ShinTakuya wrote: post #235
ajxs wrote: post #147

Earlier quoted context omitted.

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

Yes, but this is the UI of a browser. Arguably it could be more efficient to do it this way as you can strip out some of the libraries used for the native rendering.

I don't see how. Those libraries are already loaded anyway because they're used by the OS and native apps.

Re: The Firefox UI Is Now Built with Web Components

#246

Post by weberc2 »

jcelerier wrote: post #243
weberc2 wrote: post #238

Earlier quoted context omitted.

C++ has no notion of signals and slots or other metaobject utilities. Your editor cannot autocomplete those signals/slots like Qt Creator. Anyway, I encourage you to not get too hung up on this particular issue with Qt and consequently miss the broader point.

> Your editor cannot autocomplete those signals/slots like Qt Creator. what do you mean ? signals and slots are just plain functions, there is no magic to understand ; the only thing that QtCreator does is to display a different icon in the autocompletion toolbox. Do you have an example of an IDE that is not able to autocomplete a signal ? VS is able to, vscode is able to, Xcode is able to, code::blocks is able to, h…

Signals and slots compile into plain C++ functions. The input language (the unnamed Qt superset of C++) has a notion of signals and slots, the output language (C++) does not have any such notion.

> I am saying that this point does not make sense - else every library which has some concept not perfectly transmitted by raw C++ code (for instance : a library function whose correct execution / lack of UB depends on the programmer calling another function before that) would be problematic.

My point does make sense, you're just missing it.

First of all, my point is that Qt is a poor developer experience--that its interface is bastardized is merely evidence. Further, even if it were not bastardized, it would still be awful because it's C++ (insane build tooling, no package management, poor error messaging, no memory safety, enormous feature matrix, etc etc etc; all of this has been covered elsewhere ad nauseum, no need to repeat those arguments here). There's a long tail of additional issues with Qt that contribute to its unpleasantness, but there's no point in diving into them here.

Secondly, your stateful library functions example doesn't fit my criticism because stateful functions are part of the C++ language spec while signals and slots are not.

Re: The Firefox UI Is Now Built with Web Components

#247

Post by asveikau »

mixmastamyk wrote: post #189
asveikau wrote: post #176

Earlier quoted context omitted.

It's famous that Mozilla and Firefox went through many rewrites and stalled progress. But I don't think you can blame that for IE6. Some amount of that is due to the Windows monopoly and that it was preinstalled.

The blame is not for the monopoly exactly. Rather the reason IE dev stagnated for five years. With no competition and WWI over, MS retired the team.

Right, so, in that period, IE stagnated, and so did Mozilla. But IE was the dominant stagnant browser and not Mozilla or Firefox. That's somewhat on the monopoly.

In much of those days I used Netscape 4.x and it really wasn't much worse than IE. Then I used pre-1.0 Mozilla and various forks, and early firefox, they were all pretty acceptable for the time. The big issue was that all the content was authored for IE and not tested anywhere else. Monopoly.

Re: The Firefox UI Is Now Built with Web Components

#248

Post by jasode »

topspin wrote: post #241
jasode wrote: post #226

Earlier quoted context omitted.

>, so I'm not sure what unit of measure I'd need to observe the failure of Java desktop software. When people say "Java failed on the desktop", it's in relation to the initial massive hype in 1995 by Sun Microsystems as the "Microsoft evil empire killer". Microsoft took the desktop threat seriously and quickly reacted in 1996 with a Java-clone called the J++ language -- which resulted in Sun's lawsuit. There was a po…

> Microsoft took the desktop threat seriously and quickly reacted in 1996 with a Java-clone called the J++ language -- which resulted in Sun's lawsuit. I'm fully aware of the history. I was there and watched it unfold at the time. I also don't think it's terribly relevant; 1995 was a quarter century ago. Sun is dead. I'm just objectively counting the number of Java desktop programs I presently use and wondering if th…

>I also don't think it's terribly relevant; 1995 was a quarter century ago.

It's relevant because the context of the conversation was this gp's quote you responded to: "Back then people still thought Java would take off on the desktop."

The "back then" is referencing XUL circa ~1997. And the "Java would take off" was the ambitious idea of most desktop apps being written in Java to weaken the MS Windows ecosystem. Not only was Java hyped to be a Microsoft killer, it was also touted to be a C/C++ killer. (E.g. the idea was that computer desktops have gotten so powerful with so many wasted cpu cycles that manual memory of C/C++ is obsolete and letting GC use the excess cpu to automatically manage memory is the future.) History has now shown us that prediction didn't happen either. C/C++ is still heavily used for new desktop apps. That's a different idea than today's 2019 landscape with some niche Java apps like Jetbrains IDEs.

I do understand your point. Yes, you can also have an alternative definition of "not a failure on desktop " because you can count some current Java apps today. That's also a valid perspective. However, for the sake of not confusing the conversation... that's not what the gp was originally talking about. I don't think there's any misconception about what "Java failed on the desktop" means -- especially among the HN audience. I also regularly use Jetbrains IDEA for Android deveopment and Webstorm for Javascript but my usage of those Java apps doesn't change what "Java failed on the desktop" means to other people.

Re: The Firefox UI Is Now Built with Web Components

#249

Post by brailsafe »

jabl wrote: post #204
brailsafe wrote: post #66

Earlier quoted context omitted.

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

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. The same team behind Zotero has another newer application called tropy ( https://tropy.org/ ), which is based on Electron, and apparently they were happy with that and are indeed planning to transition Zotero to…

Neat. Hadn't heard of Tropy

Re: The Firefox UI Is Now Built with Web Components

#250

Post by topspin »

jasode wrote: post #248
topspin wrote: post #241

Earlier quoted context omitted.

> Microsoft took the desktop threat seriously and quickly reacted in 1996 with a Java-clone called the J++ language -- which resulted in Sun's lawsuit. I'm fully aware of the history. I was there and watched it unfold at the time. I also don't think it's terribly relevant; 1995 was a quarter century ago. Sun is dead. I'm just objectively counting the number of Java desktop programs I presently use and wondering if th…

>I also don't think it's terribly relevant; 1995 was a quarter century ago. It's relevant because the context of the conversation was this gp's quote you responded to: "Back then people still thought Java would take off on the desktop." The "back then" is referencing XUL circa ~1997. And the "Java would take off" was the ambitious idea of most desktop apps being written in Java to weaken the MS Windows ecosystem. Not…

Yes, I moved the goal posts making my point. I believe the storied history of Java clouds the contemporary reality of Java too much, to the point where one can argue Java "failed on the desktop" specifically among people that spend a good fraction of their waking hours using Java desktop software, and I appear to be one of the few that notices this irony.
Post reply on HN