Hacker News Reader

Comment by dale_glass | Hacker News Reader

I'm very excited about Servo. Can't believe Mozilla wasn't interested in it.

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.

View on HN

> I'm very excited about Servo. Can't believe Mozilla wasn't interested in it.

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.

If you offered me a lot of money and unlimited timeline I'd have done it as well, and I don't know what Servo is.

Servo is an experimental web engine written in Rust, originally by Mozilla.

I'm pretty sure this was a sarcasm.

I think the joke is that he'd do pretty much anything if given a lot of money and infinite time.

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

Ah, yeah, I forgot about that. Seemed like a good tactic to get it onto some production use case more quickly.

> I also love the idea of a web engine as a component. This for some reason seems to have disappeared in modern times.

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

1 - https://github.com/cretz/ffembedpoc

There's a difference between a browser and an embedded webview. The latter shouldn't be logging into anything important at it's ripe for abuse - and basically training people to be phished by any app they install.

I admit the two categories are hazy, but it's an important distinction.

Mozilla was interested in Servo. What do you mean? They extracted multiple components into Gecko including WebRender and Stylo.

Don't you know the rule? The top comment of any Mozilla-adjacent discussion needs to contains at least 70% of misinformed garbage dunking on Mozilla. /s

Oh, that ACtiveX comment brought so many memories! I remember that when the desktop background failed, an ActiveX error page was shown (on the desktop) with clickable links. That was so consufing...

WebKit is still very embedding-friendly, though building it on Windows is messy. Works great under macOS and Linux though.

We absolutely need more embeddable web engines though. Gecko is nice but it being permanently joined at the hip with XULRunner is killing it.

I get your point but xul specifically is gone https://docs.google.com/document/u/0/d/1ORqed8SW_7fPnPdjfz42...

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

Possibly memory safe (possibly. Helix, for example, recently had a build that was crashing due to memory safety problems) doesn’t explicitly mean “great security”.

Not even memory safe.

It has many "unsafe" and "transmut", and this is without the bazillion external dependencies it also depends on.

I mean they currently have 12 unsafes and 4 transmutes (who knows how many in dependencies). I wouldn't say it's many when the code base is clocking at around 53k of Rust. Compared to languages such as C/C++/Zig, which provide no safety at all, it's still an improvement to at least know where to look when address sanitizer is screaming at you (see the bug I linked to in the sibling comment).

Both zig and modern C++ have safety that is generally good and catches swathes of issues.

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.

I agree that there's a lot to like about Zig (the module system and error management are the two I mainly consider superior to Rust's approach for example) but I wouldn't say it's easy to stay safe without thinking about it. Quite the contrary actually.

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?

[0] https://github.com/ziglang/zig/pull/17419

Are you talking about this? Interesting read and caused by one of the unsafe+transmute the sibling comment is talking about.

https://github.com/helix-editor/helix/pull/7227

It was recent. I just updated to Sonoma and then after recompiling everything, helix was crashing whenever I switched modes due to reading past the buffer.

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.

if you don't have time to look into it then you shouldn't just blindly spout incorrect information, just saying.

It seems I'm utterly and entirely misled to believe that Servo is the engine behind Mozilla since... FF52 (it was, right)? Can some please explain what is it that Mozilla uses then to render pages, and which parts did Mozilla rewrite in FF? Did some parts of Servo made it into FF, and is FF contributing back to Servo?

sorry, too many questions perhaps.

They transplanted some components, most namely Stylo. But Servo in its entirety is far from complete.

Firefox uses and has always used Gecko as its engine. Some parts that originated from Servo got transplanted into Firefox over the last few years, but overall it's still Gecko.

thank for clarification.

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.

Even if it was on the roadmap, it would still be many years until that would be possible.

> Can't believe Mozilla wasn't interested in it.

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

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

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.

That sounds like an amazing failure of imagination to me. I see at least 3 excellent angles.

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.

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

While this is great brainstorming, that doesn't mean it's a viable business plan. Having a large highly qualified dev-team working on experimental stuff for now over a decade and no likelihood of completion anytime soon and without a business plan is pretty tricky, even for a non-profit.

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.

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

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.

> Can't believe Mozilla wasn't interested in it

The fact that mozilla wasn’t interested in that really tells a lot about their priorities

Or they (Firefox folks) learned what happens when you (Netscape) try a major greenfield rewrite (Netscape v5) so ambitious that it becomes the example of why one should never rewrite.

And instead just back ported the lessons learned to make Firefox/Gecko better years earlier than a rewrite could.

That they got a ton of valuable code and lessons which improved Firefox a lot? Seems like the investment into Servo paid off really well.

That's why Servo exists in the first place. That's exactly the reason why always has been intended as a research engine, with an explicit focus on high modularity, and easy portability of single components, several of which were then incorporated into Firefox.

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.

Facts don't matter, this is one of those QAnon things were people collectively fan-fiction an apocalyptic battle for them to be on the right side of based on nothing more than a vague dislike of women and minorities.

Except Mozilla did it twice IIRC.

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.

They fired everyone working on it and completely abandoned it while giving the CEO a million dollar pay raise the same year.

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.

> When are we going to talk about how openly corrupt Mozilla has become?

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?

There is not much we can do ourselves, they are hurting themselves more than we can hurt them.

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.

> Stop using Firefox?

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.

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

I'd argue that the EFF is the main organization fighting for the open web.

The EFF is great and important too, but I feel like developing a competitive browser has more direct impact.

I agree, but that's a very generous description of what Mozilla is doing. I'd say they're less "developing a competitive browser" and more "keeping an uncompetitive browser on life support to continue to profit off it".

While very frustrating, it's just not reasonable at all to call that fraud or corruption. To make that case, you'll need to also make the argument that the CEO's remuneration is unreasonable to the given market rate; and more specifically, that you might be able to hire somebody else and achieve similar results for meaningfully less cash, and the CEO and board know this, and they're overcompensating intentionally.

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.

I was really disappointed to see Mozilla drop Servo and I think it was the wrong decision for them to make, but seeing this take mere hours after seeing people in a thread about Android Firefox bashing Mozilla for prioritizing a rewrite of their mobile browser is certainly some whiplash.

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.

> I think there was a lot more value that could have been extracted from the project

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 small level, I think that some of the areas it's behind on (security, layout) might have eventually turned out to be improvements. Stylo and WebRender were behind Firefox when they first began development as well, they were experiments to see if Rust could enable differing patterns. I personally think those experiments would have been useful to try and replicate for layout at the very least, although I don't know for sure if they would have yielded fruit.

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.

Reply on news.ycombinator.com