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 products such as the Mozilla suite, Thunderbird and Firefox used this for a very long time.
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 included application update mechanism. You basically created a diff between two application versions and placed that on a server. XULRunner would automatically detect it and apply it. No configuration needed. This was huge.
- XULRunner obviously had a built-in browser. Using a few XML elements, you could embed a browser view.
- Porting from a Firefox extension to a standalone application was very easy. Add some boilerplate and you are done. Pretty much no need to change the application code.
- Since my application didn't include any native code, it was automatically cross platform. And it integrated beautifully into all platforms.
ticktockten 1607 days ago [-]
Cool, I actually used XULRunner for a cross-platform application!
The tooling was great, and it did set the precedent for what we expect today.
war1025 1607 days ago [-]
What was the application for? Just curious
Lukas_Skywalker 1607 days ago [-]
Music. You could search for music, and the application would search a few mp3 sites for the track and play it automatically. Also, if the built-in browser detected music files or links embedded in the page, a bar popped up from the bottom offering to play the music.
cr0sh 1607 days ago [-]
I recall playing with it, when I first heard about it: "You mean I can create a native-looking app that's actually browser-based?"...
This had to be sometime in the mid-late 1990s?
I recall the documentation about everything was "ok-ish" - enough for me to create a simple "app" and have it communicate with a "backend" using POST (IIRC) - nothing fancy, but I could tell it actually worked.
But at the time, I had to shelve it - and I was working with a VB6 application for my employer, and I mostly forgot about it. It was always in the back of my mind, though - and I knew that Firefox, Thunderbird, etc - still had support...
Today, it was just a legacy technology that never went anywhere, and it amazes me why it didn't. It's yet another example of something "ahead of its time"; it was frustrating to me back then as to why nobody was using it and making it better - especially when there was a "reference app suite" right there!
But no - we had to wait another decade or so for everyone else to "catch up" to the concept. Sigh.
marcosdumay 1607 days ago [-]
From my POV, it didn't catch on because:
- It had all the problems of Electron in a time where memory was a much more of an issue
- Low quality documentation that didn't go into the details (although it had a great overview)
- Performance problems due to the high abstraction level and bad JS interpreter
- Memory leaking that appeared on several versions and disappeared on other versions, that randomly affected people and nobody could explain
All those problems got corrected eventually, but by then it was too late.
eloisant 1606 days ago [-]
It didn't catch on because Mozilla never gave a shit about XULRunner, and they were clear about it.
In the late 2000's there were many companies who launched products based on XULRunner (Miro, Songbird, Joost, Tom-Tom...), but when they encountered bugs in the platform Mozilla's response was always "bug doesn't affect Firefox, we don't care". Even if you made a PR yourself (actually a patch at the time), good luck to get it merged if Firefox wasn't impacted.
Note that XULRunner was called this way but you didn't have to use XUL, you could use HTML for UI just like in Electron today.
If Mozilla saw the potential in their platform as a development platform for third party, it might still exist and have a bigger market share than Electron today. Maybe GitHub would have used it instead of developing electron, actually.
tracker1 1606 days ago [-]
I have to agree... I'd wanted to use it for a few things in the early 00's, but the support just seemed absent.
mathw 1607 days ago [-]
I remember trying to write something in it and the performance was atrocious, it used masses of memory and I hadn't even really done much. I wasn't anything like the developer I am now back then of course, I was an undergraduate CS student, but still... also yes, the documentation was awful! The experience for an Electron developer today is far superior with documentation, performance and all sorts so much better before you even start doing work on making it go fast.
I'll pause now for my regular appreciation of what the Visual Studio Code team have managed to do with Electron.
topspin 1607 days ago [-]
> 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. Doubtless there will be more in the future. Are we all sure Java failed on the Desktop? It certainly didn't wipe out the competing paradigms, but it's still here and still seems to work pretty well for a lot of people. There aren't any Java web browsers, but then there aren't any C# or Python web browsers either, so I'm not sure what unit of measure I'd need to observe the failure of Java desktop software.
And then there's Android......
jasode 1606 days ago [-]
>, 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 popular Java slogan back then of "write once, run anywhere"[1]. In other words, instead of writing desktop apps that specifically target the Win32 API, you write Java & Java byte code for the Java Virtual Machine. Instead of writing raw Javascript, code in Java to run as Java applets in the web browser. This was the same time period as the slogan "the network is the computer" that Oracle's Larry Ellison was also pushing. Both Sun and Oracle were trying to minimize Microsoft Windows' dominance with Java.
So yes, even though niche desktop software like JetBrains IDEs running on Java is a reality today, it is still somewhat of a failure when it's measured against the 1990s breathless promises.
It turns out that Java was much more successful on the server side. Ebay, Amazon, Google, etc all run tons of server-side Java. It is ironic that Javascript as the "toy" language to add a little dynamic interactivity to webpages over-achieved on the desktop while Java the "serious" language under-achieved its goals for the desktop.
> 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.
jasode 1606 days ago [-]
>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.
topspin 1606 days ago [-]
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.
mathw 1607 days ago [-]
Java succeeded massively on the desktop, just not in quite the way people expected. We now run software that's written in Java without really knowing it's written in Java, with native wrappers and suchlike. Turns out the way to succeed is to hide, maybe.
After all, how many people know something like Slack is written with a web browser engine and a massive pile of JavaScript?
slightwinder 1606 days ago [-]
> but then there aren't any C# or Python web browsers either
There are python-webbrowsers, like qutebrowser for example. Unless you mean 100% and purely written just in python.
brailsafe 1607 days ago [-]
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.
jabl 1607 days 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.
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 Electron as well.
gnomewascool 1607 days 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.
I built some personal desktop apps with XUL(Runner) ~ a decade ago, it was fun to use web technologies (markup, JS, CSS, web browser view with relaxed security etc) to create a cross-platform executable.
I have recently played with Electron and got the impression that it barely scratches the surface of what was possible back then but makes up for this thanks to the advancements in JS performance & ES6 syntax, CSS features (like flex, which was part of XUL) and the huge ecosystem of third party libraries.
bandrami 1607 days ago [-]
I learned Smalltalk in the 1980s as a middle school student. There was always the hope that Smalltalk would actually take off...
Ironically, the use of the browser as the target for programming has, slowly, haltingly, and through nearly-infinite compromises and kludges, actually provided the working platform Smalltalk promised us Gen-Xers when we dabbled in programming as kids. I think it's ultimately for the best, even if not the ideal path to have gotten there...
girvo 1607 days ago [-]
For years I used Komodo IDE, which is (was?) written using XUL — writing plugins for it was a breeze even though the docs were a little lacking, because JavaScript and XUL got me exploring easily. I miss that editor. Now everyone’s moving away from it. Ahead of its time indeed!
StanAngeloff 1607 days ago [-]
Ah, Komodo! I wrote a bunch of extensions for it [1][2][3] that got me started with XUL. I loved both. XUL always felt like every feature you can think of was available and thoroughly thought out, you just had to discover it (not always straightforward given how lacking the documentation was, especially for internal/private APIs). XUL was way ahead of its time.
And ultimately a huge waste of time. It set back Netscape and Firefox development for several years. Meanwhile IE6 took over, leading to the web dark ages while Mozilla reinvented the world.
For more details there is the famous Spolsky post about things you should never do—rewrite a product from scratch. Mozilla went one further and tried to reinvent GUI programming as well as building a new product.
asveikau 1607 days ago [-]
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.
mixmastamyk 1607 days ago [-]
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.
asveikau 1606 days ago [-]
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.
mixmastamyk 1604 days ago [-]
Yep, I used Communicator for many years. But it always drove me nuts that it couldn’t resize the window without redoing the whole page from scratch. The new Mozilla browser took years to stabilize. It was frustrating chapter for the web... the bad old days.
paulie_a 1607 days ago [-]
Sounds like a superior version of anything electron. I used apps built in it extensively and electron doesn't compare.
laktak 1607 days ago [-]
So is Thunderbird still using XUL or not?
rndgermandude 1607 days ago [-]
Yes and so is Firefox. So far they only removed XBL not XUL, and while they are slowly migrating things to HTML most of the UI is still XUL.
pas 1607 days ago [-]
If yes it's only a matter of time until it transitions away from it too.
baroffoos 1607 days ago [-]
Likely only because it doesn't see enough attention to be migrated.
chinathrow 1607 days ago [-]
I worked on an application based on XULRunner for a couple of years and I do miss it sometimes. The mixture of (in our case) C++ based XPCOM, mixed with JS and XPIDL fine to work with.
What I wonder thoug is whether that company was able to migrate of it already or not...
edoceo 1607 days ago [-]
Evergreen ILS used the heck out of this XULRunner
Hamuko 1607 days ago [-]
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.
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 on Mac or Windows that had a worse spell checker.
LibreOffice is open source and its spell checker is fine as far as I've seen--definitely way better than the one in Firefox--so that if Mozilla for some reason needs to have the same spell check on each OS and so can't use the native MacOS one, they could still bring it up to par by copying from LibreOffice.
Groxx 1607 days ago [-]
>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.
fwiw Chrome does this too. It's effectively standard practice for browsers - OSes routinely have very out-of-date cert stores, and don't regularly remove revoked ones. Browsers ship it separately because it's such a major security concern for browsing.
tzs 1607 days ago [-]
Chrome on MacOS does use the Mac's built-in system. Going to the privacy settings (chrome://settings/privacy), and clicking "Manage certificates" just launches the MacOS "Keychain Access" application.
To get Chrome on MacOS to use my employer's self-signed root certificate, I just had to import it with "Keychain Access" and then both Chrome and Safari used it.
It may also have its own built-in certificate system, but for user-added certificates, it uses the built in MacOS system.
jve 1606 days ago [-]
On Windows, Chrome uses actually uses windows certificate store.
As for Firefox (on Windows), there is a setting called "security.enterprise_roots.enabled" in about:Config which you can enable or push via GPO.
No - Chrome uses the OS certificate store on both Windows and MacOS and hence works with all internal apps of enterprises that generate client certificates for their users and manage the OS certificate using strict policies.
Firefox does not.
pilif 1607 days ago [-]
> LibreOffice is open source and its spell checker is fine as far as I've seen
Curious. Both LibreOffice and Firefox use Hunspell
aembleton 1607 days ago [-]
and Chrome according to [1]. I guess LibreOffice has a more comprehensive dictionary.
Which is great when it works. But Romanian (my language) is not supported by Apple (even tough they sell quite many things here).
In fact this is a good example of a dysfunctional company. Apple managed to translate to Romanian most of their help docs but they can't provide a basic spell checker.
Mikhail_Edoshin 1607 days ago [-]
Python doesn't use Mac OS X certificates either. E.g the popular 'requests' package carries its own root certificates bundle (extracted from Mozilla, I believe). I haven't investigated this in details but it has something to do with the version of OpenSSL that comes with Mac OS X.
IanSanders 1606 days ago [-]
>It has its own certificate system
And it's great. If you're running it portable on another machine you don't have to trust its certificates
tracker1 1606 days ago [-]
On the plus side, at least it allows for newer releases to move ahead of deprecated OS versions... it's a mixed bag.
marcthe12 1607 days ago [-]
Web browser have a massive NIH issues.
FullyFunctional 1607 days ago [-]
Hardly surprising for such a massive cross platform project. Catering to the particularities of each platform wastes a lot of effort. I personally really appreciate that Firefox works (mostly) the same on all the platforms I use.
kqr 1607 days ago [-]
Web browsers have practically become operating systems these days. I'm fully expecting someone to create a web browser web app at some point. Not as a joke, which has obviously been done before.
cerberusss 1606 days ago [-]
What I don't like, is that it keeps the tab close button on the right. I fix it with a bit of code in UserChrome.css but it'd be great if they would stick a bit closer to the platform. To be fair, except for obviously Safari, most other browsers do the same.
saint-loup 1607 days ago [-]
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
lucideer 1606 days ago [-]
On the click-vs-hover issue, I actually very much like Firefox's approach, and wish it were more widely used.
W.r.t. it being an "old, solved HCI problem", it isn't. The link you post actually posits positioning solutions to problems inherent to the hover approach. It doesn't discuss hover-vs-click at all, and while these positioning strategies still apply to some degree with the click approach, the problems they solve are much less severe there (namely, the submenu doesn't disappear if the user takes the wrong cursor route to a submenu item).
user_50123890 1607 days ago [-]
Ticket opened 20 years ago, damn.
steveklabnik 1607 days ago [-]
There was a very old ticket that was closed recently when a component was re-written in Rust. I can't find a link right this second, but if you could have told the future, it's kinda amusing. "Sorry, we'll fix this, but first we have to invent a new programming language. We'll get back to you in a decade."
Frankly, I think it's pretty amazing that bugs this old end up getting fixed. Not many projects live even live that long, let alone keep up their infrastructure...
hnick 1607 days ago [-]
> Frankly, I think it's pretty amazing that bugs this old end up getting fixed. Not many projects live even live that long, let alone keep up their infrastructure...
Our internal dev team has changed their feedback/requirements system 3 times in the last few years.
Motion without moving...
majewsky 1606 days ago [-]
I once fixed a bug in Kolf (the KDE mini-golf game) which was about the ball glitching through walls if you hit them in the right angle. The patch that fixed the issue was rather huge, since I ripped out the home-grown collision detection and replaced it with a standard 2D physics library.
Sadly, my patch broke some custom levels which relied on the glitch. https://xkcd.com/1172/ is more true than you'd expect.
0-_-0 1607 days ago [-]
I remember the time when I never came across anything on the Internet that was older than 3 years
michaelbazos 1607 days ago [-]
That would be the first three years of the Internet.
0-_-0 1607 days ago [-]
I'm pretty sure it was after 1972 :P
ziftface 1607 days ago [-]
> i can't argue, but it's a time thing
You have no idea
bashinator 1607 days ago [-]
Wow, that predates OS X.
aasasd 1607 days ago [-]
Yup.
> Does this bug affect OS X? If not, it should be WONTFIX.
> It does affect Mac OS X.
ziftface 1607 days ago [-]
I couldn't agree more. Firefox is the only browser I use on the desktop, and I do think it's the best. But the lack of native context menus is annoying.
Also, other native features are missing. Like the rubber banding and pinch to zoom, although that one works okay if you switch the config entry.
brailsafe 1607 days ago [-]
This was posted not only before OSX, but before Firefox. This was just Mozilla.
pier25 1607 days ago [-]
Not only context menus, any type of alert is garbage.
icedchai 1607 days ago [-]
So what would a native context menu actually do for me?
Hamuko 1607 days ago [-]
Allow the context menu to close when releasing right-click outside the menu for example. There's a ticket for that as well.
Services is one which annoys me a lot. I have a few around text edition and formatting, not having them in firefox is quite inconvenient.
catalogia 1607 days ago [-]
In which ways is the Firefox context menu "garbage"? How does it behave differently?
I never even noticed that it's not native until I read your comment, and looking carefully at it now the only difference I can notice is the corners are square (and that is certainly nothing worth complaining about.)
Maybe I'm just an oblivious idiot, but it sure seems to me that a lot of MacOS users on HN love to blow trivial matters completely out of proportion. Application lags for a split second? "Utter garbage, the developers should be shot, I'm going back to Safari." Where is the perspective? If there is something glaringly broken about these context menus, by all means correct me. But to my eye they look damn close to native and they seem to work perfectly fine.
zapzupnz 1607 days ago [-]
> it sure seems to me that a lot of MacOS users on HN love to blow trivial matters completely out of proportion
Don't be so dismissive. Apart from anything, that breaks one of the HN guidelines for discussion.
Not having access to built-in and user-defined (Applescript/Automator) Services is not trivial; these are a powerful part of what makes macOS unique and a major reason why I continue to use macOS. Their lack of availability is entire down to using faked-up menus rather than proper widgets.
Having widgets behave improperly is also an accessibility issue. There are multiple accessibility APIs built into the system that practically every macOS app built using Cocoa or Carbon hook into automatically; apps that use non-native widgets that don't take enough care to (a) perfectly emulate the behaviour of native widgets or (b) sufficient expose themselves to the built-in accessibility APIs not only make for an unexpectedly unpleasant experience but also potentially are showstopping for people with disabilities.
> But to my eye they look damn close to native and they seem to work perfectly fine
In other words, it's not a problem for you, so it shouldn't be a problem for anybody else.
catalogia 1607 days ago [-]
> Not having access to built-in and user-defined (Applescript/Automator) Services is not trivial
It's under the Firefox menu. I use it frequently to trigger an Automator service for TTS, which pipes the text through a sed script to fix common mispronunciations. I use this stuff too.
Should it be in the right click menu? Yes. Is firefox crippled by it's absence? No, because that functionality still exists, just in a different location (and if you have your services bound to keyboard shortcuts it becomes a complete non-issue.)
I stand by what I said. I'm not being unreasonably dismissive. Many mac users on this forum in particular have a habit of blowing the slightest defect completely out of proportion. Maybe they're trying to emulate Steve Jobs' infamously toxic approach to critique. Calling firefox "garbage" because of defects these minor is a prime example.
JumpCrisscross 1607 days ago [-]
> Is firefox crippled by it's absence?
I’ve used Firefox since Chrome started threatening to block ad blockers. I have stopped recommending it.
This specific bug confused the hell out of not only my parents, but also multiple nieces and nephews in their teens. (They thought it crashes.) These age groups both spend most of their time on mobile. When a desktop app behaves unusually, it’s a massive burden.
Not fixing these bugs seems to be a cultural problem at Mozilla, albeit one that’s getting better.
catalogia 1607 days ago [-]
Both of your parents and multiple teenagers thought firefox was crashing because Services wasn't in the right-click menu?
Forgive me for being incredulous, but what are they using it for? While I use Services, I'm not under the impression that it's particularly common. Perhaps Mozilla haven't prioritized the matter because they, like myself, are wrong about that? (And maybe calling Firefox garbage isn't the best way to correct their cultural blindspot?)
Hamuko 1607 days ago [-]
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.
dkonofalski 1607 days ago [-]
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.
jeremiahlee 1607 days ago [-]
If you hover the cursor over the word and hit command control d, you’ll get the definition in Firefox.
dkonofalski 1607 days ago [-]
That's helpful. Thanks. Would still like for it to be in the context menu, though, but this will do in a pinch.
jhatax 1607 days ago [-]
Another trick if you have the new "Magic" trackpads: Select the word, place three fingers on the pad, press down (force press), and you can see the definition of the selected word (will be highlighted in yellow).
mweibel 1606 days ago [-]
Only one finger needed
catalogia 1607 days ago [-]
As I expected, petty bullshit. Firefox should do those things if other applications do and it's reasonable to say as much, but to say that it's "garbage" for those reasons is completely out of proportion.
Edit: Response to response:
Didn't I just say that Firefox should conform to the standards of the platform? Failure to do so might be severe, or it might be petty, in either case it should be fixed. In this instance the examples given are definitely petty, and they should still be fixed.
But to call it "garbage" is borderline offensive and definitely out of proportion.
> "removing OS functionality"
That is a very hyperbolic characterization of the cited issues.
Hamuko 1607 days ago [-]
Being inconsistent with the operating system and removing OS functionality is petty bullshit? Okay then.
albru123 1607 days ago [-]
How is that removing if it wasn't there in the first place (AFAIK)?
saagarjha 1607 days ago [-]
Here's one: try right clicking and dragging out. Firefox's menu will open and stay open.
jhatax 1607 days ago [-]
Here’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.
ajxs 1607 days ago [-]
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 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 1607 days ago [-]
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.
judge2020 1607 days ago [-]
The 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 1607 days 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 1607 days ago [-]
But you're using the browser already!
ShinTakuya 1606 days ago [-]
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.
Narishma 1606 days ago [-]
I don't see how. Those libraries are already loaded anyway because they're used by the OS and native apps.
bgrins 1607 days ago [-]
There are pros and cons to using web tech for the application UI. To be clear, the old XBL code was already using JS/DOM, so the most obvious pro in this case was that it didn't require completely rewriting Firefox from scratch (which hasn't historically worked out well). I also expect that dogfooding web technologies means we can improve the tooling and web standard implementations in Gecko.
Regarding performance, this work didn't regress anything. Performance is measured on every commit and staying at least at parity was a requirement for the project.
hutzlibu 1607 days ago [-]
But with firefox, you intend to use HTML and JS in the first place.
I doubt that the cost to also render the firefox UI is significantly higher that having it native.
sixplusone 1607 days ago [-]
Unfortunately OS/WM/DE makers didn't provide a common API, so now web browsers are the "Lowest Common Denominator" for cross-platform apps.
FussyZeus 1607 days ago [-]
This is an odd offshoot issue that comes I think from the larger movement towards web-based applications and hosted "services" replacing bespoke desktop apps.
I have to say I feel a bit old hearing developers say "well why didn't the OS developers provide common APIs for creating applications?" which in my mind, is asking why Toyota Corollas and Ford F-150's don't use the same engine. The answer being they were two entire universes, and still are to a great degree.
That being said, while it is desirable to have standard API endpoints that are accessible, and while standards in general are a Good Thing(tm) to have, it does get a bit tiresome to hear different companies like Spotify[1], especially of that scale, bemoaning that they simply "must" use frameworks like Electron to build their applications because developing for individual platforms is just too expensive. If you want your application available on multiple platforms, and you want it to be a good experience to use, then you should be developing bespoke applications for them. That's just... logic, to me.
Yeah, it's more work. But to take a crap ton of web-content, shove it in a .app file and distribute that is massively wasteful, lazy, and results in what that kind of effort typically nets: bad experiences.
For example: I absolutely LOVE the Atom editor. It's a fantastic tool to use. That said I've had to give it up because it was simply killing my Mac's performance, a brand new, 2019, 15" Macbook Pro would sit there spinning it's fans up whenever it was on the screen, for a text editor. A feature rich text editor to be sure, but this thing can play 4K movies without even running the fans. A text editor should not strain it. I can't help but feel Electron is playing a role here.
[1]: I have no idea if Spotify uses Electron. I just know they've complained about this before.
sixplusone 1607 days ago [-]
>why Toyota Corollas and Ford F-150's don't use the same engine
Yeah, they're now a weaker (browser) engine bolted on with adapters to the gui engine. Everyone gets to go through the js bottleneck.
FussyZeus 1607 days ago [-]
To continue the metaphor, it's like every car has the same crappy transmission.
HeWhoLurksLate 1607 days ago [-]
More like Electron adds its own crappy transmission to whatever you had already
twgrp 1607 days ago [-]
Qt exists.
mc3 1607 days ago [-]
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.
ajxs 1607 days ago [-]
> you can hire web devs to make a desktop product
This is a bug, not a feature.
buboard 1607 days ago [-]
Its also slow and bloated. You get what you pay for
pmoleri 1607 days ago [-]
Bloated, yes. Slow, no. You start at a not so low binary size and memory footprint, but that's it. VS Code is an awesome IDE built on electron and it's really snappy.
weberc2 1607 days ago [-]
VS Code has not been snappy for me. Especially with large screen sizes and lots of widegets. For example, if I close the left-hand pane and shrink the window, performance improves considerably.
mc3 1606 days ago [-]
Not nearly as snappy as notepad++/sublime, which are in turn not as snappy as Vim.
skunkpocalypse 1607 days ago [-]
For C++ and Python only.
And those Python bindings are laboriously backported by hand from the C++ API.
QT will never be a language-independent toolkit, and the world will always need one of those.
buboard 1607 days ago [-]
There are a ton of cross-platform GUI libraries
st1ck 1605 days ago [-]
Last time I checked (a year ago), only Qt supported all 5 major native platorms: Linux/Mac/Windows and Android/iOS. Maybe also React Native, if you count [1] (Qt backend) or [2] (libui). Now it looks like Flutter started to support desktop recently. And that's it, I think.
As someone who loves the idea of a good cross platform GUI, there simply aren’t any. GTK and Qt are the closest, and GTK is garbage. Qt is awful, but manageable. You get to work in a bastardized dialect of C++ (that no editors understand save Qt Creator) or use a leaky Python binding (that still segfaults), but you can build things that don’t look awful. As far as I know, this is the only cross platform GUI tool for which this can be said (except for the browser-based solutions, of course).
jcelerier 1606 days ago [-]
> You get to work in a bastardized dialect of C++ (that no editors understand save Qt Creator)
Qt's "dialect" is just C++ - the signals:, slots:, emit etc... things are just plain preprocessor macros which resolve to nothing (https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kerne...). If your editor does not support resolving empty macros it does not support C++ at all anyways.
weberc2 1606 days ago [-]
This misses my point. If I create a language and assign different semantics to the Python AST, an editor that supports Python does not meaningfully support my language. The syntax highlighting will work, but any semantic analysis will break.
That's what you get with Qt absent the moc (meta object compiler).
Moreover, there is still a host of reasons why Qt is a painful developer experience (even though it is probably the best cross platform native option). For example, even if you solve the editor problem, you can't reliably use C++ templates, and Qt has its own strings, lists, hashmaps, concurrency mechanisms, memory model, etc. And even if it were just C++, C++ itself is a pretty poor experience compared to other languages on the market these days.
So Qt might be the best thing on the market today, but it's not hard to imagine much better alternatives. For example, browser support for native system things that would render electron obsolete (especially as WASM matures) or perhaps Flutter as its desktop story matures. Or maybe even a mature intermediate GUI toolkit in a modern language.
jcelerier 1606 days ago [-]
> 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.
weberc2 1606 days ago [-]
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.
jcelerier 1606 days ago [-]
> 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.
weberc2 1606 days ago [-]
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.
jcelerier 1606 days ago [-]
> 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.
If that was the case, gcc and clang would not be able to build Qt files. Yet the following compiles without issues :
No, it just means that Qt is valid C++, not that the two have equivalent semantics (which is necessary for Qt to be exactly C++ and not a bastardized version thereof, which is what we are debating). If I we’re wrong and you were right, the moc would be purely optional; it would serve no purpose, and Qt programs compiled with moc would behave exactly as those compiled without.
sixplusone 1607 days ago [-]
But this is part of the problem. I should have said "provide standard API" above. These libs aren't standard.
ajxs 1607 days ago [-]
I don't think that really excuses the use of Electron. Cross-platform GUI frameworks like Qt/GTK+ already exist to resolve this issue. This problem was already solved before Electron came around. All Electron did was lower the bar.
marmada 1607 days ago [-]
Is js actually slow? I thought with all the money invested in it, JS was one of the fastest dynamic languages out there.
bryanh 1607 days ago [-]
Just peeking through the tracker history 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!
matheist 1607 days ago [-]
I 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!
It’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?
matheist 1607 days ago [-]
The content stretches all the way to the top of the screen. No menu bar, no tab bar, no toolbars.
abyssin 1606 days ago [-]
This is the only feature I miss from Chrome on OSX.
pfraze 1607 days ago [-]
Incidentally, so is Beaker browser's. We use lit-elements, which I like a lot.
hunterloftis 1607 days ago [-]
I'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.
sho 1606 days 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 1606 days ago [-]
I 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.
BoumTAC 1607 days ago [-]
can 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.
jasonlaster11 1607 days ago [-]
Hi, Firefox DevTools Debugger engineer here.
We've focused on performance and quality over the past six months and believe it should be much better.
If you're still seeing issues, feel free to record a performance profile and send it to us:
I find it mildly amusing that there's a profiler in the devtools. And yet there is another profiler that is at times more powerful than it. I have used the gecko profiler from time to time to identify which feature the page was using that slowed down the entire browser. Multi-process means just debugging a single tab doesn't give you the whole picture.
skunkpocalypse 1607 days ago [-]
Profilers profiling profilers. Because why Do It Right The First Time when you can slap another layer onto the stack?
everybodyknows 1606 days ago [-]
To any other devs who like me who want to use Firefox Debugger, but were driven back to the devil Chromium by need for consistent, seamless copy-paste and select-middlemouse interaction: Give 70.0.1 a try. Much, much better. So much that I've dropped Chromium. (Ubuntu 18.04)
alexkoeh 1606 days ago [-]
Is it possible for Cmd+P to work when you don't have the Debugger tab in focus? That one of the few things I miss from Chrome dev tools.
Performance-wise it's been running great for me. The hard work you've put into this definitely shows.
abacadaba 1607 days ago [-]
ty for the effort! this is pretty much what has kept me developing chrome first.
Using 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.
chrome devtools are also written in javascript (although I'm not sure which framework if any they use). You can even debug the chrome devtools with chrome devtools (I think the same applies to firefox, although I've never accidentally gotten into that state like I have in chrome).
the8472 1607 days ago [-]
about:config -> devtools.chrome.enabled = true
then you should have additional entries in the tools -> web developer menu.
saagarjha 1607 days ago [-]
I believe the developer consoles for all three major desktop browsers (Chrome, Firefox, and Safari) are written using web technologies.
floatboth 1607 days ago [-]
Yes. In fact, "Safari devtools" are really a part of upstream WebKit. You get them in e.g. Epiphany (GNOME Web) too.
saagarjha 1607 days ago [-]
Yup, I'm aware and use the on GNOME Web too. It's fun to point the web inspector at itself :)
kart23 1607 days ago [-]
Really? I prefer the firefox devtools over chrome. They're pretty similar though.
ravenstine 1607 days ago [-]
Poor web components. Everybody rags on them.
ng12 1607 days ago [-]
Because 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.
ergo14 1607 days ago [-]
You are correct, they are pretty low level. You want something like lit-element or stencil (or vue, svelte... etc) on top of them for a pleasant experience.
On one hand it looks neat. This is something i expected browsers to be able to do since i noticed that Mozilla (pre-Firefox) implemented <blink> (or <marquee>?) in JavaScript.
On the other hand it looks like it'll become much harder for JavaScript-less environments to extract data from web-pages as now an article on a news site could be something like <news-article id="23848923"> and the JavaScript side will do the rest.
But being able to do something like <my-fancy-button caption="Go To Google" target="http://google.com/"> that in the background creates all the canvases and such needed will be neat.
Asooka 1606 days ago [-]
>On the other hand it looks like it'll become much harder for JavaScript-less environments to extract data from web-pages as now an article on a news site could be something like <news-article id="23848923"> and the JavaScript side will do the rest.
This is already the case on a lot of sites, just not standardized. With the standard you could sandbox the javascript or maybe implement specific parsing for the most common web components.
madmulita 1606 days ago [-]
Oh, wait for webassembly, that's gonna be fun.
jlengrand 1607 days ago [-]
Which is exactly the point :). So good news!
cmpolis 1607 days ago [-]
This is one of the goals of Polymer- a cleaner API/abstraction layer on top of web components, right?
floatboth 1607 days ago [-]
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.
interlocutor 1607 days ago [-]
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.
spankalee 1607 days 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 1607 days ago [-]
lit-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.
spankalee 1607 days ago [-]
Huh? lit-html uses standard JavaScript. That's it. JSX is a non-standard extension. So yes it is more standard than a non-standard, and lit-html runs directly in browsers without any transpilation while JSX very much doesn't.
VS Code is as able to analyze lit-html templates as well as JSX via the lit-plugin extensions. It gives you type-checking, code completion, hover-over docs, and linting.
Yes, JSX needs transpilation but that happens at compile-time. Which is better, pre-processing at compile-time, or "transpilation" (i.e., string processing) at run-time?
spankalee 1607 days ago [-]
UIBuilder doesn't do incremental updates at all. You might as well use innerHTML and template literals. That's a 0-line library :)
interlocutor 1607 days ago [-]
Updates offered by lit-html appear to be very limited. If you change value of expressions it updates the DOM. What about larger changes, such as list items changing? What about child elements being replaced with new ones?
update() simply iterates through each part and value (the parts array and values array are always the same length) and calls part.setvalue(v) for each part.
Behind the scenes lit-html creates HTML <template> elements from your JavaScript templates and processes them so that it knows exactly where to insert and update the values from expressions.
This is very limited. You need to manually update DOM unless your updates are simple changes in values of expressions.
spankalee 1606 days ago [-]
It is very correct: lit-html is amongst the fastest template systems in use right now. This is shown in every benchmark I've seen or made for it.
lit-html updates only the parts of DOM that are dynamic and change. It handles nested templates as values, only updating the whole nested template if the template itself changes, otherwise recursing and only updating that template's values if needed. Repeated DOM is handled either by simply updating state for each item in sequence (non-keyed), or by using the repeat() directive which will move DOM (keyed).
You absolutely don't need to manually update DOM. The whole point is to describe your DOM structure as a function of data, and to be to describe all the conditional / repeated parts in the template expression itself.
1607 days ago [-]
petilon 1607 days ago [-]
OK, so plugins can enhance code editing. But what about compile-time checks? With TSX, if you have a mis-matched tag the TypeScript compiler will give you an error.
spankalee 1607 days ago [-]
Same with lit-html and the TypeScript compiler plugin.
So we finally got a goddamn proper standard and we're already cheering for the next API to throw in front of it to make it "cleaner"?
floatboth 1607 days ago [-]
Actually, no. There's no need or possibility to make it "cleaner", but there's always the direction of making it more "high level". These are very different things.
The platform APIs are not opinionated about templating, they just provide proper mechanisms for declaring elements and having isolated DOM subtrees. It makes sense to leave templating to libraries, because… well, good luck on getting even just two people to agree about how templating should be done :)
fourthark 1607 days ago [-]
Yeah - I do not understand the snark on this thread. This is great news.
sujNansnam 1607 days ago [-]
It’s one of those things where you’re only going to notice it as a user when it’s broken.
saagarjha 1607 days ago [-]
There's nothing inherently wrong with web components. People rag on them when they aren't used correctly, and this is apparently hard to do.
mosburger 1607 days ago [-]
I 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!
etse 1607 days ago [-]
I 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.
johnpowell 1607 days ago [-]
I 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 1605 days ago [-]
I 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.
Does 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?
konart 1607 days ago [-]
I don't think it's related. They were removing XBL piece by piece for a quite some time now. /r/firefox has many mosts about such removals.
Anyway - nightly is a dev build. It is expected to have bugs of all kinds.
jshap70 1607 days ago [-]
I think so, but that issue was fixed w/in a few days
agumonkey 1607 days ago [-]
Reminds me of the firefox.html protothingie someone showed a few years ago.
Yeah. It never took off. Really wanted to have a Firefox clone in with Servo + HTML UI. It looked very neat: http://paulrouget.com/bhtml/
jabl 1607 days ago [-]
Just 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?
1607 days ago [-]
axilmar 1606 days ago [-]
Was 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.
zem 1607 days ago [-]
that sounds like a massively satisfying project to be involved with!
dudidu 1607 days ago [-]
This is awesome!
kick 1607 days ago [-]
Remember when a tab freezing didn't make Firefox's UI chrome unresponsive? I do, too.
floatboth 1607 days ago [-]
I remember when it did — before the "Electrolysis" project, when everything ran in one process. This was quite a long time ago already.
skrebbel 1607 days ago [-]
I'd assume that the Firefox chrome runs in its own process. Why would the switch to web components for the chrome change that?
amelius 1607 days ago [-]
Every tab's UI (and the main UI) can still run in a different thread or process, I suppose ...
MikusR 1607 days ago [-]
When was that?
pessimizer 1607 days ago [-]
Web 4.0 is the internet of race conditions. Thanks, javascript everywhere.
hombre_fatal 1607 days ago [-]
I don't get it. Javascript would have categorically improved on this compared to more traditional multi-threaded solutions.
GrayShade 1607 days ago [-]
You can still have race conditions in single-threaded async code.
cjones26 1607 days ago [-]
Well 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 1607 days ago [-]
Why 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 1607 days ago [-]
And “Javascript would have categorically improved on this compared to more traditional multi-threaded solutions” remains true nevertheless.
cjones26 1607 days ago [-]
What? JavaScript is a single threaded language...
Yoric 1607 days ago [-]
And 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.
lloydatkinson 1607 days ago [-]
That’s great and all but I’m still waiting on a spell checker. How can this still not be a thing?
amelius 1607 days ago [-]
Security implications?
Does this strip away a layer of security?
mcpherrinm 1607 days ago [-]
Firefox 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.
noja 1607 days ago [-]
But XUL was simpler, wasn't it?
pcwalton 1607 days ago [-]
Maybe marginally so in isolation? But that isn't the metric that matters, since a browser has to render HTML. HTML + XUL is more complex than just HTML.
floatboth 1607 days ago [-]
The article talks about XBL (the binding part of XUL?):
> There are hard to debug complications with binding lifecycles in our UI, and very few people know how it works.
> It adds enormous complexity to our platform in the frame constructor, style system, and the DOM implementation.
pfraze 1607 days ago [-]
When you control the webview, you can establish fairly strong limits on where content and code can come from, same as with CSPs. Injection into the context really shouldn't be possible. You'd need to hit some kind of exploit such as an image-parsing buffer overflow, which any other frontend technology would be vulnerable to. Given that web tech gets a lot of attention to avoid those kinds of exploits, I think web platform UIs might be the safer call.
BubRoss 1607 days ago [-]
Why would there be security implications?
capableweb 1607 days ago [-]
There 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 1607 days ago [-]
In this case specifically though, what security problems do you think there might be?
musicale 1607 days ago [-]
And 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 1606 days ago [-]
Yes, the Safari UI basically defines the look and feel for macOS. However Firefox has some advantages in other areas, like ad blocking.
musicale 1605 days ago [-]
Yeah, I appreciate Apple's attempts to sandbox content blockers for security and privacy reasons, but I still miss ublock origin.
breatheoften 1607 days ago [-]
Wow - that must be an incredibly messy UI codebase by now ...
emilsedgh 1607 days ago [-]
Honestly, how can a project of that magnitude _not_ be messy?
ergo14 1607 days ago [-]
You know, chrome UI is also web components in many places.
mosselman 1607 days ago [-]
Do 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 1607 days ago [-]
I see no connection between WC's and messy code. Can bo good, can be bad.
breatheoften 1607 days ago [-]
Just 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 ...
1606 days ago [-]
tomc1985 1607 days ago [-]
Everyone celebrates this, as if it were something worth celebrating. Yet all I see is another stake through the heart of desktop and native UI.
spankalee 1607 days ago [-]
You don't think XBL was more native than HTML do you?
tomc1985 1607 days ago [-]
It was. It rendered to GTK which renders to native widgetry
paulrouget 1607 days ago [-]
Not more native than HTML.
tomc1985 1606 days ago [-]
Sure, when people didn't style buttons or text boxes, because those also used native widgets
the8472 1607 days ago [-]
it used native widgets
paulrouget 1607 days ago [-]
No. XBL was not "using" widgets. XBL is a binding language.
marcosdumay 1607 days ago [-]
Most 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.
fnordsensei 1606 days ago [-]
Oh boy, I've seen nothing to confirm this.
/user researcher (etc.)
tomc1985 1607 days ago [-]
Most people who? Under 25s?
Yoric 1607 days ago [-]
Personally, I'm not a big fan of native UIs, so fine by me.
tomc1985 1607 days ago [-]
Native 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 1606 days 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.
FpUser 1607 days ago [-]
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.
gnomewascool 1607 days ago [-]
> Bah, I was wondering why it suddenly feels less snappy.
Were you using Nightly?
If not, then it's most probably unrelated.
potiuper 1607 days ago [-]
'There was also a case where a user with over 1500 tabs open (scientifically considered a “tab hoarder”)' - by what metric?
chc 1607 days ago [-]
By number of tabs open, it sounds like.
potiuper 1603 days ago [-]
To 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".
gilrain 1607 days ago [-]
That's the joke.
dependenttypes 1607 days ago [-]
People seem to love laggy web-sights, let's port the lag into the browser's UI!
mintplant 1607 days ago [-]
Firefox has always been built with DOM, JS, CSS technologies, as the linked article calls out. This change replaces a large proprietary extension, XBL, with a standard equivalent.
dependenttypes 1607 days ago [-]
Calling XBL a proprietary is weird when considering that it is published by w3c and that firefox is FOSS.
> Firefox has always been built with DOM, JS, CSS technologies, as the linked article calls out
I am aware of that (and imo, it was a mistake). That however does not mean that moving to more web-y stuff will not make the performance any worse.
> XBL is a proprietary technology developed by Mozilla. We are solely responsible for the maintenance and improvement of XBL. Any time spent on doing this doesn’t contribute to the evolution of the Web so effectively we don’t spend anytime improving XBL except for plugging serious holes.
What they mean is they 'own' it, the good, the tedious and the bad parts.
saagarjha 1607 days ago [-]
The web is not inherently slow.
dependenttypes 1607 days ago [-]
The modern web certainly is.
saagarjha 1607 days ago [-]
It's not. You just have to care.
anoncake 1607 days ago [-]
No, the developers of the web pages you use have to care.
saagarjha 1607 days ago [-]
Yes, that's what I meant by "you". But if you want to take a more active role in improving the web, you're free to interpret that "you" as actually referring to you.
anoncake 1606 days ago [-]
But ultimately you can't get everyone to care. That's why the web will always be slow.
hunterloftis 1607 days ago [-]
"web-sights"
daotoad 1607 days ago [-]
It's not just the rendering that makes a website slow.
Rendered at 21:15:35 GMT+0000 (Coordinated Universal Time) with Vercel.
https://www.mozilla.org/keymaster/gatekeeper/there.is.only.x...
- XULRunner had an included application update mechanism. You basically created a diff between two application versions and placed that on a server. XULRunner would automatically detect it and apply it. No configuration needed. This was huge.
- XULRunner obviously had a built-in browser. Using a few XML elements, you could embed a browser view.
- Porting from a Firefox extension to a standalone application was very easy. Add some boilerplate and you are done. Pretty much no need to change the application code.
- Since my application didn't include any native code, it was automatically cross platform. And it integrated beautifully into all platforms.
The tooling was great, and it did set the precedent for what we expect today.
This had to be sometime in the mid-late 1990s?
I recall the documentation about everything was "ok-ish" - enough for me to create a simple "app" and have it communicate with a "backend" using POST (IIRC) - nothing fancy, but I could tell it actually worked.
But at the time, I had to shelve it - and I was working with a VB6 application for my employer, and I mostly forgot about it. It was always in the back of my mind, though - and I knew that Firefox, Thunderbird, etc - still had support...
Today, it was just a legacy technology that never went anywhere, and it amazes me why it didn't. It's yet another example of something "ahead of its time"; it was frustrating to me back then as to why nobody was using it and making it better - especially when there was a "reference app suite" right there!
But no - we had to wait another decade or so for everyone else to "catch up" to the concept. Sigh.
- It had all the problems of Electron in a time where memory was a much more of an issue
- Low quality documentation that didn't go into the details (although it had a great overview)
- Performance problems due to the high abstraction level and bad JS interpreter
- Memory leaking that appeared on several versions and disappeared on other versions, that randomly affected people and nobody could explain
All those problems got corrected eventually, but by then it was too late.
In the late 2000's there were many companies who launched products based on XULRunner (Miro, Songbird, Joost, Tom-Tom...), but when they encountered bugs in the platform Mozilla's response was always "bug doesn't affect Firefox, we don't care". Even if you made a PR yourself (actually a patch at the time), good luck to get it merged if Firefox wasn't impacted.
Note that XULRunner was called this way but you didn't have to use XUL, you could use HTML for UI just like in Electron today.
If Mozilla saw the potential in their platform as a development platform for third party, it might still exist and have a bigger market share than Electron today. Maybe GitHub would have used it instead of developing electron, actually.
I'll pause now for my regular appreciation of what the Visual Studio Code team have managed to do with Electron.
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. Doubtless there will be more in the future. Are we all sure Java failed on the Desktop? It certainly didn't wipe out the competing paradigms, but it's still here and still seems to work pretty well for a lot of people. There aren't any Java web browsers, but then there aren't any C# or Python web browsers either, so I'm not sure what unit of measure I'd need to observe the failure of Java desktop software.
And then there's Android......
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 popular Java slogan back then of "write once, run anywhere"[1]. In other words, instead of writing desktop apps that specifically target the Win32 API, you write Java & Java byte code for the Java Virtual Machine. Instead of writing raw Javascript, code in Java to run as Java applets in the web browser. This was the same time period as the slogan "the network is the computer" that Oracle's Larry Ellison was also pushing. Both Sun and Oracle were trying to minimize Microsoft Windows' dominance with Java.
So yes, even though niche desktop software like JetBrains IDEs running on Java is a reality today, it is still somewhat of a failure when it's measured against the 1990s breathless promises.
It turns out that Java was much more successful on the server side. Ebay, Amazon, Google, etc all run tons of server-side Java. It is ironic that Javascript as the "toy" language to add a little dynamic interactivity to webpages over-achieved on the desktop while Java the "serious" language under-achieved its goals for the desktop.
[1] https://en.wikipedia.org/wiki/Write_once,_run_anywhere
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.
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.
After all, how many people know something like Slack is written with a web browser engine and a massive pile of JavaScript?
There are python-webbrowsers, like qutebrowser for example. Unless you mean 100% and purely written just in python.
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 Electron as well.
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
Ironically, the use of the browser as the target for programming has, slowly, haltingly, and through nearly-infinite compromises and kludges, actually provided the working platform Smalltalk promised us Gen-Xers when we dabbled in programming as kids. I think it's ultimately for the best, even if not the ideal path to have gotten there...
[1] https://github.com/StanAngeloff/komodo-html-toolkit [2] https://github.com/StanAngeloff/komodo-fuzzy-open [3] https://github.com/StanAngeloff/komodo-aero-theme
For more details there is the famous Spolsky post about things you should never do—rewrite a product from scratch. Mozilla went one further and tried to reinvent GUI programming as well as building a new product.
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.
What I wonder thoug is whether that company was able to migrate of it already or not...
It's luckily on Bugzilla, so I can keep monitoring progress daily.
https://bugzilla.mozilla.org/show_bug.cgi?id=34572
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 on Mac or Windows that had a worse spell checker.
LibreOffice is open source and its spell checker is fine as far as I've seen--definitely way better than the one in Firefox--so that if Mozilla for some reason needs to have the same spell check on each OS and so can't use the native MacOS one, they could still bring it up to par by copying from LibreOffice.
fwiw Chrome does this too. It's effectively standard practice for browsers - OSes routinely have very out-of-date cert stores, and don't regularly remove revoked ones. Browsers ship it separately because it's such a major security concern for browsing.
To get Chrome on MacOS to use my employer's self-signed root certificate, I just had to import it with "Keychain Access" and then both Chrome and Safari used it.
It may also have its own built-in certificate system, but for user-added certificates, it uses the built in MacOS system.
As for Firefox (on Windows), there is a setting called "security.enterprise_roots.enabled" in about:Config which you can enable or push via GPO.
From docs it appears it works on Mac too: https://support.mozilla.org/en-US/kb/setting-certificate-aut...
Firefox does not.
Curious. Both LibreOffice and Firefox use Hunspell
1. https://hunspell.github.io/
Which is great when it works. But Romanian (my language) is not supported by Apple (even tough they sell quite many things here).
In fact this is a good example of a dysfunctional company. Apple managed to translate to Romanian most of their help docs but they can't provide a basic spell checker.
And it's great. If you're running it portable on another machine you don't have to trust its certificates
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
W.r.t. it being an "old, solved HCI problem", it isn't. The link you post actually posits positioning solutions to problems inherent to the hover approach. It doesn't discuss hover-vs-click at all, and while these positioning strategies still apply to some degree with the click approach, the problems they solve are much less severe there (namely, the submenu doesn't disappear if the user takes the wrong cursor route to a submenu item).
Frankly, I think it's pretty amazing that bugs this old end up getting fixed. Not many projects live even live that long, let alone keep up their infrastructure...
Our internal dev team has changed their feedback/requirements system 3 times in the last few years.
Motion without moving...
Sadly, my patch broke some custom levels which relied on the glitch. https://xkcd.com/1172/ is more true than you'd expect.
You have no idea
> Does this bug affect OS X? If not, it should be WONTFIX.
> It does affect Mac OS X.
Also, other native features are missing. Like the rubber banding and pinch to zoom, although that one works okay if you switch the config entry.
https://bugzilla.mozilla.org/show_bug.cgi?id=101472
I never even noticed that it's not native until I read your comment, and looking carefully at it now the only difference I can notice is the corners are square (and that is certainly nothing worth complaining about.)
Maybe I'm just an oblivious idiot, but it sure seems to me that a lot of MacOS users on HN love to blow trivial matters completely out of proportion. Application lags for a split second? "Utter garbage, the developers should be shot, I'm going back to Safari." Where is the perspective? If there is something glaringly broken about these context menus, by all means correct me. But to my eye they look damn close to native and they seem to work perfectly fine.
Don't be so dismissive. Apart from anything, that breaks one of the HN guidelines for discussion.
Not having access to built-in and user-defined (Applescript/Automator) Services is not trivial; these are a powerful part of what makes macOS unique and a major reason why I continue to use macOS. Their lack of availability is entire down to using faked-up menus rather than proper widgets.
Having widgets behave improperly is also an accessibility issue. There are multiple accessibility APIs built into the system that practically every macOS app built using Cocoa or Carbon hook into automatically; apps that use non-native widgets that don't take enough care to (a) perfectly emulate the behaviour of native widgets or (b) sufficient expose themselves to the built-in accessibility APIs not only make for an unexpectedly unpleasant experience but also potentially are showstopping for people with disabilities.
> But to my eye they look damn close to native and they seem to work perfectly fine
In other words, it's not a problem for you, so it shouldn't be a problem for anybody else.
It's under the Firefox menu. I use it frequently to trigger an Automator service for TTS, which pipes the text through a sed script to fix common mispronunciations. I use this stuff too.
Should it be in the right click menu? Yes. Is firefox crippled by it's absence? No, because that functionality still exists, just in a different location (and if you have your services bound to keyboard shortcuts it becomes a complete non-issue.)
I stand by what I said. I'm not being unreasonably dismissive. Many mac users on this forum in particular have a habit of blowing the slightest defect completely out of proportion. Maybe they're trying to emulate Steve Jobs' infamously toxic approach to critique. Calling firefox "garbage" because of defects these minor is a prime example.
I’ve used Firefox since Chrome started threatening to block ad blockers. I have stopped recommending it.
This specific bug confused the hell out of not only my parents, but also multiple nieces and nephews in their teens. (They thought it crashes.) These age groups both spend most of their time on mobile. When a desktop app behaves unusually, it’s a massive burden.
Not fixing these bugs seems to be a cultural problem at Mozilla, albeit one that’s getting better.
Forgive me for being incredulous, but what are they using it for? While I use Services, I'm not under the impression that it's particularly common. Perhaps Mozilla haven't prioritized the matter because they, like myself, are wrong about that? (And maybe calling Firefox garbage isn't the best way to correct their cultural blindspot?)
That's the stuff I've noticed in the couple of days I've been using Firefox.
Edit: Response to response:
Didn't I just say that Firefox should conform to the standards of the platform? Failure to do so might be severe, or it might be petty, in either case it should be fixed. In this instance the examples given are definitely petty, and they should still be fixed.
But to call it "garbage" is borderline offensive and definitely out of proportion.
> "removing OS functionality"
That is a very hyperbolic characterization of the cited issues.
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.
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.
Regarding performance, this work didn't regress anything. Performance is measured on every commit and staying at least at parity was a requirement for the project.
I have to say I feel a bit old hearing developers say "well why didn't the OS developers provide common APIs for creating applications?" which in my mind, is asking why Toyota Corollas and Ford F-150's don't use the same engine. The answer being they were two entire universes, and still are to a great degree.
That being said, while it is desirable to have standard API endpoints that are accessible, and while standards in general are a Good Thing(tm) to have, it does get a bit tiresome to hear different companies like Spotify[1], especially of that scale, bemoaning that they simply "must" use frameworks like Electron to build their applications because developing for individual platforms is just too expensive. If you want your application available on multiple platforms, and you want it to be a good experience to use, then you should be developing bespoke applications for them. That's just... logic, to me.
Yeah, it's more work. But to take a crap ton of web-content, shove it in a .app file and distribute that is massively wasteful, lazy, and results in what that kind of effort typically nets: bad experiences.
For example: I absolutely LOVE the Atom editor. It's a fantastic tool to use. That said I've had to give it up because it was simply killing my Mac's performance, a brand new, 2019, 15" Macbook Pro would sit there spinning it's fans up whenever it was on the screen, for a text editor. A feature rich text editor to be sure, but this thing can play 4K movies without even running the fans. A text editor should not strain it. I can't help but feel Electron is playing a role here.
[1]: I have no idea if Spotify uses Electron. I just know they've complained about this before.
Yeah, they're now a weaker (browser) engine bolted on with adapters to the gui engine. Everyone gets to go through the js bottleneck.
This is a bug, not a feature.
And those Python bindings are laboriously backported by hand from the C++ API.
QT will never be a language-independent toolkit, and the world will always need one of those.
[1]: https://github.com/status-im/react-native-desktop [2]: https://github.com/kusti8/proton-native
Qt's "dialect" is just C++ - the signals:, slots:, emit etc... things are just plain preprocessor macros which resolve to nothing (https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kerne...). If your editor does not support resolving empty macros it does not support C++ at all anyways.
That's what you get with Qt absent the moc (meta object compiler).
Moreover, there is still a host of reasons why Qt is a painful developer experience (even though it is probably the best cross platform native option). For example, even if you solve the editor problem, you can't reliably use C++ templates, and Qt has its own strings, lists, hashmaps, concurrency mechanisms, memory model, etc. And even if it were just C++, C++ itself is a pretty poor experience compared to other languages on the market these days.
So Qt might be the best thing on the market today, but it's not hard to imagine much better alternatives. For example, browser support for native system things that would render electron obsolete (especially as WASM matures) or perhaps Flutter as its desktop story matures. Or maybe even a mature intermediate GUI toolkit in a modern language.
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.
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.
> 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.
If that was the case, gcc and clang would not be able to build Qt files. Yet the following compiles without issues :
which is all that is needed to ensure that some code is indeed 100% valid C++ code - that it is idiomatic is a wholly different question.hell, you can even generate the signals code without moc if you are ok with more macros (https://github.com/woboq/verdigris)
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
Just enough abstraction to automate the hard stuff without dictating your architecture.
Good god.I've seen some ridiculous tab collections but that is next level.
I never use multiple windows in any browser because they are unreliable with tab reloading.
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.
We've focused on performance and quality over the past six months and believe it should be much better.
If you're still seeing issues, feel free to record a performance profile and send it to us:
- https://profiler.firefox.com/ - https://bugzilla.mozilla.org/enter_bug.cgi?product=DevTools&...
I'd be happy to fix it!
Performance-wise it's been running great for me. The hard work you've put into this definitely shows.
https://github.com/ChromeDevTools/devtools-frontend/blob/mas...
then you should have additional entries in the tools -> web developer menu.
On one hand it looks neat. This is something i expected browsers to be able to do since i noticed that Mozilla (pre-Firefox) implemented <blink> (or <marquee>?) in JavaScript.
On the other hand it looks like it'll become much harder for JavaScript-less environments to extract data from web-pages as now an article on a news site could be something like <news-article id="23848923"> and the JavaScript side will do the rest.
But being able to do something like <my-fancy-button caption="Go To Google" target="http://google.com/"> that in the background creates all the canvases and such needed will be neat.
This is already the case on a lot of sites, just not standardized. With the standard you could sandbox the javascript or maybe implement specific parsing for the most common web components.
LitElement + lit-html give you very efficient updates, and don't require non-standard JS like JSX.
VS Code is as able to analyze lit-html templates as well as JSX via the lit-plugin extensions. It gives you type-checking, code completion, hover-over docs, and linting.
Yes, JSX needs transpilation but that happens at compile-time. Which is better, pre-processing at compile-time, or "transpilation" (i.e., string processing) at run-time?
https://github.com/Polymer/lit-html/wiki/How-it-Works#4-upda...
Excerpt:
update() simply iterates through each part and value (the parts array and values array are always the same length) and calls part.setvalue(v) for each part.
https://lit-html.polymer-project.org/guide
Excerpt:
Behind the scenes lit-html creates HTML <template> elements from your JavaScript templates and processes them so that it knows exactly where to insert and update the values from expressions.
This is very limited. You need to manually update DOM unless your updates are simple changes in values of expressions.
lit-html updates only the parts of DOM that are dynamic and change. It handles nested templates as values, only updating the whole nested template if the template itself changes, otherwise recursing and only updating that template's values if needed. Repeated DOM is handled either by simply updating state for each item in sequence (non-keyed), or by using the repeat() directive which will move DOM (keyed).
You absolutely don't need to manually update DOM. The whole point is to describe your DOM structure as a function of data, and to be to describe all the conditional / repeated parts in the template expression itself.
Where is the plug-in that does compile-time checks of HTML tags and attributes?
This is the tsc plugin: https://www.npmjs.com/package/ts-lit-plugin
If you look at https://lit-element.polymer-project.org — it's just a base class that integrates declarative DOM templates.
The platform APIs are not opinionated about templating, they just provide proper mechanisms for declaring elements and having isolated DOM subtrees. It makes sense to leave templating to libraries, because… well, good luck on getting even just two people to agree about how templating should be done :)
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.
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.
Link: https://www.reddit.com/r/FirefoxCSS/
Anyway - nightly is a dev build. It is expected to have bugs of all kinds.
To me it seems many hundreds, if not thousand, man years spent on something totally unnecessary.
Note the difference between race conditions in general and data races that involve unsynchronized access to shared memory.
Does this strip away a layer of security?
So this should help Firefox be more secure, by decreasing attack surface.
> There are hard to debug complications with binding lifecycles in our UI, and very few people know how it works.
> It adds enormous complexity to our platform in the frame constructor, style system, and the DOM implementation.
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.
One of the reasons I prefer Safari on macOS is that it actually has a native Cocoa UI.
I can just imagine it would be easy to build up a very large mess ...
/user researcher (etc.)
Plus I don't need half a dozen chromium processes just to run it
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.
Were you using Nightly?
If not, then it's most probably unrelated.
> Firefox has always been built with DOM, JS, CSS technologies, as the linked article calls out
I am aware of that (and imo, it was a mistake). That however does not mean that moving to more web-y stuff will not make the performance any worse.
https://mozilla.github.io/firefox-browser-architecture/text/... says:
> XBL is a proprietary technology developed by Mozilla. We are solely responsible for the maintenance and improvement of XBL. Any time spent on doing this doesn’t contribute to the evolution of the Web so effectively we don’t spend anytime improving XBL except for plugging serious holes.
What they mean is they 'own' it, the good, the tedious and the bad parts.