[HN Gopher] This year in Servo: over 1000 pull requests and beyond
___________________________________________________________________
This year in Servo: over 1000 pull requests and beyond
Author : Vinnl
Score : 238 points
Date : 2023-12-18 12:09 UTC (10 hours ago)
(HTM) web link (servo.org)
(TXT) w3m dump (servo.org)
| stephen_g wrote:
| Is there any plan at Mozilla to eventually use Servo for Firefox
| or did them basically stopping working on it end any hope of
| that? Is the Servo team's plan to build a new browser around it?
|
| It definitely could get interesting soon, I've been keenly
| watching the development of the Ladybird browser (which is also a
| from-scratch engine) so if there were potentially two viable new
| browser engines over the next few years that could really shake
| things up!
| nicoburns wrote:
| Mozilla have already integrated a few key servo components into
| Firefox. Notably webrender, the rendering backend, and stylo,
| the style system. But they've effectively dropped all servo
| development at this point, and are not working on it further.
| tmikaeld wrote:
| Huh? Why would they drop development of key components to
| their main product?
|
| What is Mozilla without Firefox?
|
| Update:
|
| https://www.youtube.com/watch?v=9lkIX5ryZZ4
|
| Basically, Mozilla gave Servo employees the foot and the
| project was taken over by the linux foundation.
|
| Servo dev has been restarted (mostly) during 2023 and the
| changed Firefox made to their servo implemementation is now
| being added to servo in batches (ongoing).
|
| So Servo team is aiming to become a full featured
| (standalone) web platform (browser).
| robin_reala wrote:
| They integrated what they felt was worthwhile, and continue
| to develop and support those pieces internally to Firefox.
| zaphar wrote:
| Servo is not Firefox. It was always a testbed research
| platform. Stopping development of Servo does not mean
| stopping development of Firefox.
| Longhanks wrote:
| > What is Mozilla without Firefox?
|
| De facto? Google's puppet company to keep regulators happy.
| chimeracoder wrote:
| > De facto? Google's puppet company to keep regulators
| happy.
|
| If you think that's the case, then Google is clearly
| failing at that goal, since they've aggressively taken
| browser share directly from Firefox users to the point
| where Firefox may no longer be supported by government
| services.
| kramerger wrote:
| > project was taken over by the linux foundation
|
| Why? What is role of Linux Foundation anyway?
|
| (Beside spending members tons of spam and completely ignore
| GDPR?)
| fabrice_d wrote:
| Their role is mostly being a fiscal host to receive
| donations. Servo moved to the Linux Foundation Europe
| recently (https://servo.org/slides/2023-04-25-servo-and-
| linux-foundati...), which should make it easier to
| receive grants from EU programs - this is a good thing!
| cxr wrote:
| The undue focus and almost wistful
| romanticization/fetishization of Servo is frankly weird,
| especially when it comes from people with only a tenuous grasp
| of (let alone hands-on relationship with) browser engine
| internals. I'm talking about tech news writers and kind-of-but-
| not-really technical commenters on e.g. Reddit who confabulate
| their own lore in the spirit of those press accounts, etc.
|
| Firefox uses Gecko as its browser engine. The worthwhile parts
| of Servo are already in Firefox by way of Gecko. Servo is not
| The Answer to all of life's problems.
|
| Or, to answer your question more bluntly: "No. Stop asking."
| Ygg2 wrote:
| > Firefox uses Gecko as its browser engine. The worthwhile
| parts of Servo are already in Firefox by way of Gecko.
|
| And Gecko has been notoriously unembeddable. Which kinda
| helped the whole CEF spread.
|
| Not to mention Mozilla basically kneecapped Servo and Firefox
| by firing most of its devs in a purge.
| crotchfire wrote:
| Mozilla needs to hear this more often.
|
| There is only one browser, because browsers need to be
| embeddable, and Firefox isn't.
| lmeyerov wrote:
| Interesting to work through that
|
| On its face, it's a tough sustainability position for an
| org of Mozilla's size b/c browser revenue - today - is
| from controlling the search bar (and maybe now payments
| APIs?). By making Firefox embeddable, Mozilla gives that
| revenue to whoever is doing the embedding. Ex: Brave <>
| Chrome engine.
|
| Building for embedding developers can be super
| distracting if no sustainability, which isn't a problem
| for Google: They still make money from embedding by
| owning the embedding environments like Android. AFAICT,
| Mozilla failed to land in sizeable markets there. They
| tried to own & partner in the embedding envs -- e.g.,
| FirefoxOS -- so maybe the trick is to get a more generous
| rev share for phone vendors wanting to break free of
| Google? Historically didn't seem to really work out, but
| maybe genAI w/ consumer/prosumer-grade UIs is reopening
| that door.
|
| Evolutions like that in turn may take quite an
| engineering & culture rethink as well, not easy to turn
| such a big & decentralized ship. I'll keep rooting for
| them!
| jwells89 wrote:
| I'm not well-versed on the internals of FirefoxOS, but
| I'm not sure it really counts as embedding because to my
| understanding, the entirety of the user-facing UI was
| built with Gecko. Embedding entails usage of the engine
| with unrelated toolkits, e.g. AppKit/UIKit or GTK.
|
| If that's true, then Mozilla wouldn't have been making
| money from Gecko's ability to embed with FirefoxOS unless
| the project took a sharp corner and changed UI toolkits.
| lmeyerov wrote:
| The FirefoxOS scenario would be Gecko embedding in
| FirefoxOS, so Mozilla is their own customer, and makes $
| by being the controller of FirefoxOS - OS search, and
| configuration of browser search
|
| It's less likely the handset manufacturer would be able
| to change search bar defaults in those scenarios, at
| least without a stronger profit sharing negotiation, as
| they'd probably be already negotiating a more careful
| licensing & teaming agreement
| paulrouget wrote:
| I was part of Mozilla back then. I think we were already
| talking about making Gecko embeddable in __2003__.
|
| But then... looot of things happened, other priorities,
| competition, bad decisions, etc etc.
| mike_hearn wrote:
| Arguably neither is Chrome. Electron, CEF and WebView2
| are all forks of it. Google has no interest in a
| supported official embedding API.
| cxr wrote:
| I'm struggling to see the logical throughline that connects
| your comment to mine, or even how it relates to itself.
|
| Gecko was originally conceived to be embeddable by design.
| TPTB decided this was a handicap. It's not an accident that
| it's hard to work with outside the context that is its
| modern raison d'etre; it is now unembeddable, if not "by
| design" then certainly by choice.
|
| Servo is not a product, and there is no product for which
| Servo is an integral component. Servo was an R&D project.
| It succeeded. Mozilla laid off a bunch of Servo developers,
| partly because of COVID, and partly because it was (past)
| done; it doesn't make sense to keep paying for R&D at
| Servo's stage. It's debatable whether it's even R&D at that
| point--more like wankery/noodling (i.e. what most
| programmers _want_ to do, but that the world already has
| enough of).
| paulrouget wrote:
| > Gecko was originally conceived to be embeddable by
| design
|
| Which part? And... what do you mean by embeddable in that
| context?
| zokier wrote:
| XULRunner?
| Ygg2 wrote:
| Throughline is unwanted fetishization/romantizadion of
| Servo.
|
| I'd argue Servo's promise was never realized - embedding.
|
| Another part of it is losing people in the purge. People
| fired weren't hired to work on Servo exclusively, some
| were long time developers of FF, including the MDN docs
| team.
|
| So it's not like they started Servo, hired bunch of
| people to work on it, then fired them after R&D was done.
| eitland wrote:
| I remember Mozilla Prism as a "site specific browser"or
| what one calls it back in the days.
| KyleSanderson wrote:
| If only one could Boot2Gecko
| capableweb wrote:
| > Is there any plan at Mozilla to eventually use Servo for
| Firefox or did them basically stopping working on it end any
| hope of that?
|
| Initially, I think Servo was never meant to be integrated
| wholesale into anything. It was a experiment playground to
| evaluate ideas without having them coupled to mainline Firefox,
| and be able to iterate on things quickly.
|
| Once the ideas were validated, they were integrated into
| Firefox without pulling in their entirety of Servo.
|
| The "Quantum Render project" is one example of this, where the
| WebRender compositor was first created in Servo, and eventually
| integrated into Firefox mainline.
| nicce wrote:
| I remember the Quantum hype. Time flies.
|
| https://developer.mozilla.org/en-
| US/docs/Mozilla/Firefox/Rel...
| worik wrote:
| Hype? I guess
|
| It made Firefox competitive again
| nicce wrote:
| Hype can be deserved, not always dismissive
| insanitybit wrote:
| Yeah, incredible that there was a brief period of time
| where Mozilla almost made Firefox exciting again.
| dbrgn wrote:
| Quote from the post:
|
| > In a decade that many people feared would become the nadir of
| browser engine diversity, we hope we can help change that with
| Servo.
|
| I sure hope so! It might be a good thing that Servo is now
| independent from Mozilla. We can't rely on Mozilla anymore, and
| should move on. Maybe someday Servo can become the new Firefox
| (as in "modern and freedom-respecting browser")?
|
| From testing the current version of Servo, it still has a long
| long way to go though, until it becomes a usable browser.
| deskamess wrote:
| > Servo is now independent from Mozilla
|
| When I initially read the headline what I remember thinking
| before reading the article was 'I hope it has some use outside
| of Firefox'.
| lnxg33k1 wrote:
| I build scrapers with rust, and use servo
| Exec2 wrote:
| is there a chance to see it? any links for someone
| interested?
| Reefersleep wrote:
| I would have thought it overkill to memory manage scrapers
| by hand. Do you need such succinct memory usage?
| wongarsu wrote:
| Safe memory management without GC is the feature that
| gets Rust the most headlines, but it's not the only
| raison d'etre. It also has a great type system, that
| combined with the focus of the standard library and the
| library ecosystem makes it a lot easier to avoid bugs and
| makes refactoring a lot safer and easier. It's also very
| fast, and scrapers are surprisingly often CPU bound
| zozbot234 wrote:
| There's also the Ladybird browser by the SerenityOS folks,
| that's however not written in a memory-safe language.
| 3836293648 wrote:
| I thought Jakt was supposed to be memory safe (but it was
| very wip last I looked at Jakt)
| peoplefromibiza wrote:
| Ladybird is written in C++
| azakai wrote:
| It is for now, but as both Ladybird and Jakt are
| SerenityOS projects, eventually parts of Ladybird might
| get written in Jakt. Jakt compiles to C++ and plans to
| have features like "inline C++" to allow easy interop
| between the two, so I assume they are thinking about
| this.
| mminer237 wrote:
| Which, despite being much younger and 80% made by one guy, is
| somehow way farther along than Servo. Ladybird doesn't have
| any pre-built images, but it's downright usable.
| x-yl wrote:
| Andreas is incredible but that's an overstatement.
| $ git log --format="%an %s" | grep -E
| "Browser|LibWeb|Ladybird|LibJS" | wc -l 15524 $
| git log --format="%an %s" | grep -E
| "Browser|LibWeb|Ladybird|LibJS" | grep "Andreas Kling" | wc
| -l 4249 $ calc 4249/15524
| ~0.28530018036588508116
|
| Still a monumental feat but don't downplay the community
| that's rallied behind him.
| devwastaken wrote:
| It's not further along when you consider the
| vulnerabilities that are present. C++ is unfit for long
| term use because it is intentionally introducing severe
| tech debt that we mistakenly imagine doesn't have to be
| repaid.
| nightski wrote:
| I rely on Mozilla just fine. Have used Firefox for a decade and
| will continue to do so. I am not about to accept Google as the
| sole provider of the web like you are so eager to do.
| eitland wrote:
| I think you misunderstood:
|
| I think GP just like me wants neither Google nor Mozilla.
| tapoxi wrote:
| With Firefox being in single digit marketshare, the fight is
| already over. It's hard to justify developing for or testing
| against Firefox unless you want to appeal to the similarly
| small Linux desktop crowd.
| echelon wrote:
| This is why antitrust matters.
|
| Google needs to have their arms tied for a bit. Their
| fingers are in every single pie, taxing the entire tech
| sector.
|
| Likewise, Safari shouldn't be the default iPhone browser,
| Edge shouldn't be the default on Windows, and no company
| should be able to scare users or force their solution as a
| default.
|
| The browser space would be fine without Google.
| tapoxi wrote:
| But looking at alternative browsers like Brave, Vivaldi,
| Opera or Arc they are also Chromium based. Brave is even
| by Mozilla's former CTO and they still don't use the
| Mozilla stack. Many apps will either bundle in CEF or are
| entirely written in Electron.
|
| Mozilla just made technology that nobody else wants to
| use.
| capableweb wrote:
| > From testing the current version of Servo, it still has a
| long long way to go though, until it becomes a usable browser.
|
| In reality, I think you're waiting for a different project.
| Servo is like Gecko/Webkit, it's the browser engine. As far as
| I know, they're not aiming to build a browser, just the engine
| part.
|
| What you're waiting for is someone to start using Servo as an
| engine and provide the browser chrome :)
| HeckFeck wrote:
| I thought it would be a fun weird project to make Servo work
| with MS' abandoned JavaScript engine:
|
| https://github.com/chakra-core/ChakraCore
|
| Of course it is written in C++ and you'd probably want a pure
| Rust browser. But it is sad seeing that fairly complete open
| source JIT JavaScript engine sit and rot.
| capableweb wrote:
| > finishing our integration with Tauri (thanks to NLNet)
|
| This is really exciting! Hopefully can lead to tiny packages
| (compared to Electron) but still a consistent rendering story
| across platforms.
| ReactiveJelly wrote:
| If it has enough features to match Electron, I think it's
| likely to end up the same size (100 MB on disk)
| capableweb wrote:
| No, because Electron embeds Chromium/Chrome, Tauri uses
| whatever the platform already has.
| fabrice_d wrote:
| Correct, but for the Tauri/Servo combination, you need
| Servo which is unlikely to be already available. Stripped
| release builds of servo are currently 106M which is quite
| large. Hopefully some size reduction will be achieved.
| niutech wrote:
| For lightweight alternatives to Electron.js (apart from Tauri),
| have a look at:
|
| - Sciter (https://sciter.com)
|
| - Yue (https://libyue.com)
|
| - Wails (https://wails.io)
|
| - Muon (https://github.com/ImVexed/muon) and Ultralight
| (https://ultralig.ht)
|
| - Gluon (https://gluonjs.org)
|
| - NeutralinoJS (https://neutralino.js.org)
|
| - Proton Native (https://proton-native.js.org)
|
| - NodeGUI (https://nodegui.org)
|
| - DeskGap (https://deskgap.com)
|
| - Graffiti (http://tomsik.cz/graffiti/)
| ravenstine wrote:
| Can anyone tell me whether Servo is "ready enough" to use for
| small noncommercial projects? For example, I really like writing
| personal projects in Typescript using Deno, but there really
| isn't a very good UI library for Deno outside of running an HTTP
| server. Other attempts at UI libraries, last I checked, were
| experimental or half-assed. Would be cool to somehow integrate
| directly with Servo from Deno so that I don't have to resort to
| Electron.
| capableweb wrote:
| > Can anyone tell me whether Servo is "ready enough" to use for
| small noncommercial projects?
|
| I don't think it is, yet. But why not play around with it and
| see if it's enough for your use case? Hard to know exactly
| without knowing what you need to be able to do.
|
| Personally, Tauri currently hits the sweetspot of being way
| lighter than Electron, but still provide (mostly) the same
| benefits.
| mst wrote:
| There's always https://neutralino.js.org/ which uses native
| WebView components to keep itself rather smaller than Electron.
| KolmogorovComp wrote:
| The budget to make a browser today (including a browser engine)
| is estimated to be around 400 million yearly (FF cost, estimates
| for Safari in the same range). They may be bloated, but even by
| being 10x more efficient it's still 40 million a year of
| equivalent engineering work. How is servo intending to pull that
| work without the leverage of a big corp?
| YetAnotherNick wrote:
| I might be wrong but I don't think servo is intending to be
| feature or standard complete ever. Most of the cost of firefox
| or safari likely comes from new features.
|
| Also it is a web rendering engine, not a full fleshed browser.
| capableweb wrote:
| How much of that cost is the browser vs the cost of the browser
| engine?
|
| Servo currently describes itself as a "web rendering engine",
| so I don't think they are aiming to become a full-featured
| browser, and I'm not sure if there is an important distinction
| between "browser engine" vs "web rendering engine". It makes it
| sound like they only want to focus on the rendering part
| itself.
| mminer237 wrote:
| Ladybird has mostly been made by one guy in a few years and has
| somehow become a usable browser. Where did you get that
| estimation?
| joshmarinacci wrote:
| useable and complete are very different things.
| wharvle wrote:
| There's something wackadoo going on in software where in one
| environment it'll take 200 workers six years to have
| something that's still not good, and in another it'll take
| 1-5 workers a couple years to do at least as well.
|
| It's not even a corporate vs. small shop thing. Look at the
| team sizes on "giant" programs from big companies in the 90s
| and consider how enormous an undertaking they'd be considered
| by most software orgs today.
|
| Like, I get all the Mythical Man-Month, Brooks' Law stuff and
| that that observation predates the period I'm talking about,
| but there's definitely been some kind of shift that has other
| factors causing this (with Brooks' Law compounding the
| problem). Not sure what it is, I just know that it sure looks
| like we're far _less efficient_ at building software than we
| used to be (where "we" is the industry overall). It's like
| every single organization larger than a dozen people got
| _way_ worse at building software, pretty suddenly, some time
| between about 2005 and 2010.
| refulgentis wrote:
| Usable is carrying the weight of the world in that sentence.
| simonw wrote:
| The Playwright browser automation framework already has backends
| for Chromium, WebKit and Firefox.
|
| I wonder what it would take to build a Servo backend?
|
| Could be a really fun way to experiment with its capabilities.
___________________________________________________________________
(page generated 2023-12-18 23:01 UTC)