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.
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.
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.
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.
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.
Curious. Both LibreOffice and Firefox use Hunspell
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...
You have no idea
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.
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.
That's the stuff I've noticed in the couple of days I've been using Firefox.
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.
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!
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.
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.
To me it seems many hundreds, if not thousand, man years spent on something totally unnecessary.
Does this strip away a layer of security?
So this should help Firefox be more secure, by decreasing attack surface.
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.
/user researcher (etc.)
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.
