I agree it's disappointing to think I've found a native app only to realize it's just an Electron app. But I don't need the idea to die, I just want better transparency in app stores so I can know ahead of time whether an application is native or just a wrapped webapp.
> 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.
> But I don't need the idea to die, I just want better transparency in app stores so I can know ahead of time whether an application is native or just a wrapped webapp.
That’s a great idea. Or a simple “Native App” badge for native apps.
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.
And you won't get Skype, Slack, Teams and many other applications people use on a daily basis on Linux, at all. Features on Mac will be limited compared to Windows version, because the team prioritizes work on the platform with the largest userbase. There will be more inconsistencies in feature and UI for "desktop" version vs web version, if companies still bother to maintain two versions.
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.
Telegram manages just fine, and looks the same on all platforms. I even ran it on FreeBSD for a few weeks with no issues. Their desktop client is developed pretty much by one person in C++ with Qt. It's really feature rich these days and actually works, unlike some of the things you've listed.
Seems a bit weird to use Skype as your example, since (a) it already had a native application for Linux, (b) AFAIK it was the same (Qt) codebase as Windows and Mac, so no feature discrepancy, and (c) Skype also developed clients for other operating systems like Symbian, Android, Blackberry, etc. as well as a Java-based client for other mobiles.
If anything, it's easier to develop cross-platform native applications these days, since the mobile space has mostly collapsed to just Android + iOS.
Yep, but it seems to be a PITA. They endure whatever changes happen on Firefox UI, which are well tested on Firefox, but not on Thunderbird and Thunderbird has much more UI to manage than Firefox. See this interesting Thunderbird talk at FOSDEM on visual change that mentions this issue [1].
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.
> 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.
Which browsers? Pale Moon, Basilisk, K-Meleon are still being developed.
And in that vein, a reduced version of Servo for rendering desktop/games GUIs.
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.
https://ultralig.ht/
Something isn't that right. It is using 1/5 to 1/10 of memory compared to Chrome while still supporting 95% of what WebKit supports.
This is being worked on https://github.com/tauri-apps/tauri/issues/579
Honestly, what I would like to see more than "Electron, but Gecko" would be "Chromium Embedded Framework, but Gecko".
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)
Yeah, it's an awesome idea to waste few hundred megabytes of RAM to run your app.
This browser-in-a-box cancer needs to die a painful death.
I agree it's disappointing to think I've found a native app only to realize it's just an Electron app. But I don't need the idea to die, I just want better transparency in app stores so I can know ahead of time whether an application is native or just a wrapped webapp.
> 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.
> But I don't need the idea to die, I just want better transparency in app stores so I can know ahead of time whether an application is native or just a wrapped webapp.
That’s a great idea. Or a simple “Native App” badge for native apps.
They would use Qt/QML, NodeGui, Sciter, Flutter, React Native or another lightweight Electron alternative: https://news.ycombinator.com/item?id=38687662.
> Electron just makes web apps slightly more convenient.
Yes. Until the next Cornflicker, Sircam, Code red, Blaster.
You can write performant app if you want. But why stopping other on what they want to do?
Because I also want to run performant apps.
Because your average Joe doesn't know the difference and the race to the bottom affects everyone.
5 replies →
Until there's a viable solution for desktop native GUI, this trend will continue.
Native UI has been there for decades before. Yes, cross-platform requires extra effort.
Hell even Wine is more efficient an approach for cross-platform distribution.
10 replies →
Qt?
7 replies →
There are many: QML, NodeGui, Flutter, React Native and plenty more lightweight Electron alternatives: https://news.ycombinator.com/item?id=38687662
Or to mention native libs: GTK, wxWidgets, Xamarin.
According to Chrome, this tab alone uses over 200mb.
According to Firefox, it uses 25MB. I suspect neither measurement is entirely accurate.
Eight Megabytes and Constantly Swapping.
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.
3 replies →
And you won't get Skype, Slack, Teams and many other applications people use on a daily basis on Linux, at all. Features on Mac will be limited compared to Windows version, because the team prioritizes work on the platform with the largest userbase. There will be more inconsistencies in feature and UI for "desktop" version vs web version, if companies still bother to maintain two versions.
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.
Telegram manages just fine, and looks the same on all platforms. I even ran it on FreeBSD for a few weeks with no issues. Their desktop client is developed pretty much by one person in C++ with Qt. It's really feature rich these days and actually works, unlike some of the things you've listed.
2 replies →
Seems a bit weird to use Skype as your example, since (a) it already had a native application for Linux, (b) AFAIK it was the same (Qt) codebase as Windows and Mac, so no feature discrepancy, and (c) Skype also developed clients for other operating systems like Symbian, Android, Blackberry, etc. as well as a Java-based client for other mobiles.
If anything, it's easier to develop cross-platform native applications these days, since the mobile space has mostly collapsed to just Android + iOS.
Have a look at many cross-platform native apps like Jami, Pidgin, VNC, XnView - all made with Qt/GTK+.
Isn't Tauri already capable to run several apps in their own sandboxes with a single host process, just like browser tabs?
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.
Make a better alternative and people will flock to it.
There are better alternatives to Electron, like: Qt/QML, Tauri, Flutter, Sciter, React Native, NodeGui, DeskGap, etc. but people don't flock to it.
Thunderbird is developed on top of Firefox.
Yep, but it seems to be a PITA. They endure whatever changes happen on Firefox UI, which are well tested on Firefox, but not on Thunderbird and Thunderbird has much more UI to manage than Firefox. See this interesting Thunderbird talk at FOSDEM on visual change that mentions this issue [1].
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...
> 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.
Which browsers? Pale Moon, Basilisk, K-Meleon are still being developed.
4 replies →
Is it based on the current version? I though it was based on the old XUL based Firefox.
They've moved (or still moving?) from XUL to a regular HTML/CSS/JS stack.
They are tracking recent versions of Firefox.
How about quickjs or tauri?
why? firefox performance will always be worse than blink, if only because of spidermonkey
the last thing people want from electron is a worse version of it hogging more resources
I don't think SpiderMonkey is the boat anchor you claim it to be: https://arewefastyet.com/linux64/benchmarks/overview