Mozilla's abandoned web engine 'Servo' project is getting a reboot (opens in new tab)

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.

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)

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.

You can write performant app if you want. But why stopping other on what they want to do?

Until there's a viable solution for desktop native GUI, this trend will continue.

According to Chrome, this tab alone uses over 200mb.

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.

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.

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...

Is it based on the current version? I though it was based on the old XUL based Firefox.

I don't think SpiderMonkey is the boat anchor you claim it to be: https://arewefastyet.com/linux64/benchmarks/overview

I totally missed that page. Thanks!

Which leads me to wonder, what would be the reason for doing that rather than just using the system WebView?

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.

> 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

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.

> 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

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.

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

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.