return to table of content

Mozilla's abandoned web engine 'Servo' project is getting a reboot

thinkingemote
63 replies
5d8h

I would like to see Positron rebooted. Positron is to Firefox what electron is to chromium.

https://mykzilla.org/2017/03/08/positron-discontinued/

jojobas
48 replies
5d6h

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.

diath
20 replies
5d6h

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

jojobas
10 replies
5d6h

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.

postalrat
7 replies
4d14h

extra effort = no less than 50x the effort

jojobas
6 replies
4d13h

Bullshit. If that's what it takes you please seek another line of work.

postalrat
5 replies
4d13h

I can built a basic app with html, javascript, etc that supports many platforms in an evening. How long do you think it would take to support windows, macos, ios, android, xbox, linux, etc, etc? Much more than 50x the time even if you already are familiar with development on all the plaforms.

jojobas
3 replies
4d13h

Qt covers 5 of the 6 platforms you named, and many more "etc".

Yes it takes a bit more than a boot camp graduate to code that, and might take a bit more time still.

lukan
1 replies
4d9h

See?

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.

jojobas
0 replies
4d7h

It's the same in any other industry where cheap plastic overtakes all, except and average user can't tell the difference, other than on "my PC is slow" level.

It is everyone's responsibility to not make shit software.

postalrat
0 replies
4d3h

5 of the 6 isn't a fair comparison

niutech
0 replies
3d15h

Flutter or React Native are also easy to develop with and cross-platform, no need to learn C/C++.

LunaSea
1 replies
5d4h

Yes, cross-platform requires extra effort.

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.

steve_rambo
0 replies
5d4h

Wine requires no more installation than Electron. There are lots of "pirated" releases for macOS/Linux with a bundled copy of Wine (sometimes with third party patches or some libraries swapped out).

coldacid
7 replies
5d6h

Qt?

EasyMark
6 replies
5d4h

too many gotchas with LGPL to become a universal solutions. I wish that gtk was more stable across all platforms. I have a few on macos and some are less than ... stable... compared to on linux.

skeletal88
0 replies
5d1h

What gotchas are there? The stuff required for doing guis is lgpl, without any kind of other licenses

scotty79
0 replies
5d1h

Has anyone been sentenced for falling into those lgpl gotchas?

rubymamis
0 replies
5d3h

I don’t think it’s as bad as you make it to be. Qt is a great option imo.

jenadine
0 replies
3d13h

Electron's web engine is also LGPL. (And GTK too)

figomore
0 replies
5d2h

I like WX.

Liquid_Fire
0 replies
4d7h

Isn't GTK also LGPL anyway?

niutech
0 replies
3d16h

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.

phantomathkg
7 replies
5d6h

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

jojobas
5 replies
5d6h

Because your average Joe doesn't know the difference and the race to the bottom affects everyone.

KronisLV
4 replies
5d4h

Because your average Joe doesn't know the difference and the race to the bottom affects everyone.

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
as opposed to:

  - having a questionably performing app built on web technologies
  - having an awesome native/cross-platform app that runs better and respects the OS design
Or, who knows, maybe it's just cheaper to use web tech and those other options have failed to make themselves as easy to get started with and work on, especially when you're looking for good cross platform options that would run nearly everywhere and be popular enough to have tooling and tutorials.

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.

jojobas
3 replies
4d18h

Your notion that browser-based apps are somehow bug-free is absurd.

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.

KronisLV
2 replies
4d4h

Your notion that browser-based apps are somehow bug-free is absurd.

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

jojobas
1 replies
3d16h

This is an equivalent of "our town job board has mostly carpenter jobs and few metalworking one, so then we started building cars out of wood".

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.

KronisLV
0 replies
2d7h

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.

mcronce
0 replies
5d3h

Because I also want to run performant apps.

wodenokoto
5 replies
5d6h

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

incrudible
3 replies
5d4h

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.

hulitu
1 replies
5d

RAM is meant to be used,

Some of us have to run other programs besides Teams. /s

wolpoli
0 replies
4d14h

Yes, I also happened to run a browser which shares the same philosophy on RAM.

JohnFen
0 replies
4d23h

RAM is meant to be used

Sure, and when applications hog it, it prevents me from putting it to better use.

ac29
0 replies
5d1h

According to Firefox, it uses 25MB. I suspect neither measurement is entirely accurate.

pquki4
5 replies
5d5h

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.

steve_rambo
2 replies
5d4h

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.

pxc
1 replies
5d3h

Doesn't Telegram use a web view via QtWebkit?

niutech
0 replies
3d15h
niutech
0 replies
3d15h

Have a look at many cross-platform native apps like Jami, Pidgin, VNC, XnView - all made with Qt/GTK+.

