[HN Gopher] Servo's progress in 2024
___________________________________________________________________
Servo's progress in 2024
Author : brson
Score : 272 points
Date : 2025-02-05 15:03 UTC (7 hours ago)
(HTM) web link (servo.org)
(TXT) w3m dump (servo.org)
| qwertox wrote:
| That's great news! I thought the project had died and that this
| meant that V8 was the only serious JavaScript engine for the
| future.
|
| For those who don't know: "Servo is a web browser rendering
| engine written in Rust, with WebGL and WebGPU support, and
| adaptable to desktop, mobile, and embedded applications."
| vanderZwan wrote:
| I'm confused: why would the existence of a _browser engine_
| affect a _JavaScript_ engine? Don 't you mean WebKit/Blink
| instead of V8?
|
| Either way I'm glad that there's a challenge to the browser
| monopoly and its various technical components of course.
| gkbrk wrote:
| Servo just uses SpiderMonkey instead of their own JS engine in
| Rust.
|
| Even without SpiderMonkey, we'd still have JavascriptCore from
| Safari and LibJS from Ladybird.
| wslh wrote:
| I don't see the relevancy of the JS engine in the context of
| a web rendering engine and its independent complexity. The
| homepage of Servo (basically, a portion of the Wikipedia
| entry snapshot) doesn't even mention it.
| kjeetgill wrote:
| Because the parent-most post from quertox was:
|
| > That's great news! I thought the project had died and
| that this meant that V8 was the only serious JavaScript
| engine for the future.
|
| The person you're responding to was basically clarifying
| what you want to too.
| fbouvier wrote:
| And some lightweight alternatives like Bellard's QuickJS
| (https://bellard.org/quickjs/) in C and Kiesel
| (https://kiesel.dev/) in Zig.
| nicoburns wrote:
| Also, Hermes which React Native uses.
| ai-christianson wrote:
| I thought it had died too. Great to see it make a comeback.
| bdhcuidbebe wrote:
| spidermoneky has been around since before V8
| diggan wrote:
| Bit of an understatement. SpiderMonkey was _the_ first
| JavaScript engine (out of all of them), born in 1996, made by
| refactoring the scraps of Mocha that was the initial
| prototype made by Eich.
| madeofpalk wrote:
| > V8 was the only serious JavaScript engine for the future.
|
| Firefox's SpiderMonkey? Webkit's JSC?
| culi wrote:
| Ladybird and Servo are exciting and much needed projects since
| Microsoft abandoned their own independent browser engine to use
| Chromium.
|
| If you didn't know you could see the massive progress both
| projects have made in web compatibility here:
| https://wpt.fyi/results/?label=master&product=chrome&product...
|
| As of today, browsers pass this percent of tests:
| Chrome: 96.82% Firefox: 95.41% Safari: 94.97%
| Ladybird: 89.30% Servo: 78.61%
| materielle wrote:
| One interesting thing covered in the Ladybird monthly update
| videos, is that most of the web platform tests are text
| encoding tests for Asian languages.
|
| If you remove them, Ladybird is closer to 60% and Servo to 50%.
|
| Still good, and the point still stands that they are making
| amazing progress. But probably more accurate because that last
| 10%-20% are going to get harder to chip away at.
| culi wrote:
| That's interesting and it explains why the wpt.fyi website
| doesn't show a percentage but instead the number of tests.
|
| There are tons of other examples of these easy points in the
| test suite. Ofc text encoding tests are important if we want
| the internet to truly be global
|
| I guess these percentages are kinda useless by themselves but
| still useful to track progress when you put them together in
| a historical graph
| wiz21c wrote:
| Are the last percents harder to complete ? (law of diminishing
| returns)
| igrunert wrote:
| For Ladybird - Andreas Kling called out that the vast
| majority of "easy tests" are passing and each additional test
| is going to be more difficult to come by going forward.
|
| https://www.youtube.com/watch?v=-l8epGysffQ (1 minute - 4
| minute)
| culi wrote:
| As another comment pointed out, some of them will never be
| implemented on purpose. These tests aren't all backed by web
| standards. E.g. one test suite is for compatibility with non-
| standard Blink APIs
|
| Also there are new tests being added all the time
| a-dub wrote:
| what ever became of khtml? i remember back in the day it had
| the nicest codebase of all of the browser layout engines.
| madeofpalk wrote:
| Basically became webkit. Which google forked for Blink/Chrome
| yonatan8070 wrote:
| Damn
|
| I was entirely unaware that both Chrome and Safari can
| trace their roots back to KDE of all projects. I always
| just assumed big corpos like Google and Apple would just
| roll their own from scratch.
| pests wrote:
| It was easier to just take a competitors engine, let me
| chase the new web standards, and slap a new UI on it.
| Edge and Opera both use Blink, so also trace back to KDE.
| xnorswap wrote:
| Webkit was forked from khtml, but the original died along
| with Konqueror, which couldn't keep up with javascript API
| changes & performance.
| a-dub wrote:
| lots of relevant interesting reading on the webkit
| wikipedia page: https://en.wikipedia.org/wiki/WebKit
|
| seems it was a quite complicated matter that included
| clashes between open source and commercial concerns.
|
| https://web.archive.org/web/20090210230809/http://www.kdede
| v...
| loeg wrote:
| It eventually forked into Webkit / Chrome.
| JimDabell wrote:
| Be careful you don't mistake that for web standards
| compatibility.
|
| There are many tests in there for non-standard Blink-only APIs
| that Google implemented unilaterally, which both Mozilla and
| Apple rejected on security and privacy grounds.
|
| For instance WebUSB accounts for 845 tests, and WebNFC accounts
| for 173 tests. Neither of these are web standards, they are
| Blink-only Google APIs.
| LeFantome wrote:
| While I don't doubt that there are bogus tests in there,
| looking at how many of them Safari and Firefox pass does not
| indicate that they have rejected many of them.
| JimDabell wrote:
| Web NFC:
|
| > Status of This Document
|
| > This specification was published by the . It is not a W3C
| Standard nor is it on the W3C Standards Track.
|
| -- https://w3c.github.io/web-nfc/
|
| > We oppose this feature and will not implement it.
|
| > We do not believe a permission prompt is a sufficient
| mitigation for the serious security and privacy risks
| raised by this specification. In addition, we think
| exposing direct hardware access to the web is a bad idea
| and compromises the device-independence of the web
| platform.
|
| -- https://lists.webkit.org/pipermail/webkit-
| dev/2020-January/0...
|
| > We believe Web NFC poses risks to users security and
| privacy because of the wide range of functionality of the
| existing NFC devices on which it would be supported,
| because there is no system for ensuring that private
| information is not accidentally exposed other than relying
| on user consent, and because of the difficulty of
| meaningfully asking the user for permission to share or
| write data when the browser cannot explain to the user what
| is being shared or written.
|
| -- https://mozilla.github.io/standards-positions/#web-nfc
|
| WebUSB:
|
| > This specification was published by the Web Platform
| Incubator Community Group. It is not a W3C Standard nor is
| it on the W3C Standards Track.
|
| -- https://wicg.github.io/webusb/
|
| > WebKit declined to implement several APIs, including
| WebUSB, due to concerns over fingerprinting
|
| > We have previously stated privacy concerns, thus the
| concerns: privacy label. We agree with Mozilla's security
| concerns raised in their standards position issue, thus the
| concerns: security label.
|
| -- https://github.com/WebKit/standards-positions/issues/68
|
| > Because many USB devices are not designed to handle
| potentially-malicious interactions over the USB protocols
| and because those devices can have significant effects on
| the computer they're connected to, we believe that the
| security risks of exposing USB devices to the Web are too
| broad to risk exposing users to them or to explain properly
| to end users to obtain meaningful informed consent. It also
| poses risks that sites could use USB device identity or
| data stored on USB devices as tracking identifiers.
|
| -- https://mozilla.github.io/standards-positions/#webusb
| jeltz wrote:
| Yes, they are horrible features that do not belong in a
| browser but they make up at most 1.41% of the test suite.
| ironhaven wrote:
| It may seem like a lot but there are 1.7 million web platform
| tests. Controversial chrome only web apis are few and far
| between the common features
| polyaniline wrote:
| Hasn't Servo been around much longer than Ladybird? Has it
| stagnated?
| kibwen wrote:
| Servo was on a multi-year development hiatus, which is the
| reason this is news (see the graph in the article). In
| addition the original priority of Servo was not to broadly
| implement web standards, it was as a proving ground for Rust
| components to be uplifted into Firefox (I'm unclear whether
| or not those components, which have surely been continually
| developed since then, have been backported into Servo).
| KwanEsq wrote:
| >(I'm unclear whether or not those components, which have
| surely been continually developed since then, have been
| backported into Servo)
|
| I believe the article makes clear that they have.
|
| >Servo main dependencies (SpiderMonkey, Stylo and
| WebRender) have been upgraded
| yonatan8070 wrote:
| These are interesting stats, but it makes me wonder what those
| tests exactly are. Are there 3.18% of tests that no browser
| passes? How applicable are most of these tests to real world
| websites?
| culi wrote:
| No, likely much less than 3.18%. Chrome passes the most but
| there are plenty of tests that only Chrome passes or only
| Chrome doesn't pass
| upcoming-sesame wrote:
| I'm guessing that the "last 5% = 90% of the work" rule applies
| to browser engines as well ?
| Tsarp wrote:
| Wondering how useful this would be for the agentic workflows that
| need browsing. The open deep research tread from yesterday
| mentioned using a pure text based browser sort of thing to
| quickly get info.
| infogulch wrote:
| Like the recently discussed Lightpanda?
|
| Show HN: Lightpanda, an open-source headless browser in Zig |
| 318 points | 11 days ago | 137 comments |
| https://news.ycombinator.com/item?id=42817439
| fbouvier wrote:
| Yes, argentic workflows are one of our use cases for
| Lightpanda.
|
| We skip the graphical rendering of the web page for instant
| startup, fast execution and low resources usage.
| infogulch wrote:
| Can skipping rendering affect website behavior? What
| happens when JS tries to get layout/color information? How
| often does this break a website?
| petesergeant wrote:
| I have to imagine that the vast majority of those workflows are
| going to want to blend into real traffic as much as possible,
| which just means driving Chrome
| jillesvangurp wrote:
| Are there browsers that use servo; or plans to build one? If not,
| who is actually using servo and what for?
| pera wrote:
| Verso: https://news.ycombinator.com/item?id=41215727
| dblohm7 wrote:
| Firefox has used Servo's rendering and styling components for
| years now.
| jillesvangurp wrote:
| Servo was of course based on the servo project in Mozilla.
| But that was discontinued years ago before that project was
| completed. I'm sure Mozilla still uses some of those
| components. But is servo actively contributing back to
| Mozilla at this point or is it more of a fork?
| 0x457 wrote:
| > But that was discontinued years ago before that project
| was completed.
|
| IIRC purpose of Servo when it was Mozilla project was:
|
| - Develop large scale project in rust to see pain points
|
| - Have a test bed for pieces that would later be integrated
| in Firefox
|
| In both cases project succeeded: Quantum CSS (Stylo),
| WebRender, and some smaller components that I don't recall.
| I don't think there was ever a goal of building a full
| consumer-grade browser, at least not within Mozilla.
| nicoburns wrote:
| There is two-way syncing of the shared components
| (primarily Stylo and Webrender). They are primarily
| maintained by Mozilla, but Servo has been contributing some
| changes.
| infogulch wrote:
| I'm convinced that using an embedded browser engine to render app
| UI is the future. Browser rendering engines are so powerful and
| versatile and universal I don't see how they can lose.
|
| "But Electron!" Yes, Electron hasn't taken the world by storm
| because it has two huge deficiencies: 1. It takes an enormous
| amount of resources including ram and disk. 2. It has no native
| DOM API bindings so it takes even more ram and cpu to compile and
| run JS quickly.
|
| I'm excited for the new crop of browser engines because they
| could fix those deficiencies, opening up browser tech to app
| developers without hugely compromising the experience.
| horsawlarway wrote:
| I mean... Just to be clear, Electron has pretty much taken the
| world by storm.
|
| Huge number of Enterprise/productivity apps are shipped on
| Electron.
|
| It's hard to beat the value proposition on the business side if
| you need a website for the product.
| infogulch wrote:
| True but anyone that cares about battery life or runs more
| than one of these apps hates it. So I guess my threshold for
| "taken by storm" is both "very common" and "users don't hate
| it".
| icedrift wrote:
| It is tragic that the only robust solution for cross
| platform apps eats up so much memory and storage but we're
| getting to the point where it's not that big a deal.
| viraptor wrote:
| Java and .Net/Avalonia are right there... Electron is not
| the only cross platform solution.
| akritrime wrote:
| Yeah I was going to comment the same thing. A very big reason
| why we are even having this conversation about a browser
| engine powering native apps is because electron exists. Yes
| it's sub-optimal but that hasn't impeded its conquest in the
| slightest.
| pjmlp wrote:
| If you need a Website, use a browser.
| horsawlarway wrote:
| They do and and they did. You just don't like that they
| used the browser in both places.
| pjmlp wrote:
| My computer already has an browser installed, I am not a
| browser collector.
| horsawlarway wrote:
| Might be better if you were, though.
|
| Personally - I collect quite a few for different things.
| I almost always have at least chrome, firefox, ungoogled-
| chromium, and - recently - ladybird installed.
|
| Not to mention a couple different chromium versions for
| various electron apps (slack, discord, etcher, bitwarden,
| vscode, postman, etc).
|
| Different browsers do different things well, and electron
| does the "desktop app" niche better than the others right
| now. In the same way that ladybird does the "not tracked
| by corporations" part, and firefox does the "still
| supports manifest v2 extensions" part.
|
| You can complain all you'd like (and I recognize you from
| other places hating on electron) and it's fine, but it
| doesn't change incentive structures for the folks
| deploying these, and as a full time linux user... I am SO
| fucking happy to have all the BS apps my company requires
| "just work" on my computers because of electron.
|
| If you don't want to use software developed with
| Electron... more power to ya. Go make that choice. Leave
| the rest of us out of it.
|
| From my side... it'd be great if we can make electron
| suck less (and trust me, I definitely agree that we can),
| but right now... it's still a pretty huge win.
| pjmlp wrote:
| Only one Electron app is tolerated on my computer,
| VSCode, and that is because for some stuff that is the
| only place I get plugins for, and that is about it.
|
| Everything else, if there is a Web app, then I use the
| browser, no need to ship it alongside every single
| application out there.
|
| It is like those garbage mobile apps, that are exactly
| the same website that I can access via the Webbrowser,
| packaged inside a "native" app.
|
| And I say this as someone that works primarly in
| distributed systems and Web.
| eddd-ddde wrote:
| Except that means you're locked in to web APIs.
| pjmlp wrote:
| As it should be.
| KronisLV wrote:
| I mean, most OSes already ship with a WebView component that
| you can use instead of shipping an entire browser runtime.
|
| Wails does that: https://wails.io/
|
| Tauri also does that: https://tauri.app/
|
| That does help with the app sizes quite a bit:
| https://github.com/Elanis/web-to-desktop-framework-compariso...
|
| Sadly it doesn't change the memory usage much so the technology
| is still inherently wasteful, but on a certain level it feels
| like a lost battle - because web technologies often feel like
| the choice of least resistance when you want GUI software that
| will run on a bunch of platforms while not being annoying to
| develop (from the perspective of your run of the mill dev).
| Tmpod wrote:
| > That does help with the app sizes quite a bit:
| https://github.com/Elanis/web-to-desktop-framework-
| compariso...
|
| Interesting resource, thanks!
|
| Was not expecting the start up values for Tauri, they're
| abysmal ._. Welp, at least the executables are small.
| kibwen wrote:
| Tauri uses the native webview on the platform, which is
| presumably why startup values are all over the place. (It's
| also somewhat suspect to the point of warranting
| investigation; even using the native webview there seems no
| reason for something that takes half a second on Windows to
| take 25 seconds on Linux).
| lukevp wrote:
| I had this same observation. My guess is because Tauri
| uses WebGtk and Linux doesn't really have a "native
| webview" so it's kinda shipping the whole thing? The
| startup time seems like Tauri's a non-starter for a lot
| of apps if you want them to be cross platform, had no
| idea this was a thing.
| icedrift wrote:
| Correct me if I'm wrong, but isn't the problem with tauri and
| wails that they are still dependent on the client's native OS
| webview? I know Tauri uses WRY which essentially takes in
| your request, finds the webview present in the client and
| calls a corresponding function. The differences between these
| webviews are vast and you end up with different UIs or
| cobbled together adjustments for each OS to split the
| differences. Fully embedding a browser is extremely storage
| inefficient but it does guarantee apps look identical
| regardless of platform.
| amelius wrote:
| Except on iOS because Apple can't get its sandboxing act
| together.
| taurknaut wrote:
| > Browser rendering engines are so powerful and versatile and
| universal I don't see how they can lose.
|
| Well browsers are pretty damn heavy for an app that won't use
| 99% of its functionality. Maybe some of this can be amortized
| with clever distro work so apps don't have to ship the whole
| runtime but that hasn't happened yet.
|
| (In fact, it's a little odd to me electron is based on chrome
| rather than the WebKit that actually ships with macos.... you
| should be able to ship that sort of app with a few megabytes)
|
| I'd also rather eat glass than be stuck with javascript, easily
| the most frustrating ecosystem I've ever worked with by a very
| wide margin. Just the language is ok, but the build
| pipelines/bundling/transpilation/polyfillls is absolutely
| miserable to work with and lack of a decent standard library
| really hurts. It's crazy how we've basically lifted up the
| concepts of compilation and linking c objects to the world of
| javascript, _just to ship code in a language the browser
| already fully supports_.
|
| Maybe WASM will help but my understanding its use of the DOM is
| quite awkward and still requires javascript usage.
| jampekka wrote:
| How does WASM help with the concepts of compilation and
| linking c objects?
| nicoburns wrote:
| > It has no native DOM API bindings so it takes even more ram
| and cpu to compile and run JS quickly.
|
| By this, do you mean something like a C/C++/Rust API to the
| DOM?
| diath wrote:
| Numerous video games have been doing precisely that for the
| past decade using CEF:
| https://en.wikipedia.org/wiki/Chromium_Embedded_Framework
| ZeWaka wrote:
| s/o to CefGlue, the C# bindings: https://github.com/space-
| wizards/cefglue
| zeroq wrote:
| and before that Scaleform!
| ChocolateGod wrote:
| FiveM uses CEF and let's you replace much of the built in GTA
| V scaleform with it.
|
| It's incredible what can be done but can be far less
| responsive than the scaleform it replaces, but this may
| partially be due to it being a third party mod to the game.
| cyberax wrote:
| > I'm convinced that using an embedded browser engine to render
| app UI is the future.
|
| Sciter exists: https://sciter.com/
|
| And it indeed is great for UI.
| FreezerburnV wrote:
| Has it ever been made easy to use on mobile? That's the big
| thing that's always given me pause on investing heavily in
| using it. Especially since it uses weird syntax in places and
| isn't "just a browser".
| cyberax wrote:
| It works... But it doesn't have a lot of integration. It's
| OK for its main use, a UI framework for primarily C/C++
| programs, rather than a pure JavaScript+HTML host.
|
| A company that I'm advising is using it for their
| industrial IoT control dashboards, and it's great for that
| purpose.
| coldtea wrote:
| > _" But Electron!" Yes, Electron hasn't taken the world by
| storm because it has two huge deficiencies: 1. It takes an
| enormous amount of resources including ram and disk._
|
| Why would an "embedded browser engine" be any better? Electron
| after all is also a browser engine, and that's what makes it
| slow and bloated compared to native UI, not the embedded part
| (by which I asume you mean something like a browser engine
| wrapper widget).
|
| > _2. It has no native DOM API bindings so it takes even more
| ram and cpu to compile and run JS quickly._
|
| Huh?
| rafaelmn wrote:
| >Why would an "embedded browser engine" be any better?
| Electron after all is also a browser engine, and that's what
| makes it slow and bloated compared to native UI, not the
| embedded part (by which I asume you mean something like a
| browser engine wrapper widget).
|
| There are legacy parts of browser layout that make it
| impossible(?) to optimize some rendering while being
| standards compatible. If you just chose a subset that is fast
| to implement and focused on being subset you narrow the scope
| of the project and enable optimizations.
|
| Electron has to implement everything chrome has to support
| even though the apps running in it will never touch it.
|
| Also web engines have to be heavily sandboxed because you
| cannot allow internet code break out of the sandbox.
|
| Native apps shipped with electron already ship Node and just
| waste resources sandboxing stuff with security layers.
| coldtea wrote:
| > _There are legacy parts of browser layout that make it
| impossible(?) to optimize some rendering while being
| standards compatible. If you just chose a subset that is
| fast to implement and focused on being subset you narrow
| the scope of the project and enable optimizations._
|
| Embedded browser engines though are either wrappers for
| Webkit and Blink (thus also including the "legacy parts of
| browser layout that make it impossible(?) to optimize some
| rendering") OR simplistic web rendering engines that are
| not as capable as Chrome/Webkit for layout and not
| compatible with all modern CSS/HTML features.
| rafaelmn wrote:
| But that is where servo can fill the niche, focus on
| modern/fast parts, ignore legacy compatibility.
| viraptor wrote:
| To be fair, there's lots that could be stripped from chrome
| bundled with electron. Nobody's really attempted that yet
| as far as I can tell - but I really hope we'll get there. I
| mean, there's hundreds of compilation options in there, for
| components that will never be used by a simple app.
|
| Does your desktop app need a gyro, webrtc and gamepad
| support? But they're loaded anyway.
| weinzierl wrote:
| _" It has no native DOM API bindings"_
|
| I wish we'd get _direct_ DOM access from WASM anytime but I
| have little hope.
| monroewalker wrote:
| If servo (or something like it) succeeds, would that mean
| potentially being able to swap out chromium in Electron? Would
| that help with performance / application size?
| kibwen wrote:
| Long ago it was a goal of Servo to adhere to the Chromium
| embedding framework, and differentiate itself from Gecko by
| having a good embedding story. I'm unclear whether that is
| still a goal of the modern project, however.
| PartiallyTyped wrote:
| Minor typo: from over an our to under 30
| minutes.
|
| s/our/hour/
| esad wrote:
| I think Servo's killer application would be a mobile-first
| browser for postmarketOS/Mobian/other mobile Linux distros. It's
| a weird vacuum because Firefox has its Android port, but when you
| run Firefox on small linux (touch)screen, the experience is very
| suboptimal. I'd call it unbearable if it wasn't for bunch of
| tweaks in form of
| https://gitlab.postmarketos.org/postmarketOS/mobile-config-f...
|
| Chrome is no better, as it has a very weird hardcoded minimum
| window width of 500px.
| kevingadd wrote:
| The minimum window width is a funny thing, Chrome has been
| steadily raising the minimum every time they make changes to
| the UI. It used to have a minimum around 320px and now on some
| configurations it's nearly 800px. There's an old open bug about
| it where people periodically comment to complain that it was
| raised again.
| spankalee wrote:
| I've long thought its killer feature would be embeddable cross-
| platform UI and native-wrapped web apps like Electron and
| Capacitor. For these cases it doesn't need to render the entire
| public web, but the subset used by the application developers.
| It's a much more tractable problem.
|
| Chrome had a project a long time ago called Razor whose goal
| was to make a 120fps streamlined subset of the web platform for
| those types of use cases. They tried to throw away warts of the
| web that slowed down parsing and rendering like quirks modes,
| floats, negative margins, infinite entity expansion, element
| adoption, and probably most built-in elements, leaving a few
| core built-ins and custom elements.
|
| Razor apps could have run on the web, and in a Razor runtime.
| Unfortunately, IMO, they kept removing things until they
| removed the document, and swapped in Dart for JS and the
| project became Flutter which is not very web-like at all.
|
| I thought Razor was a neat idea, and Servo could really fill
| that space well.
| pests wrote:
| Didn't realize that was the backstory of Flutter, I thought
| this was headed in a different direction.
|
| I heard the YouTube team did something similar for their
| embedded / resource-constrained environments where the client
| just renders barebones HTML/JS and only what is needed is
| implemented in the engine.
| spankalee wrote:
| Yeah, YouTube has minimal engine called Cobalt:
| https://developers.google.com/youtube/cobalt
|
| That's also an unfortunate story, because they've really
| lagged on adding features in the past because they
| generally have no way to update the engine on TVs. So any
| new feature would take 5-10 years to be usable.
|
| So almost 10 years ago they didn't invest in some core
| things like web components, and they could have used them
| by now if they did.
| elcritch wrote:
| Fascinating, and I've been working on a native UI project I
| call Figuro for a couple of years now (1) that's built on the
| idea of simple nodes.
|
| It's surprising how similar to HTML it's becoming. I feel
| like it's sorta an inverse of the Flutter story. Lately I'm
| working on adding a subset of CSS. Adding padding and margins
| too seems like a good idea too, etc. Part of me wonders how
| much of a webpage I could render with it.
|
| 1: https://github.com/elcritch/figuro
| rafaelmn wrote:
| Yes this is the ideal space for a performance minded web
| rendering engine rewrite.
|
| And if you do it well enough as a subset it can become the
| next standard where the modern web is just the subset, you
| can even integrate it with a legacy render where you fall
| back to legacy when you detect you cant handle it, and have
| the fast path for the subset.
| fabrice_d wrote:
| Someone is doing that:
| https://github.com/catacombing/kumo/tree/servo
| PartiallyTyped wrote:
| Huawei is doing that, with their own OS.
| pipeline_peak wrote:
| > I think Servo's killer application would be a mobile-first
| browser for postmarketOS/Mobian/other mobile Linux distros
|
| Are you suggesting that such an app would get people to go out
| of their way and use mobile Linux?
| ramon156 wrote:
| Why the big dip in PRs over the years? Was that the year it got
| discontinued?
___________________________________________________________________
(page generated 2025-02-05 23:00 UTC)