[HN Gopher] Servo announces grant from the NLnet Foundation
___________________________________________________________________
Servo announces grant from the NLnet Foundation
Author : puzzlingcaptcha
Score : 307 points
Date : 2023-11-09 13:30 UTC (9 hours ago)
(HTM) web link (servo.org)
(TXT) w3m dump (servo.org)
| nicoburns wrote:
| It's cool to see the work on Servo since Igalia picked it up.
| There was a lot of tech debt to work through due to years of
| minimal maintenance, but they seem to have been making real
| progress.
|
| 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.
| Vespasian wrote:
| Wild speculation: With iphones being forced to open their web
| engine there might be some apps interested in embedding their
| own engines across mobile devices.
| capableweb wrote:
| > 1) there's probably a niche to be filled by an OSS browser
| engine focussed on embedability
|
| 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.
| the_duke wrote:
| Tauri is actually adding experimental Servo support.
| capableweb wrote:
| Oh wow, I wasn't aware of this! So proper embedded cross-
| platform engine into the final binary? That'd be awesome.
| igrunert wrote:
| Yep, embedding the Servo engine into the final binary.
| This work is sponsored by another (separate) NLnet grant:
|
| https://nlnet.nl/project/Tauri-Servo/
| paulrouget wrote:
| > My personal hope is they push hard on the modularity angle
|
| It is strongly designed that way (the component model and the
| embed layer).
| wongarsu wrote:
| An embedded engine is also a much faster path to viable use
| cases. For example Sciter [1] has some degree of success
| despite implementing only a sane subset of the DOM API. It
| doesn't work well for general internet surfing, but when used
| as an UI library you just avoid the parts that don't work.
|
| 1: https://sciter.com/
| dale_glass wrote:
| 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.
| znpy wrote:
| > 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
| paulryanrogers wrote:
| 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.
| jeltz wrote:
| 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.
| dahauns wrote:
| 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._
| ZeroGravitas wrote:
| 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.
| mrd3v0 wrote:
| 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.
| div72 wrote:
| > 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?
| GuB-42 wrote:
| 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.
| maleldil wrote:
| > 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.
| Aeolun wrote:
| > 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.
| unflxw wrote:
| I'd argue that the EFF is the main organization fighting
| for the open web.
| emn13 wrote:
| 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.
| danShumway wrote:
| 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.
| fabrice_d wrote:
| > 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...).
| danShumway wrote:
| 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.
| bluejekyll wrote:
| > 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.
| ericlewis wrote:
| 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.
| dale_glass wrote:
| Servo is an experimental web engine written in Rust,
| originally by Mozilla.
| konart wrote:
| I'm pretty sure this was a sarcasm.
| dralley wrote:
| >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.
| bluejekyll wrote:
| Ah, yeah, I forgot about that. Seemed like a good tactic to
| get it onto some production use case more quickly.
| rvz wrote:
| > 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).
| tentacleuno wrote:
| > 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.
| dale_glass wrote:
| 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.
| wila wrote:
| > 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.
| emn13 wrote:
| 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.
| dralley wrote:
| >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.
| 101008 wrote:
| 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...
| wredue wrote:
| 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".
| jedisct1 wrote:
| Not even memory safe.
|
| It has many "unsafe" and "transmut", and this is without the
| bazillion external dependencies it also depends on.
| jiripospisil wrote:
| 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).
| wredue wrote:
| 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.
| jiripospisil wrote:
| 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
| wredue wrote:
| 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.
| jwells89 wrote:
| 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.
| schuyler2d wrote:
| I get your point but xul specifically is gone https://docs.go
| ogle.com/document/u/0/d/1ORqed8SW_7fPnPdjfz42...
| jcranmer wrote:
| > 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.
| tristan957 wrote:
| Mozilla was interested in Servo. What do you mean? They
| extracted multiple components into Gecko including WebRender
| and Stylo.
| fabrice_d wrote:
| 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
| larodi wrote:
| 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.
| seanw444 wrote:
| They transplanted some components, most namely Stylo. But
| Servo in its entirety is far from complete.
| kodablah wrote:
| > 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
| fermigier wrote:
| The money for this grant actually comes, in part, from the
| European Commission (via the NGI programme).
| Sander_Marechal wrote:
| That is great news for Servo! NLNet Foundation has been funding a
| lot of great projects lately. I see their name pop up a lot.
| chubot wrote:
| Yes, my project https://www.oilshell.org/ has been funded by
| NLnet since 2022, and it's helped a lot. I needed some help to
| push through a few problems, and that happened :)
|
| It is very forward thinking since we happen to be mostly in
| North America, but the funding comes from the EU.
| rob74 wrote:
| What's this "Legacy Layout" they're using as a comparison? The
| previous iteration of Servo? Looks like some of the code is still
| used by both, as the curves sometimes (but not always) go up and
| down at the same time...
| igrunert wrote:
| Legacy Layout refers to the original system, Layout 2013. There
| was a second system started, Layout 2020, to address challenges
| with implementing parts of the CSS spec which didn't cleanly
| map to Layout 2013's architecture.
|
| 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...
| sergiotapia wrote:
| See also Ladybird for another from-scratch browser being built by
| a more ragtag indie group. https://ladybird.dev/
|
| The chaddest of the chad projects honestly.
| jedisct1 wrote:
| I have more hope in Ladybird than Servo, TBH. Considering how
| young it is, Ladybird is already very impressive.
|
| Even just to take screenshots, Servo's renderer is very basic,
| slow and buggy.
| jancsika wrote:
| Hm... is Ladybird more feature complete than Servo at this
| point?
| actuallyalys wrote:
| I have more optimism for Ladybird as well. For me, That's not
| a knock on Servo and mostly because it was started as a
| research project, which suggests you're focusing more on
| experimentation than producing a product.
| wila wrote:
| Ladybird is amazing.
|
| They move so fast and are building all of it in the open. I'm
| very impressed by what the Ladybird team is doing.
| neurostimulant wrote:
| Is ladybird actually usable outside of serenity os?
| tristan957 wrote:
| There are many ports. GTK, Qt, and Cocoa are the 3 that I am
| aware of.
| mvelbaum wrote:
| Why do we need another browser engine written in C++?
| tristan957 wrote:
| Can you explain why people shouldn't pursue passion projects
| because they are written in a language you don't like?
| whytevuhuni wrote:
| Not the parent, but my own opinion is that if a C/C++
| passion project becomes successful, it burdens other people
| with yet another source of security vulnerabilities.
|
| 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.
| tristan957 wrote:
| Why is your imaginary burden more important than
| someone's passion?
|
| 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.
| igrunert wrote:
| Building an browser engine from scratch is a great exercise
| for validating both the specifications and the web platform
| tests.
|
| 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.
| ..
| AbuAssar wrote:
| Servo is a web rendering engine written in Rust, with WebGL and
| WebGPU support, and adaptable to desktop, mobile, and embedded
| applications.
|
| It is embeddable, independent, memory-safe, modularand parallel
| web rendering engine.
| ilaksh wrote:
| Somehow I thought that Servo was already incorporated into
| Firefox.
|
| 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.
| nicoburns wrote:
| The closest thing currently is probably
| https://github.com/trimental/inlyne which differs in two ways:
| it only support markdown not arbitrary HTML, and it renders to
| screen rather to an image. But it's a good start.
|
| 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.
| jszymborski wrote:
| The CSS style system (stylo) started out in Servo and is now in
| Firefox but as I understand it they've diverged quite a bit.
|
| https://blog.nightly.mozilla.org/2017/07/25/stylo-is-ready-f...
| fulafel wrote:
| WebRender and Stylo come from Servo and have been integrated as
| Quantum Render and Quantum CSS. An maybe some other things as
| well?
| abhinavk wrote:
| Not the entire engine but WebRender (GPU-based compositor) and
| Stylo (CSS engine) are in Firefox for a few years now.
___________________________________________________________________
(page generated 2023-11-09 23:01 UTC)