Servo announces grant from the NLnet Foundation
servo.org
servo.org
Not only the idea of an engine with great security and performance is an excellent one, but I also love the idea of a web engine as a component. This for some reason seems to have disappeared in modern times.
IE used to have an ActiveX control back in the Windows 9x days. You could embed a web engine anywhere you wanted. KHTML also worked like that. And in modern times... nothing. Neither Firefox nor Chrome seem to have interest in that kind of usage. Qt WebEngine thankfully exists, but in my understanding has a bit of an antagonistic relationship with Chrome, because Chrome doesn't care for that kind of use.
Plus Chrome is a Google thing, and Google things in my experience are their own world, making them annoying to build and integrate.
So I'm very much looking forward to having a viable alternative to integrate into our code. Both solving security concerns and hopefully making the integration less painful.
The fact that mozilla wasn’t interested in that really tells a lot about their priorities
And instead just back ported the lessons learned to make Firefox/Gecko better years earlier than a rewrite could.
Especially the latter wasn't some kind of salvage, trying to squeeze value out of some theoretical project. It was an explicit goal from the beginning.
And it really doesn’t matter whst conventional wisdom holds, when the architecture of a project is based on flawed assumptions, or things just changed since it was architected.
It has to be majorly refactored, period.
When are we going to talk about how openly corrupt Mozilla has become? They clearly have issues at the top that need to be fixed for the betterment of web.
It's routinely discussed on HN, whenever a topic about Mozilla/browsers comes up. The real question in my opinion is what can we do about it? Start an awareness campaign? Stop using Firefox? Stop donating to Mozilla?
We don't want to punish the corrupt, we want to save Firefox from them. If would be great if some organization could fork Firefox and work with Servo to make a usable browser, but that's going to be really expensive, and the new browser will have to make a name for itself. Also the organization will have to do better than Mozilla in terms of corruption, which, again, is not a given when a lot of money is involved.
And use what? A Chromium reskin and give up the web to Google?
Mozilla has (many) problems, but it remains the main organisation fighting for the open web.
Well, it’s a different organisation from MS and Google anyway. I’m not sure how much I’d say they’re fighting for an open web, so much as I’d say they’re fighting for their slice of it. But the end result is more or less the same.
Now: I agree that the pay is absurd! I'm quite willing to believe she's not worth it, too. But she's hardly the first CEO to have ridiculous pay; nor am I convinced the board is overcompensating her for corrupt reasons - it may simply be a difference of perspective. And - perhaps I'm wrong, and this pay is a going market rate and a hypothetical cheaper replacement would do worse - I really don't believe that, but to call something corruption I'd need to be rather sure of that and of their knowledge of it.
And to a certain extent, I get it, I also think Servo was a more valuable project than Fenec. But let's not pretend that there's an obvious correct answer to "should Mozilla rewrite its browsers from scratch?"
Again, I say this as someone who wanted Mozilla to stick with Servo. It was a bad decision for them to drop it, I think there was a lot more value that could have been extracted from the project. But if Mozilla had stuck with Servo, I guarantee there would be people on HN right now saying, "why are they rewriting their browser engine, the current one works fine, why aren't they doing X? Shows a lot about their priorities. This is the problem with Mozilla, they're too focused on theory and engineering projects instead of just shipping a good browser." There's no winning.
What exactly? They extracted the 2 pieces that worked better than the existing gecko stack (Stylo and WebRender). I'm a big fan (and small contributor) to Servo, but it's far behind on anything else (layout, networking, security, web api support...).
On a bigger level, I think having a more easily embeddedable Firefox could change the dynamics around V8 and Chromium could end up being pretty important for the health of the web overall, including the health of Firefox.
There's an argument to be made here that none of that potential is gone because, hey, Servo is still being developed. But I think it could have gone faster with Mozilla's support behind it for longer, I think they would have served as an effective advertising/hype engine behind the technology. I think the dominance of Chromium for embedded applications does influence how developers approach the web in some minor ways.
On a really out-there level, I would like to see HTML-like interfaces proliferate in more apps, and Servo in particular has a very modular approach that could make it more feasible to bring in the DOM without bringing in languages like Javascript (yes, manipulation and events and all that stuff would need to be accessible without JS, but... it's certainly easier than it would be with Chromium, Stylo already makes some interesting applications possible). If I had to pick a company to push that effort that I didn't thing would horribly mess it up, Mozilla would be high on my list. And I vaguely maybe suspect that pulling more browser technologies out of the web could open up more technical fields and niches for Mozilla to get its hands into. Right now what that area mostly looks like is Electron or embedded Chromium. At most you have embedded JS engines like V8.
I'm hoping that there's some potential to do more interesting things, and I think it could have been valuable to Mozilla and it could have increased developer investment/mindshare if Mozilla was a bigger player in those areas.
But that's just my instinct, maybe I'm wrong.
This doesn’t feel like an accurate statement. It’s probably better described that Mozilla funded it as a research project, realized that it was going to cost a lot more money and time to bring it fully to the market and decided to save the money (and distributed that money to execs and others in ways that were not inline with their projected morals).
Based on what I’ve read from their blog posts, Mozilla then took what they could from Servo and incorporated it into Firefox, which means they were able to get some value from the project.
My guess is that if someone were to have offered Mozilla a lot of money and an unlimited timeline to complete Servo, they would have done it.
My understanding is that they tried to do that with VR (turn Servo into the first VR-capable browser and work on browser-technology-based AR overlays) and even had a partnership with Magic Leap at one point, it just never really went anywhere.
It is because it doesn't make money. An expensive research project (Servo) that was not worth the effort for Mozilla.
Mozilla needs to find better ways of making money and not depending on Googles' money.
Now thanks to the US v Google anti-trust trial, Mozilla doesn't know if they should support Google for keeping them alive for their hundreds of millions of dollars or being going against them for Google to be broken up for more competition.
Either way Google's search AND browser monopoly is held together by paying its competitors such as Apple (for Safari) and Mozilla (for Firefox).
Why would they not publicly support Google when Google are the ones keeping Mozilla alive? I'm all for journalistic integrity, but I don't think Mozilla could pull that one off.
1. Chrome beat Firefox in the stability/security area. Its usage of multiple processes, sandboxing, etc is excellent, while Firefox failed to adapt. Servo seems to have an excellent potential for coming up on top there, being both more secure, and having higher performance.
2. There are actually markets interested in security. Think say, banking, military, industry, IOT. There are various laws coming requiring companies to take security seriously. Servo has a lot of potential there too. There's potential for both projects that have security as a selling point, and regulatory compliance.
3. Embedding. Like I said, using a web engine as a component seems to have been forgotten in modern times. Surely that can be sold to somebody, because there are plenty use cases for embedding web engines in stuff.
It's not forgotten. Microsoft has WebView2 which uses the same engine as MS Edge and it can be included in your .net applications.
If OTOH you want an ActiveX then you can buy AntView, which wraps WebView2 in an ActiveX control.
Disclaimer: AntView is a control sold by my company.
In general, for research of that type (of scale) it doesn't strike me as generally very viable to rely on commercial support, and such a niche technicality is surely not going to collect enough donations to run on that alone. If we want to fund this because it's an interesting option for the future in the long term, governments are going to need to chip in - and it looks like that's at least partly at play here (or even primarily), i.e.: system working as designed.
They did adapt, and the HN types got mad at them for breaking the old-style extensions, which were effectively incompatible with multiple processes, sandboxing, performance, etc. And were totally incompatible with Servo at a fundamental level.
>2. There are actually markets interested in security. Think say, banking, military, industry, IOT.
Those industries are infamous for doing things like having applications that only support IE9 in Windows XP. Security may matter to them in theory but in practice it is clearly far lower on the priority list than stability and supporting one golden path. Getting them to adopt something novel and experimental for use cases they want to be thoroughly boring and unchanging for 15 years is never ever going to happen.
As someone that compiled and ran Servo and submitted a couple of patches, it had a long way to go (years of development) before it would have been production ready in its entirety.
It has many "unsafe" and "transmut", and this is without the bazillion external dependencies it also depends on.
I’ve been writing zig for a couple months now and have only once accidentally leaked in a test, and haven’t once accidentally messed up a buffer.
Not saying you can’t, because zig definitely has escape hatches, but idiomatic zig has proven quite easy to stay safe without even thinking about it.
No. Neither is as pedantic as rust, but zig has been a joy to work in compared to either C++ or Rust in my opinion.
Rust sometimes forces you to add annotations which certainly can get unwieldy at times (I think this in particular trips a lot people because sometimes they know what they want to tell the compiler but don't know how to express it in Rust speak and thus anger ensues). Zig, on the other hand, doesn't require any of that and makes code look simple and arguably more pleasant in comparison, but it doesn't mean the "contract" between objects goes away. It's just not expressed in code and checked by the compiler but rather by the person writing the code.
Take [0] for example. The compiler (at least in the current stage, it's at 0.11 after all) is perfectly happy with code which returns a pointer to a stack allocated memory from a function. The fix is to remember that you need to pass the argument via pointer and not let the compiler decide for you. But what if the programmer forgets or somebody else is working on the code?
Sorry I can’t be any more help on specifics than that. I am WAY beyond fiddling with my tools when they give me trouble. I just moved back to neovim.
We absolutely need more embeddable web engines though. Gecko is nice but it being permanently joined at the hip with XULRunner is killing it.
XULRunner's last release was off of the 41 branch, 8 years ago. It's dead.
sorry, too many questions perhaps.
I kinda feel betrayed using FF, always thought its a predominantly Rust-based project with improved security etc. it'd be great to have the Servo engine taken in its entirety and plugged into FF, but I guess this is not on the roadmap, reading all these comments here.
I have used CEF, WebKit, and WebView2. Only the former is easily embeddable cross platform, and as soon as it became popular, Google put a lot of resources into disallowing Google login from it or any other embedded browser[0]. I had to abandon my own CEF-based browser because of this. While I abhor the business practice, there's nothing I can do. If my browser can't login to Google products, it can't see much adoption and I don't have the time to try and win a cat-and-mouse game against their detection methods.
If we want embedded browser components to be more mainstream where anyone can develop a browser, we're going to first have to address that large companies block them if they get too popular but the embedding company is not popular. Ideally an embeddable non-Android Gecko would come about because FF is too big to block (lots of talk in the past, and I even PoC'd stealing the window handle[1]). But there's no money in it.
0 - https://developers.googleblog.com/2016/08/modernizing-oauth-...
I admit the two categories are hazy, but it's an important distinction.
My personal hope is they push hard on the modularity angle. Seems to me that:
1) there's probably a niche to be filled by an OSS browser engine focussed on embedability
and
2) That it could be a huge boon for the long-term health of the web platform if there are build-your-own-browser "lego building block" libraries that people can mix and match to create new engines.
Absolutely. Electron or something Electron-like with Servo embedded could be a nice outcome. Tauri already fills that niche a bit, but uses whatever the OS provides, rather than embedding anything. Would be nice with something in-between that.
It is strongly designed that way (the component model and the embed layer).
It is very forward thinking since we happen to be mostly in North America, but the funding comes from the EU.
The chaddest of the chad projects honestly.
Even just to take screenshots, Servo's renderer is very basic, slow and buggy.
Servo is honestly doing the correct thing by focusing on embed-ability into other projects, something that has been basically dominated by Chrome alone
They move so fast and are building all of it in the open. I'm very impressed by what the Ladybird team is doing.
This is even more so for small projects that didn't have the decades of security hardening of Firefox/Chrome behind them, and now people go to these projects assuming their security is on par with Firefox/Chrome.
I find Rust people to be really annoying these days if you can't even write software in the language you want to write without being a burden to society.
For example, here's some bugs raised by Andreas Kling in the HTML spec that were found while building Ladybird:
https://github.com/whatwg/html/issues?q=is%3Aissue+author%3A...
Is there a way to render some HTML in Rust into an image, without loading a whole browser? It doesn't have to support a lot of HTML or CSS.
IMO the main blocker for web rendering in Rust right now is better text layout, and in particular support for embedding non-text content within text ala `display: inline-block`. If/when that is implemented I think we'll be able to do a decent job of rendering basic web pages.
https://blog.nightly.mozilla.org/2017/07/25/stylo-is-ready-f...
It is embeddable, independent, memory-safe, modularand parallel web rendering engine.
There's a good report in the Servo wiki from this year (authored by a group of Igalians) summarizing the differences between the two and why the decision was made to move forward with Layout 2020.
https://github.com/servo/servo/wiki/Servo-Layout-Engines-Rep...