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.
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.
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.
They have a video of Servo running on a Raspberry 400 faster than Chromium. However there are no downloads or build instructions specifically for the Raspberry in the repository on GitHub or in the issues. Maybe it's just build for Linux.
Googling servo and raspberry together gives a lot of hardware projects with motors, even when including mozilla in the query.
The plan is to see how viable Servo is as an alternative to WebView. If it works well I expect Tauri to provide an option to use Servo when building the app.
That's what happened, but if I remember correctly, it was supposed to be an entirely new engine. I had a lot of hope for it, as the demo looked really promising at the time. It really was what Mozilla needed to get back on track, because to be honest, Firefox was pretty sucky when compared to Chrome at that time. I also liked the idea of inventing a whole programming language for that purpose (Rust), it reminded me of C/UNIX.
In the end, Firefox got better, and we have Rust, a great language on its own, but I think it could have been even better. And I was particularly disappointed when Mozilla laid off the Servo team, I feel they let go of the most important thing they had.
> And I was particularly disappointed when Mozilla laid off the Servo team, I feel they let go of the most important thing they had.
Gotta pay out those CEO bonuses somehow.
In a sick plot twist Mozilla gets shocked back to its senses, re-hires the team, restarts the effort to replace Gecko with Servo, and Firefox finally lives up to its potential. (I wish.)
Servo didn't need to be dropped, rust could have been handled oh so much better. Mozilla is not being run very well, they need to cut their "social" activities and focus on the browser and promoting free software through example rather than preaching, just throw some of that Google money at EFF/ACLU instead. I am kind of neutral on pocket and their other activities. I don't see how they could go wrong with partnerships like with Mullvad though. focus focus focus is what they need as well as a new CEO
Not really no, it was more to explore a greenfield web engine design, and also to use rust to do that.
Not for user facing features as all, for one thing servo barely has a UI
no it was to eventually be replacement for gecko engine. It was used as a testbed for a while before mozilla killed it, and it was forked for open source. Huge difference.
Was not Servo a super nice thing it would allow better multithreading through Rust's power as compared to old, ancient C++ that everyone and her neighbour says it is so bad?
What happened exactly to Servo? Why it was discontinued?
Servo was always intended as a way to proof certain technologies without the restrictions of a full browser engine like Gecko, so they could integrate them into Firefox/Gecko later if they panned out. They did and things got integrated into Firefox with https://wiki.mozilla.org/Quantum.
Then Mozilla had a sustainability crisis and - imho unwisely - decided that one of the things that they could do without in the future was the Servo team.
Without funding Servo effectively was put into sleep mode since people need to eat. Then it got donated to the Linux foundation and got new funding and progress has started again.
This isn't true. Servo was originally intended to become the rendering engine in FF.
As it became clearer that a full engine wouldn't be complete any time soon (if ever), they pivoted to using Servo to gradually upgrade the existing engine.
I hope that being at Igalia forces the team to have laser focus in being a real embeddable solution for developers. The last I checked maybe a year ago or more, it isn’t.
I commented over the years how Servo isn’t a real alternative because they don’t actually provide any API surface comparable to using CEF or full Chromium or WebKit, and as a result it’s a nonstarter.
I think someone working on it had mentioned they were looking into creating a CEF-like API for embedding, but if the project says it’s an embed-able engine before anything else and it can’t even be used for that purpose, I have no idea what that team is focusing on other than rendering itself. I’d be more interested in even just a partially compliant engine whose primary focus was actually embedding.
It might be OK if you want to build a Firefox? It’s not if you want to use it as an actual embedded renderer.
An operating system that isn't written in Rust can contend with browser remote code execution vulnerabilities. Having the browser implemented in Rust to mitigate most remote code execution vulnerabilities stops the problem at the root.
Mozilla tried multiple times to parallelize CSS style calculation in Gecko which is written in C++, and failed all of them. When they tried again in Servo with Rust, they succeeded first time.
They integrated Rust-written parallel CSS style calculation to Gecko. As a result, to this day, Firefox is the only web browser which can parallelize CSS style calculation, and beats every other browser in CSS style calculation performance.
The meme that Rust is easier to parallelize is true.
I don't think this has anything to do with the language itself. If anything, you could claim the same for C++ since "easier to parallelize in Rust" is derived from the fact that Rust models pretty much everything as a shared-ptr so many gotchas you would normally have in multithreaded (but not concurrent) code disappear. Since you have the shared-ptrs in C++, you can achieve pretty much the same and also quite easily.
So I think that the programming language as an underlying reason is most likely a wrong premise to start with. IMO there's a huge difference between "here's several MLOC with all of its 20-years legacy/baggage, and now make N% of that non-trivial work to run faster" and "here's a greenfield project with 0 LOC, no legacy and no baggage, no code to learn, and now please write the algorithm from the ground up". I think this is much more likely to be closer to the truth.
I would like to see Positron rebooted. Positron is to Firefox what electron is to chromium.
https://mykzilla.org/2017/03/08/positron-discontinued/
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.
3 replies →
You can write performant app if you want. But why stopping other on what they want to do?
7 replies →
Until there's a viable solution for desktop native GUI, this trend will continue.
20 replies →
According to Chrome, this tab alone uses over 200mb.
5 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.
5 replies →
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.
1 reply →
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...
6 replies →
Is it based on the current version? I though it was based on the old XUL based Firefox.
2 replies →
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
They have a video of Servo running on a Raspberry 400 faster than Chromium. However there are no downloads or build instructions specifically for the Raspberry in the repository on GitHub or in the issues. Maybe it's just build for Linux.
Googling servo and raspberry together gives a lot of hardware projects with motors, even when including mozilla in the query.
Did anybody here made it run on a Pi?
I haven't messed with it yet but from looking into it, this should absolutely work.
https://github.com/servo/servo/wiki/Building-on-ARM-desktop-...
I totally missed that page. Thanks!
I'd like to know how much Tauri is driving interest in Servo. I was ecstatic to see that Servo is using Tauri as a "test client" of sorts.
The plan is to see how viable Servo is as an alternative to WebView. If it works well I expect Tauri to provide an option to use Servo when building the app.
Which leads me to wonder, what would be the reason for doing that rather than just using the system WebView?
8 replies →
I thought not much: https://github.com/tauri-apps/tauri/issues/579
That issue is four years old. Here is a discussion from last month: https://github.com/tauri-apps/tauri/discussions/8524#discuss... . The two teams are apparently working together.
Wasn't servo's purpose to essentially be a testing ground for features that would eventually be pushed to Firefox?
That's what happened, but if I remember correctly, it was supposed to be an entirely new engine. I had a lot of hope for it, as the demo looked really promising at the time. It really was what Mozilla needed to get back on track, because to be honest, Firefox was pretty sucky when compared to Chrome at that time. I also liked the idea of inventing a whole programming language for that purpose (Rust), it reminded me of C/UNIX.
In the end, Firefox got better, and we have Rust, a great language on its own, but I think it could have been even better. And I was particularly disappointed when Mozilla laid off the Servo team, I feel they let go of the most important thing they had.
> And I was particularly disappointed when Mozilla laid off the Servo team, I feel they let go of the most important thing they had.
Gotta pay out those CEO bonuses somehow.
In a sick plot twist Mozilla gets shocked back to its senses, re-hires the team, restarts the effort to replace Gecko with Servo, and Firefox finally lives up to its potential. (I wish.)
7 replies →
Servo didn't need to be dropped, rust could have been handled oh so much better. Mozilla is not being run very well, they need to cut their "social" activities and focus on the browser and promoting free software through example rather than preaching, just throw some of that Google money at EFF/ACLU instead. I am kind of neutral on pocket and their other activities. I don't see how they could go wrong with partnerships like with Mullvad though. focus focus focus is what they need as well as a new CEO
Not really no, it was more to explore a greenfield web engine design, and also to use rust to do that. Not for user facing features as all, for one thing servo barely has a UI
It was a supposedly replacement for Firefox that's written in Rust.
no it was to eventually be replacement for gecko engine. It was used as a testbed for a while before mozilla killed it, and it was forked for open source. Huge difference.
Was not Servo a super nice thing it would allow better multithreading through Rust's power as compared to old, ancient C++ that everyone and her neighbour says it is so bad?
What happened exactly to Servo? Why it was discontinued?
Servo was always intended as a way to proof certain technologies without the restrictions of a full browser engine like Gecko, so they could integrate them into Firefox/Gecko later if they panned out. They did and things got integrated into Firefox with https://wiki.mozilla.org/Quantum.
Then Mozilla had a sustainability crisis and - imho unwisely - decided that one of the things that they could do without in the future was the Servo team.
Without funding Servo effectively was put into sleep mode since people need to eat. Then it got donated to the Linux foundation and got new funding and progress has started again.
> Then Mozilla had a sustainability crisis and
One way to word it... CEO had a 400% pay increase since 2018
All while Firefox browser market share dropped from 11.87% to 7.58% during the same period.
World would be a better place without the Mozilla Foundation
5 replies →
This isn't true. Servo was originally intended to become the rendering engine in FF.
As it became clearer that a full engine wouldn't be complete any time soon (if ever), they pivoted to using Servo to gradually upgrade the existing engine.
Parts of Servo were integrated fully, but they stopped doing this and let everyone go.
Now it's going again, I think this could happen again in future.
Mozilla found it will be easier to change gecko part per part once the initial tests with Servo was done and successful.
I hope that being at Igalia forces the team to have laser focus in being a real embeddable solution for developers. The last I checked maybe a year ago or more, it isn’t.
I commented over the years how Servo isn’t a real alternative because they don’t actually provide any API surface comparable to using CEF or full Chromium or WebKit, and as a result it’s a nonstarter.
I think someone working on it had mentioned they were looking into creating a CEF-like API for embedding, but if the project says it’s an embed-able engine before anything else and it can’t even be used for that purpose, I have no idea what that team is focusing on other than rendering itself. I’d be more interested in even just a partially compliant engine whose primary focus was actually embedding.
It might be OK if you want to build a Firefox? It’s not if you want to use it as an actual embedded renderer.
There was an embedding example: https://github.com/paulrouget/servo-embedding-example
This page keeps crashing for me on iOS Safari. Is anyone else experiencing this?
Yep. It keeps refreshing on me on Firefox iOS. Super annoying
A 100% Rust based browser engine is sorely needed.
That sounds pretty difficult unless it's also the operating system.
An operating system that isn't written in Rust can contend with browser remote code execution vulnerabilities. Having the browser implemented in Rust to mitigate most remote code execution vulnerabilities stops the problem at the root.
Do you mean Redox OS? https://www.redox-os.org
It's not Mozilla's anymore
I just want native tab group support.
I want Safari on Windows back
Have a look at my Split Browser WebKit (still alpha): https://niutech.github.io/splitbrowser/
Don't know if it helps anyone but darkreader in "light" mode absolutely destroys the linked page for some reason, works fine in DR dark mode tho
Servo is a waste of time. If we want a fast rendering engine, Mozilla already has it.
If we want a secure rendering engine we could leverage code checks.
It's all there. The meme of Rust equals safety (or C equals I safety) has to go away.
Servo was about parallelism.
Mozilla tried multiple times to parallelize CSS style calculation in Gecko which is written in C++, and failed all of them. When they tried again in Servo with Rust, they succeeded first time.
They integrated Rust-written parallel CSS style calculation to Gecko. As a result, to this day, Firefox is the only web browser which can parallelize CSS style calculation, and beats every other browser in CSS style calculation performance.
The meme that Rust is easier to parallelize is true.
I don't think this has anything to do with the language itself. If anything, you could claim the same for C++ since "easier to parallelize in Rust" is derived from the fact that Rust models pretty much everything as a shared-ptr so many gotchas you would normally have in multithreaded (but not concurrent) code disappear. Since you have the shared-ptrs in C++, you can achieve pretty much the same and also quite easily.
So I think that the programming language as an underlying reason is most likely a wrong premise to start with. IMO there's a huge difference between "here's several MLOC with all of its 20-years legacy/baggage, and now make N% of that non-trivial work to run faster" and "here's a greenfield project with 0 LOC, no legacy and no baggage, no code to learn, and now please write the algorithm from the ground up". I think this is much more likely to be closer to the truth.
11 replies →
Firefox owes quite a bit of its speed to Servo... so that's a weird take.
Honestly I think servo is a worthwhile endeavor if solely because it has the potential to introduce some needed variety into the browser engine space.
Especially if they can dial it in with tauri as a viable electron/blink alternative.