chriswarbo
0 replies
5d4h

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.

asoneth
3 replies
5d4h

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.

rubymamis
0 replies
5d4h

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.

niutech
0 replies
3d16h

They would use Qt/QML, NodeGui, Sciter, Flutter, React Native or another lightweight Electron alternative: https://news.ycombinator.com/item?id=38687662.

hulitu
0 replies
5d

Electron just makes web apps slightly more convenient.

Yes. Until the next Cornflicker, Sircam, Code red, Blaster.

postalrat
1 replies
4d14h

Make a better alternative and people will flock to it.

niutech
0 replies
3d15h

There are better alternatives to Electron, like: Qt/QML, Tauri, Flutter, Sciter, React Native, NodeGui, DeskGap, etc. but people don't flock to it.

moritzwarhier
0 replies
5d4h

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.

zerr
6 replies
5d6h

Thunderbird is developed on top of Firefox.

kwhitefoot
2 replies
5d6h

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

zerr
0 replies
5d6h

They've moved (or still moving?) from XUL to a regular HTML/CSS/JS stack.

jraph
0 replies
5d5h

They are tracking recent versions of Firefox.

jraph
2 replies
5d5h

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

niutech
1 replies
3d16h

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.

jraph
0 replies
2d3h

They are all kind of pre-multiprocess/Rust Firefox forks. It seems Pale Moon has forked Gecko into Goanna and made it embeddable (which is neat!) and that's what K-Meleon uses too. Which I didn't know.

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.

pier25
1 replies
5d3h

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/

ksec
0 replies
1d5h

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.

coolelectronics
1 replies
5d1h

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

tadfisher
0 replies
4d14h

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

bouk
1 replies
5d6h
DarkUranium
0 replies
5d5h

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)

stefanos82
0 replies
5d7h

How about quickjs or tauri?

jhoechtl
15 replies
5d6h

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.

sanxiyn
12 replies
5d5h

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.

menaerus
11 replies
4d9h

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.

Liquid_Fire
10 replies
4d7h

Rust doesn't model everything as a shared_ptr, it gives you a choice of tools that fit different use cases - just like C++ does. The difference is if you mess up, it is massively more likely to detect it at compile time.

I agree that starting from scratch can make a huge difference, but if you're starting from scratch anyway why not use the language that will prevent you from making mistakes in your design?

menaerus
9 replies
4d6h

I did not mean "everything" in the broader context but in the context when it comes to writing "easy" multithreaded programs. Pretty much everything in that case becomes modeled through a shared-ownership or message-passing semantics.

Since those same mechanisms are available in C++, and other languages too, making an argument that some specific XYZ algorithm re-implementation from scratch was more successful only because it was written in Rust, doesn't hold water. It was successful, for the arbitrary definition of success, in its major part because it was a greenfield project.

I believe that suggesting otherwise is plain wrong and misleading.

Liquid_Fire
8 replies
4d5h

You might be right, but you're stating this without any evidence, so I don't think it's clearly "wrong or misleading". There are many cases of software rewrites failing, so I'm not sure you can take for granted that "greenfield project" implies higher success rate, and even if you did, I don't see how you can judge how much of this was due to it being rewritten from scratch vs that it was in Rust to claim "major part".

menaerus
7 replies
4d4h

It's common sense what I said. It applies across the industry regardless of the programming languages used. On the contrary, where's the evidence suggesting that the Rust is what made Gecko rewrite succeed? Has there been any rewrite from scratch with some other programming language?

steveklabnik
4 replies
4d2h

There were two previous attempts at parallelizing CSS layout in Firefox. Both were in C++. Both were abandoned after being unsuccessful. The Servo folks credited Rust's safety guarantees as the reason why they were able to be successful on the third attempt.

https://www.youtube.com/watch?v=Y6SSTRr2mFU

menaerus
3 replies
4d1h

C++ attempts were from scratch or were based on interventions on the existing codebase?

steveklabnik
2 replies
4d1h

I mean, the Rust version was also put into the existing codebase, so it's not clear to me what distinction you're making.

But this presentation was made seven years ago, and the attempts it's talking about are even older, and I wasn't involved with them. So I don't know the answer to your question.

menaerus
1 replies
4d1h

The distinction is whether or not you're rewriting something from scratch carrying no baggage from the thwarts of the existing system or you keep organically growing existing code to meet the new requirements. The latter is usually much much harder. I hope it's clear now.

steveklabnik
0 replies
4d

Understood. Yeah, I do not know.

Liquid_Fire
1 replies
4d2h

No, I don't think there's any concrete evidence either way. I'm not trying to argue that it was Rust that made it succeed - I'm sure in reality it was some mixture of both, as well as other factors.

