It exists for Android, but not desktop (judging by a number of dead links, it looks like it used to exist for desktop).
(or s/Gecko/Servo/ if desired)
You also kinda have to fork Firefox to do this. It would be good to be able to #include <gecko-embedded-framework.h> and build the UI from there. XULRunner seemed nice too.
Using Gecko when you are not Firefox is such a pain that
- all alternative browsers that are not forks of Firefox that were based on Gecko have abandoned: they stopped being maintained, or switched to WebKit or Blink, which is a shame.
- all apps based on XUL / Gecko, like Songbird, have mostly disappeared.
It needs to be easier.
Gecko seems like a drag for Thunderbird. It shouldn't. For this, it needs to be a proper toolkit, with stability guarantees, and proper support to third party apps, and easily reusable. That's not the focus for Firefox devs though.
[1] https://fosdem.org/2024/schedule/event/fosdem-2024-2728-thun...
Which browsers? Pale Moon, Basilisk, K-Meleon are still being developed.
Is Goanna on part with web standards? Maintaining what seems basically a folk of an old Gecko must be hard.
It also kinda validates my point: using Gecko elsewhere is a PITA. You have to work hard to make it embeddable.
To answer your question, Gnome Web / Epiphany was once based to Gecko. It switched to WebKit because using Gecko was harder and harder. Konqueror optionally allowed you to use Gecko, but that stopped being possible a long time ago for the same reason. Galeon and Camino both died a long time ago.
Brave, Vivaldi & Co picked Chromium instead of Gecko. With Eich coming from Mozilla, I think Brave considered Gecko but that was deemed too hard.
This browser-in-a-box cancer needs to die a painful death.
That's the future you want to see, huh?
Have you developed a cross-platform desktop application in the last few years and make sure everything works on every platform? Probably not. If there is a way to make it easy, cheap, reliable to support multiple platforms and the solution takes little system resources, I'm sure everyone will want to do that. Before that happens, stop your wasting complaining about the Electorn mode of making apps. This will not change. It is the only thing that makes business sense and make developers' life easy at this time.
Or to put it simply, are you going to pay for the extra cost used for developing "native" applications for each platform? Put your money where your mouth is.
If anything, it's easier to develop cross-platform native applications these days, since the mobile space has mostly collapsed to just Android + iOS.
Would it be possible that the average Joe is more familiar with a web stack vs a native or cross platform desktop stack?
Is it not possible that the difference therefore might be between:
- having a questionably performing app built on web technologies
- vs a buggy one that's built on a native/cross-platform stack, or even not having one altogether because they can't build with that tech
- having a questionably performing app built on web technologies
- having an awesome native/cross-platform app that runs better and respects the OS design
It's the same how something like Rust might be a good fit for writing correct web applications, but very few people actually use it for that and might instead reach for something like Python because that lets them iterate faster, even if neither the type system, nor the performance is great.
Actually, who knows, maybe the problem is not that there's not enough "good software" out there, but rather that different people have wildly different views on what matters, in addition to there just being too much software in general.
Skype on Linux, for one, keeps the microphone open after a call, forever.
The issue has been known for more than 2 years.
I'd say Electron adds no value with respect to fighting bugs other than containing the consequences in the browser sandbox.
My notion is that more people are familiar with using the web stack, than any other alternative.
Out of curiosity, I perused some local job boards: out of about 50 technical role ads that I looked through, 4 were embedded or desktop development, there were some DevOps and ML related roles in the middle, but the majority were web development.
If that's the set of technologies and the languages that people are familiar with (high abstraction level, no manual memory management), then attempting to use these "performant" options obviously wouldn't turn out well, due to a lack of skill, familiarity and/or user experience of that tooling.
I mean, in an ideal world, GUI software would be even easier to create than using Lazarus was back in the day (the RAD approach), but sadly the greatness that was lcl is mostly lost to time because nobody cares: https://en.wikipedia.org/wiki/Lazarus_Component_Library
Yes it might be cheaper and easier to make a car out of wood but it will drive like crap.
Using tools not made for the job yields crappy results, who would have known.
Depends on what the goals are. If they are to take people from the job market that currently exists (lots of webdevs) and build software that is good enough and ship it to earn $$$, then clearly they've succeeded, no matter how much people complain about the inefficiencies or how suboptimal the tools might be considered.
This too, shall pass. The minimum amount of memory for a double buffered fullscreen surface at 8bpc on a 4k monitor is 48MB. RAM is meant to be used, and if it was not for memory hogs, the DRAM industry would be a decade behind where it is today.
Some of us have to run other programs besides Teams. /s
Sure, and when applications hog it, it prevents me from putting it to better use.
Hell even Wine is more efficient an approach for cross-platform distribution.
Aaand you lost most companies.
> Hell even Wine is more efficient an approach for cross-platform distribution.
I'm sure that customers will be willing to install and run Wine.
Yes it takes a bit more than a boot camp graduate to code that, and might take a bit more time still.
Your solution requires more dev time and skill - which makes it way more expensive. Basic economics.
The main requirement most devs and users have for an app - that it runs and works reliable. Not that it is the most efficient solution.
It is everyone's responsibility to not make shit software.
Or to mention native libs: GTK, wxWidgets, Xamarin.
> This browser-in-a-box cancer needs to die a painful death.
That depends on what you think the result would be.
What do you think companies who use Electron, CEF, embedded web views, etc today would do if those technologies all died tomorrow? For example, do you think GitHub, WordPress, Figma, Discord, Whats App, Slack, Trello, Skype, or Spotify would hire native Windows desktop development teams? (Or even Mac/Linux desktop development teams?)
Personally I doubt that there would be any increase in native app development. Any developer who cares about this is already making native applications, Electron just makes web apps slightly more convenient.
Yes. Until the next Cornflicker, Sircam, Code red, Blaster.
That’s a great idea. Or a simple “Native App” badge for native apps.
I can see complaining about being forced to run multiple browsers at once, the hate Web as a UI stack in general, I don't really understand.
There's a lot of stuff in CSS and HTML nobody uses anymore like floats, blink, marquee, etc.
Ultralight has a product based on that idea but I think they use WebKit.
the last thing people want from electron is a worse version of it hogging more resources
https://mykzilla.org/2017/03/08/positron-discontinued/