Mozilla's abandoned web engine 'Servo' project is getting a reboot(news.itsfoss.com) |
Mozilla's abandoned web engine 'Servo' project is getting a reboot(news.itsfoss.com) |
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.
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)
This browser-in-a-box cancer needs to die a painful death.
> 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.
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.
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.
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...
the last thing people want from electron is a worse version of it hogging more resources
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?
https://github.com/servo/servo/wiki/Building-on-ARM-desktop-...
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.
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.)
What happened exactly to Servo? Why it was discontinued?
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.
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
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.
Now it's going again, I think this could happen again in future.
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.
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.
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.
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.
Especially if they can dial it in with tauri as a viable electron/blink alternative.
That’s a great idea. Or a simple “Native App” badge for native apps.
Yes. Until the next Cornflicker, Sircam, Code red, Blaster.
If anything, it's easier to develop cross-platform native applications these days, since the mobile space has mostly collapsed to just Android + iOS.
... beep beep beep ... wakeup!
We can dream, lol.
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.
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 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.
Sure, and when applications hog it, it prevents me from putting it to better use.
Cargo's feature management should make this quite simple.
However, I do not think it would be better without Mozilla foundation. They have more software as well, such as Thunderbird.
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?
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.
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.
Or to mention native libs: GTK, wxWidgets, Xamarin.
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.
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.
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.