menaerus
0 replies
4d1h

Having to work and learn through the codebase to make some substantial improvements often requires substantial effort and even rewiring the code architecture itself. That's enough of the evidence for me.

jacoblambda
0 replies
5d6h

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.

boxed
0 replies
5d6h

Firefox owes quite a bit of its speed to Servo... so that's a weird take.

k8svet
10 replies
5d13h

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.

laerus
7 replies
5d11h

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.

Joeboy
6 replies
5d9h

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

Raicuparta
3 replies
5d8h

I'm currently suffering the pains of developing a Tauri app that relies on the system WebView (which is the default for Tauri). It's unreliable (especially on Windows where people love to mess around and run "debloat" scripts), and causes slight differences on each platform. Tauri lets you bundle the WebView, but this causes the installer to grow like 150 MB. I presume this alternative would be a lot smaller.

cageface
1 replies
5d6h

After messing around with various cross platform desktop toolkits, including a big Electron app and some smaller Tauri apps, I've settled on Flutter. It's not perfect but the results I'm getting are so far much better than anything I was able to achieve using repurposed web tech.

Raicuparta
0 replies
4d11h

How is desktop performance and startup times for you with Flutter? I tested some flutter apps like Flutter Folio and they seemed to perform poorly.

Sytten
0 replies
5d6h

Afaik bundling webview is only available with appimage. We also have a big tauri app and it is a PITA to develop. I actually opened an issue to support bundling a chromium ala electron.

ephemeral-life
1 replies
5d8h

You won't have to worry about different engines and their edge cases. But at that point we are back to electron, but in rust.

black_puppydog
0 replies
5d4h

... and with an easy way to control what gets baked into your engine. maybe you don't actually need that Xbox controller driver in your app. :)

Cargo's feature management should make this quite simple.

davgoldin
1 replies
5d9h
goku12
0 replies
5d8h

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.

germandiago
10 replies
5d7h

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?

sgift
7 replies
5d6h

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.

whywhywhywhy
5 replies
5d6h

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

yoavm
3 replies
5d5h

Because without the Mozilla Foundation the Firefox market share would raise?

whywhywhywhy
1 replies
5d4h

I mean even staying stagnant would be an improvement over the current management that seems more focused on selling VPN scams and other farces.

yoavm
0 replies
2d4h

Not sure what's a scam about Mozilla's VPN offering? AFAIK it's powered by Mullvad, one of the VPN providers with the best reputation when it comes to privacy.

chris_wot
0 replies
5d4h

Sadly, this might well be the case.

germandiago
0 replies
5d5h

I agree the increases are too high for the performance shown (apparently).

However, I do not think it would be better without Mozilla foundation. They have more software as well, such as Thunderbird.

smt88
0 replies
5d4h

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.

stuaxo
0 replies
5d7h

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.

claudex
0 replies
5d7h

Mozilla found it will be easier to change gecko part per part once the initial tests with Servo was done and successful.

sa-code
7 replies
5d11h

Wasn't servo's purpose to essentially be a testing ground for features that would eventually be pushed to Firefox?

GuB-42
3 replies
5d8h

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.

rollcat
1 replies
5d8h

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

jacknews
0 replies
5d7h

And fires the executive?

... beep beep beep ... wakeup!

We can dream, lol.

EasyMark
0 replies
5d4h

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

theusus
1 replies
5d4h

It was a supposedly replacement for Firefox that's written in Rust.

EasyMark
0 replies
5d4h

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.

fyrn_
0 replies
5d9h

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

pmontra
2 replies
5d7h

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?

jacoblambda
1 replies
5d6h

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

pmontra
0 replies
5d5h

I totally missed that page. Thanks!

devaiops9001
2 replies
5d6h

A 100% Rust based browser engine is sorely needed.

postalrat
1 replies
4d14h

That sounds pretty difficult unless it's also the operating system.

niutech
0 replies
3d15h

Do you mean Redox OS? https://www.redox-os.org

terabytest
1 replies
5d7h

This page keeps crashing for me on iOS Safari. Is anyone else experiencing this?

h0l0cube
0 replies
5d7h

Yep. It keeps refreshing on me on Firefox iOS. Super annoying

haunter
1 replies
5d6h

I want Safari on Windows back

niutech
0 replies
3d15h

Have a look at my Split Browser WebKit (still alpha): https://niutech.github.io/splitbrowser/

andrewmcwatters
1 replies
5d2h

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.

niutech
0 replies
3d15h
charcircuit
0 replies
5d4h

It's not Mozilla's anymore

beretguy
0 replies
5d5h

I just want native tab group support.

andrewmcwatters
0 replies
5d2h

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.

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.

EasyMark
0 replies
5d4h

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