16 ms·

Servo, the parallel browser engine written in Rust

340 points by manx 3y ago

coldtea 3y ago
[flagged]
- GeertJohan 3y ago
  Not sure if sarcasm or..? Can you elaborate?
erk__ 3y ago
It should be noted that development has been getting up in gear again mostly by Igalia after some external funding.
- pabs3 3y ago
  Who are the new funders for Igalia's work?
  - capableweb 3y ago
    > Igalia is a private, worker-owned, employee-run cooperative model consultancy focused on open source software. Based in A Coruña, Galicia (Spain), Igalia is known for its contributions and commitments to both open-source and open standards. Igalia's primary focus is on open source solutions for a large set of hardware and software platforms centering on browsers, graphics, multimedia, compilers, device drivers, virtualization, embedded Linux, and device drivers. https://en.wikipedia.org/wiki/Igalia https://en.wikipedia.org/wiki/Igalia https://people.igalia.com/mrego/servo/igalia-servo-tsc-2022/ https://people.igalia.com/mrego/servo/igalia-servo-tsc-2022/ Seemingly, they are funding this work themselves, probably from income from the consultancy. Edit: Also, seems Igalia received public funding, the latest one in 2022. In Spanish: https://www.igalia.com/public-funding-projects/public-funding-2022.html https://www.igalia.com/public-funding-projects/public-fundin...
    - afiori 3y ago
      From what I gathered from a few podcasts it is mostly employee driven championing of priorities and croudfunding
      - password4321 3y ago
        Maybe "this is the way" to fund an alternative browser!
        ktosobcy 3y ago
        One wonders if there would be more user donations to Firefox if those were directly going to browser development and not to mozilla...
        orra 3y ago
        I don't see how this Mozilla hate is relevant. Igalia aren't ordinary users: they're developers.
      - HyperSane 3y ago
        I wish most companies were run this way.
- fmiras 3y ago
  This is awesome to hear, thanks Igalia
samsquire 3y ago
Is compositing different bitmaps an embarrassingly parallel problem? I started writing a simple layout engine based on the ORCSolver white paper but I wonder how layout can be parallelized. https://GitHub.com/samsquire/browser https://GitHub.com/samsquire/browser I always thought servers could prelayout the HTML to determine X and Ys and widths for different browser viewport sizes and this metadata would speed up layout because you have a good candidate for layout immediately. When it comes to changing the DOM and reflow, I wonder if you can reflow against the row only into chunks of the screen and recomposite bitmaps to move elements down the screen. Some web pages are really pathological with relayout costs
- TuringTest 3y ago
  > Is compositing different bitmaps an embarrassingly parallel problem? If you can make an initial approximate guess of the area for each section, you can split regions with lower and upper size constraints that can be laid out in parallel. A global branch and bound algorithm can coordinate those processes, tightening the upper constraints of one region when another connected region exceededs its minimum bounds. Indeed there still may be degenerate cases where multiple regions need to be recalculated several times, but overall the default case should be able to finish without much conflict.
- benreesman 3y ago
  I’ve been out of the browser rendering engine game for a long time. But even back in the day, the various ways that a DOM element’s physical layout could escape its parent’s bounding box, the multiple stages of coordinate evaluation, the zillion edge cases: it’s hard. And that’s assuming that all inputs are perfectly formed. By the time you’ve cranked in enough Poe’s Law to be more than a tech demo, and enough performance to interest anyone? It’s one of the nastiest practical problems you’ll encounter in a long career and the cross product of the kooky standard and the bugs you have to honor on the real web, a back compat story worse than Win32 mean that there’s no One Elegant Answer. It’s a fucking mess and my hat is tipped to the hard-ass veterans who can even make a credible attempt. I’d rather be on the hook for a modern RDBMS than a modern browser.
  - 3y ago
fooker 3y ago
Cautionary tale for the ‘rewrite it in Rust’ camp
- sebzim4500 3y ago
  I think it's mainly a cautionary tale for the "let's write a browser engine" camp.
  - pavlov 3y ago
    If anything, it’s an encouraging tale for the “let’s invent a new language for our rewrite of a complex application” camp. The rewrite failed but the language lives on because the problem was general enough.
    - fooker 3y ago
      Most programming languages were born out of such a need, not necessarily just the successful ones.
      - cookieperson 3y ago
        Rust is doing just fine. And your original comment is specieous at best.
    - GeekyBear 3y ago
      > The rewrite failed Servo code, written in Rust, to enable the use of multiple CPU cores to speed up rendering was merged into Firefox quite a few years ago. https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/ https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en... Also, shout out to Lin Clark, whose blog posts for Mozilla back in the day set a high bar.
      - pavlov 3y ago
        Fair enough. My impression was that Servo didn’t meet its original goals. Whether that counts as failure is a mindset question, I suppose.
eis 3y ago
I think it would be great if the homepage could have a prominent link to the documentation as it wasn't obvious to me where to find it. I followed the link to Github which in the readme has a howto for building the project and there is a docs folder which has a few documents mostly with dealing how to get started contributing. In the end I think a good entry seems to tbe the Wiki on Github: https://github.com/servo/servo/wiki https://github.com/servo/servo/wiki I would also love to have a clear overview page that shows a high level view of the state of the engine in terms of feature support/completeness. I'd love to see the project getting revitalized and gain traction now that it is outside Mozilla and maybe maybe eventually a new phoenix might rise.
paulrouget 3y ago
Rust helped Servo. But Servo also helped Rust: I encourage people to listen to Josh Matthews interview [0]. He talks about how, early on, Servo was a "guiding light for Rust". 0: https://podcasts.google.com/feed/aHR0cHM6Ly9ydXN0YWNlYW4tc3RhdGlvbi5vcmcvcG9kY2FzdC5yc3M/episode/cnVzdGFjZWFuLXN0YXRpb24vZXBpc29kZS9qb3NoLW1hdHRoZXdzLw https://podcasts.google.com/feed/aHR0cHM6Ly9ydXN0YWNlYW4tc3R...
- GuB-42 3y ago
  Rust is to Servo what C is to UNIX. Even though they live their own lives now, the ties are strong. I think programming languages must be developed with their application. For Rust, it is Servo, Go is for Google, LUA is for scripting video games, Swift is for making iOS apps, and of course C is for UNIX.
  - SanderSantema 3y ago
    Lua wasn’t made for scripting video games but as a scripting language for a mining company if I remember correctly from this excellent paper[1]. I can highly recommend all the other ACM hopl papers too for those interested in the history of programming languages. The papers don’t seem to be open access but sci-hub might help with that if you’re so inclined. [1] https://dl.acm.org/doi/10.1145/3186277 https://dl.acm.org/doi/10.1145/3186277
    - carterschonwald 3y ago
      The hopl paper on lua seems to indicate it came out of a Brazil university. https://www.lua.org/doc/hopl.pdf https://www.lua.org/doc/hopl.pdf
      - airstrike 3y ago
        Indeed. It was created at PUC-Rio, my alma mater
      - tomjakubowski 3y ago
        Lua means moon in Portuguese! (cognate of Luna)
amelius 3y ago
Cynical prediction: by the time this project is finished, the entire rendering of browsers happens in the GPU.
- psychphysic 3y ago
  Is this now intended to be a full featured browser? That'd be great. Last I checked this was going to be a sandbox for Rust ideas with no intention of Gecko bring dropped by Firefox. It would be cool if it could at least be a "secure" window with heavy restrictions on add-ons etc. Not full featured, maybe not even much hardware acceleration. Just a single window that is super hardened.
- maksimur 3y ago
  I hope not, unless GPUs become cheaper.
  - capableweb 3y ago
    How much cheaper can they get? Most laptops have CPUs/boards with integrated GPUs, and desktop GPUs can be bought for very cheap, as long as you don't buy the latest greatest edition of everything.
  - rollcat 3y ago
    It's hard to lose on this one: even an underpowered, integrated GPU will probably do a better job than an average CPU. Desktops have figured this out a while ago, both OSX and Windows have been rendering on the GPU for a very long time and it's not necessarily to enable any extra graphical effects, but just to make the interaction faster, smoother, and more energy-efficient.
- the_third_wave 3y ago
  Who knows? A rendering engine will still be needed though so another prediction could be that Servo supports such GPU-based rendering. Maybe a better prediction would be for the CPU/GPU/MPU/APU/xPU distinction to become less relevant since processors will gain those capabilities? A future where processors come in chiplet-based packages with a few generic cores and some more tailored to massively parallel matrix processing maybe?
the_third_wave 3y ago
[dead]
doublerabbit 3y ago
Just to think, if every developer got together and contributed a single line of code to a new internet stack/browser/protocol project we could overtake the corporation poison that's current spreading within the web-space.
- meindnoch 3y ago
  Ok, here's my contribution: exit(1)
- ReactiveJelly 3y ago
  But, and I mean this un-ironically, what's in it for me?
  - TuringTest 3y ago
    Classics are worth revisiting http://www.pera.net/Stonesoup.html http://www.pera.net/Stonesoup.html
- o1y32 3y ago
  If there is such a project where every developer can contribute one single line, the result is inevitably that the codebase is a horrible unmaintainable mess. Sorry this is the stupidest thing I have seen this morning.
  - doublerabbit 3y ago
    Lack of coffee. Sounded better in my head. The dream of that everyone could get together and make an internet utopia without corporate input would be a pleasing moment. That was the illusion I was trying to make. The internet is so bogged down by corporate walled gardens that nothing is individual anymore. Not to say they don't exist but have an very minute presence.
jmyeet 3y ago
Here is a good article on how important Servo was to the early development of Rust and the feedback loop between the two [1]. I find it interesting to see how Rust chose run-time over compile-time. Some of this is completely understandable (eg the whole borrow-checking mechanism that is so valuable). Generally though, I've found you want to favor compile-time, particularly incremental compile-time. It's better to get something to work first and then optimize performance later than the other way around. [1]: https://pingcap.medium.com/the-rust-compilation-model-calamity-1a8ce781cf6c https://pingcap.medium.com/the-rust-compilation-model-calami...
- ReactiveJelly 3y ago
  OTOH, dev machines are usually beefier and fewer in number than prod machines. So if you can give yourself head room to make prod _really_ fast, in a few years the dev systems may double in power anyway. Incremental compiles are a common source of bugs, right? I find it's easy to do something from scratch (like imgui painting the whole window every frame) and hard to optimize it not to (like damage in GUIs)
  - cookieperson 3y ago
    Thread ripper with nvme drives for rust development make compile times a giggle. Not sure what you mean by bugs due to incremental compilation? I've never seen it happen anyways.
    - kbrosnan 3y ago
      Happens with some frequency with building Gecko. You can see documented instances of it for the CLOBBER file. It allows the person building to optionally have the build system force a clean rebuild. https://hg.mozilla.org/mozilla-central/log/tip/CLOBBER https://hg.mozilla.org/mozilla-central/log/tip/CLOBBER https://firefox-source-docs.mozilla.org/build/buildsystem/mozconfigs.html#mk-add-options https://firefox-source-docs.mozilla.org/build/buildsystem/mo...
- jeltz 3y ago
  > It's better to get something to work first and then optimize performance later than the other way around. As far as I gather that is one of the issues why Rust is slow to compile. Fast compilers were usually built with performance in mind from the very start while rustc was first made work and then optimized.
smarkov 3y ago
Without downplaying all the effort being put into this, I think we're just digging a deeper hole. Websites do more or less the same thing they did 15 years ago but they are now 20 times more complex to develop and maintain. A good amount of developers would rather donate a kidney than write CSS. Accessibility is a hack. Performance is getting worse despite us having better than ever hardware. We're spending large amounts of time reinventing the wheel. JS is a horrible, bare bones language which is why you can't get anything done without 100 packages. It's time to move away from HTML/CSS/JS. They worked great for as long as they did but instead of further contributing to the mess that they've become, we should be looking into alternatives.
- capableweb 3y ago
  > Without downplaying all the effort being put into this > Websites do more or less the same thing they did 15 years ago That is a huge downplay if anything :) Websites certainly does the same they always done, the difference nowadays is that there are web apps too, interactive applications, which existed 15 years ago sure, but they didn't have the same scale as today. But, most web apps today should just be websites, but there are some use cases for web apps too, although they are few. Once you start to understand there is a difference between websites and web apps, things start to make sense. There is still a huge misuse of making things into web apps, but at least you start to understand why the ecosystem moves in a direction you seemingly don't grasp. > It's time to move away from HTML/CSS/JS. They worked great for as long as they did but instead of further contributing to the mess that they've become, we should be looking into alternatives. There is huge efforts into this already, which you also seem to have missed. The whole WASM effort is about being able to write code for browsers in any language you want, and it's already usable today. It's missing some vital things like DOM manipulation to be 100x more useful, but again, still useful today. Lots of games are written in Rust and deployed as WASM for example, runnable in the browser.
- o1y32 3y ago
  The second paragraph is just simply plain wrong throughout. You should actually learn the web stack and look at how things work in 2023 instead of reading other people's rants or secondhand opinions to form your own opinions. CSS is not hard. Performance talking is meaningless without benchmarks. No, you can definitely build a decent small website with a few or even no package dependencies. Maybe do a reality check first. > It's time to move away from HTML/CSS/JS Just meaningless empty talks over and over on HN. People who don't understand web stacks ranting about web without knowing the complexity and nuances. What alternatives do you have? Are they going to provide enough features and customization as the status quo? Will this new thing achieve at least 80% of development speed? Many companies adopted web stack for their application because of the flexibility and time to deliver. They make products, instead of being a purist
Alifatisk 3y ago
What do they mean by ”parallel browser engine”? That it runs in multicore? Also, what’s fhe goal with Servo? I am all for new browser engines to compete against Chromes monopoly!
- HellDunkel 3y ago
  I think it was designed as the next level browser engine to work with firefox, making heavy use of gpus (probably for mobile). Then things got stuck.
Terretta 3y ago
The recent overall assessment work is fantastic. Every project should do this from time to time, as a heads up reset and refocus. I'll be using the report comparing layout engines as an exemplar for teams thinking about undertaking or already working on migrations. Overall report: https://github.com/servo/servo/wiki/Servo-Layout-Engines-Report https://github.com/servo/servo/wiki/Servo-Layout-Engines-Rep... Feature by feature details: https://github.com/servo/servo/wiki/Layout-2020-and-2013-parity https://github.com/servo/servo/wiki/Layout-2020-and-2013-par... TL;DR on the report: Neither Layout 2013 nor Layout 2020 fully support widely used features like flexbox, grids, or a reliable float implementation. This report proposes focusing on improving Layout 2020, but until the project benefits from the renewed energy and focus it's not ready for projects needing these.
nologic01 3y ago
Could Servo be used to build desktop webview type apps that can leverage all the html/js/css libraries that are available? The main complaint people seem to have about this approach is the large size of the executable, I don't know if Servo can make a different in this respect.
- Al0neStar 3y ago
  I'm not sure if it can support all the libraries but yes it can be used to make desktop apps. Theres also Sciter. https://sciter.com/ https://sciter.com/
  - throwaway290 3y ago
    It's not open source and there is nothing about Servo from what I could find
    - Al0neStar 3y ago
      Seems like they have plans for Q4 2023 https://servo.org/about/ https://servo.org/about/
  - wongarsu 3y ago
    I really like sciter for webview-type apps. It's really lightweight, integrates well with native code, and brings some native-app concepts to JS (like the communication between multiple app windows). Sure, it's not open source, but you can have the source code if you pay for it, I can respect that. My main issue is that it's lacking some of the DOM API. It's complete enough that you wouldn't really notice when writing code yourself, but good luck finding a charting library that runs without modifications.
  - rice7th 3y ago
    Sciter is very interesting. It uses a custom rendering engine with a custom fork of QuickJS. Extremely lightweight and fast. Quite a nice project honestly.
- conradludgate 3y ago
tgtweak 3y ago
A quick test-run on the pages linked from the hackernews front page: hackernews svg logo doesn't render youtube embed on the servo homepage doesn't load https://github.com/tpope/timl https://github.com/tpope/timl -> reloads/rerenders infinitely, uses 100% of 1 core https://akrzemi1.wordpress.com/2023/04/23/the-obvious-final-step/ https://akrzemi1.wordpress.com/2023/04/23/the-obvious-final-... -> hangs while loading the page, uses 100% of 1 core https://equalitytime.github.io/FlowersForTuring/ https://equalitytime.github.io/FlowersForTuring/ -> loads/renders fine https://github.com/reactos/reactos https://github.com/reactos/reactos -> reloads/rerenders infinitely, uses 100% of 1 core https://dolphin-emu.org/blog/2023/05/27/dolphin-steam-indefinitely-postponed/ https://dolphin-emu.org/blog/2023/05/27/dolphin-steam-indefi... -> loads fine but css rendering/placement is off on breadcrumbs and article https://xcp-ng.org/blog/2023/05/23/new-xen-updates-on-risc-v/ https://xcp-ng.org/blog/2023/05/23/new-xen-updates-on-risc-v... -> very long load then hangs while loading javascript/content. Not a great batting average - seems like sites need to be purpose built for this or leverage little/no modern javascript libraries for it to render accurately. Servo has been in this state for the last 5 or 6 years since I first discovered it.
- pohl 3y ago
  Over how many of those years was there any active development, though? It just re-started recently.
  - dathinab 3y ago
    and before it was restarted it wasn't even meant to ever become a full fledged stand alone browser at all...
- brundolf 3y ago
  It isn't production-ready and I don't think it claims to be
- kramerger 3y ago
  How does that compare to ladybird? https://awesomekling.github.io/Ladybird-a-new-cross-platform-browser-project/ https://awesomekling.github.io/Ladybird-a-new-cross-platform...
botanical 3y ago
How come since Mozilla let this go, it gets so much engagement through opening of issues? Which types of people are using this?
- capableweb 3y ago
  Mozilla laid off ~25% of their workforce, the Servo team was mostly (maybe even all?) fired in that layoff. https://www.cnet.com/tech/computing/mozilla-cutting-250-jobs-after-coronavirus-pandemic-cuts-revenue/ https://www.cnet.com/tech/computing/mozilla-cutting-250-jobs... Comments at the time: https://news.ycombinator.com/item?id=24128865 https://news.ycombinator.com/item?id=24128865 (Mozilla Fires Servo Devs and Security Response Teams) https://news.ycombinator.com/item?id=24120336 https://news.ycombinator.com/item?id=24120336 (Mozilla lays off 250 employees while it refocuses on commercial products) In the end, I think Servo is better served by being in the Linux Foundation rather than under Mozilla, as Mozilla seems to stray further and further from the path they were walking a decade ago, sadly.
  - wongarsu 3y ago
    Servo seemed like a great project for Firefox. Both in the near term, by merging parts of servo like the CSS engine, and in the long term by promising a much better rendering engine than anything else on the market. But sadly good for Firefox doesn't mean good for Mozilla. Making a great browser isn't necessarily their highest priority.
    - kvark 3y ago
      The CSS engine as well as new renderer from Servo has made it into Firefox successfully. Servo has served well.
- ktosobcy 3y ago
  well...look at thunderbird - mozilla basically let it go as well and it made spectacular come back with a huge funding from users / community... as if user do like to contribute directly to the software development and not the mozilla org with it's weird golas... food for though...
insanitybit 3y ago
Servo will forever be a testament to Mozilla's absolute failure as an organization. Finally there was a renewed interest in Firefox as a technology and their dipshit CEO fired them all "because covid" while taking their largest ever bonus. I hope that it can become something more than that, but I'll always remember it.
- surajrmal 3y ago
  Technology doesn't matter if it doesn't convert users. Perhaps the improvements were too small given the level of investment necessary and given the bleak outlook, they decided they couldn't keep it up. I am happier knowing Mozilla will live to see another day than see it die off. As far as pay goes, the Mozilla board ultimately is in charge of setting that. I'm not sure it makes sense to blame the CEO for taking the compensation they were promised. The fact it is correlated with layoffs just speaks to the large incentives those in charge throw at the CEO to perform layoffs when necessary.
  - ptx 3y ago
    The technology is what matters to users. Mozilla only matters in that they develop and publish the software that users care about. If the software is forked and development is continued as an open source project under the auspices of another organization, that works just as well for users. Conversely, if the software dies but the Mozilla Corporation survives as the world's leading manufacturer of paperclips, that's of no value to the software's users.
  - ohgodplsno 3y ago
    the Mozilla Board is a living proof that the following keywords in absolutely any leadership position are a death sentence: Stanford, Harvard, McKinsey. The Mozilla board are sycophanths that prop eachother up in the various boards they are each a part of to leech off as much as they can before jumping ship to another. https://www.mozilla.org/en-US/about/leadership/boards-of-directors/ https://www.mozilla.org/en-US/about/leadership/boards-of-dir... None of these people have demonstrated any leadership ability, nor justified a single dollar of their pay.
  - 3y ago
BSEdlMMldESB 3y ago
[flagged]

340 points by manx 3y ago

coldtea 3y ago

[flagged]

GeertJohan 3y ago
Not sure if sarcasm or..? Can you elaborate?

erk__ 3y ago

It should be noted that development has been getting up in gear again mostly by Igalia after some external funding.

pabs3 3y ago
Who are the new funders for Igalia's work?
- capableweb 3y ago
  > Igalia is a private, worker-owned, employee-run cooperative model consultancy focused on open source software. Based in A Coruña, Galicia (Spain), Igalia is known for its contributions and commitments to both open-source and open standards. Igalia's primary focus is on open source solutions for a large set of hardware and software platforms centering on browsers, graphics, multimedia, compilers, device drivers, virtualization, embedded Linux, and device drivers. https://en.wikipedia.org/wiki/Igalia https://en.wikipedia.org/wiki/Igalia https://people.igalia.com/mrego/servo/igalia-servo-tsc-2022/ https://people.igalia.com/mrego/servo/igalia-servo-tsc-2022/ Seemingly, they are funding this work themselves, probably from income from the consultancy. Edit: Also, seems Igalia received public funding, the latest one in 2022. In Spanish: https://www.igalia.com/public-funding-projects/public-funding-2022.html https://www.igalia.com/public-funding-projects/public-fundin...
  - afiori 3y ago
    From what I gathered from a few podcasts it is mostly employee driven championing of priorities and croudfunding
    - password4321 3y ago
      Maybe "this is the way" to fund an alternative browser!
      - ktosobcy 3y ago
        One wonders if there would be more user donations to Firefox if those were directly going to browser development and not to mozilla...
        orra 3y ago
        I don't see how this Mozilla hate is relevant. Igalia aren't ordinary users: they're developers.
    - HyperSane 3y ago
      I wish most companies were run this way.
fmiras 3y ago
This is awesome to hear, thanks Igalia

samsquire 3y ago

Is compositing different bitmaps an embarrassingly parallel problem? I started writing a simple layout engine based on the ORCSolver white paper but I wonder how layout can be parallelized. https://GitHub.com/samsquire/browser https://GitHub.com/samsquire/browser I always thought servers could prelayout the HTML to determine X and Ys and widths for different browser viewport sizes and this metadata would speed up layout because you have a good candidate for layout immediately. When it comes to changing the DOM and reflow, I wonder if you can reflow against the row only into chunks of the screen and recomposite bitmaps to move elements down the screen. Some web pages are really pathological with relayout costs

TuringTest 3y ago
> Is compositing different bitmaps an embarrassingly parallel problem? If you can make an initial approximate guess of the area for each section, you can split regions with lower and upper size constraints that can be laid out in parallel. A global branch and bound algorithm can coordinate those processes, tightening the upper constraints of one region when another connected region exceededs its minimum bounds. Indeed there still may be degenerate cases where multiple regions need to be recalculated several times, but overall the default case should be able to finish without much conflict.
benreesman 3y ago
I’ve been out of the browser rendering engine game for a long time. But even back in the day, the various ways that a DOM element’s physical layout could escape its parent’s bounding box, the multiple stages of coordinate evaluation, the zillion edge cases: it’s hard. And that’s assuming that all inputs are perfectly formed. By the time you’ve cranked in enough Poe’s Law to be more than a tech demo, and enough performance to interest anyone? It’s one of the nastiest practical problems you’ll encounter in a long career and the cross product of the kooky standard and the bugs you have to honor on the real web, a back compat story worse than Win32 mean that there’s no One Elegant Answer. It’s a fucking mess and my hat is tipped to the hard-ass veterans who can even make a credible attempt. I’d rather be on the hook for a modern RDBMS than a modern browser.
- 3y ago

fooker 3y ago

Cautionary tale for the ‘rewrite it in Rust’ camp

sebzim4500 3y ago
I think it's mainly a cautionary tale for the "let's write a browser engine" camp.
- pavlov 3y ago
  If anything, it’s an encouraging tale for the “let’s invent a new language for our rewrite of a complex application” camp. The rewrite failed but the language lives on because the problem was general enough.
  - fooker 3y ago
    Most programming languages were born out of such a need, not necessarily just the successful ones.
    - cookieperson 3y ago
      Rust is doing just fine. And your original comment is specieous at best.
  - GeekyBear 3y ago
    > The rewrite failed Servo code, written in Rust, to enable the use of multiple CPU cores to speed up rendering was merged into Firefox quite a few years ago. https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-engine-quantum-css-aka-stylo/ https://hacks.mozilla.org/2017/08/inside-a-super-fast-css-en... Also, shout out to Lin Clark, whose blog posts for Mozilla back in the day set a high bar.
    - pavlov 3y ago
      Fair enough. My impression was that Servo didn’t meet its original goals. Whether that counts as failure is a mindset question, I suppose.

eis 3y ago

I think it would be great if the homepage could have a prominent link to the documentation as it wasn't obvious to me where to find it. I followed the link to Github which in the readme has a howto for building the project and there is a docs folder which has a few documents mostly with dealing how to get started contributing. In the end I think a good entry seems to tbe the Wiki on Github: https://github.com/servo/servo/wiki https://github.com/servo/servo/wiki I would also love to have a clear overview page that shows a high level view of the state of the engine in terms of feature support/completeness. I'd love to see the project getting revitalized and gain traction now that it is outside Mozilla and maybe maybe eventually a new phoenix might rise.

paulrouget 3y ago

Rust helped Servo. But Servo also helped Rust: I encourage people to listen to Josh Matthews interview [0]. He talks about how, early on, Servo was a "guiding light for Rust". 0: https://podcasts.google.com/feed/aHR0cHM6Ly9ydXN0YWNlYW4tc3RhdGlvbi5vcmcvcG9kY2FzdC5yc3M/episode/cnVzdGFjZWFuLXN0YXRpb24vZXBpc29kZS9qb3NoLW1hdHRoZXdzLw https://podcasts.google.com/feed/aHR0cHM6Ly9ydXN0YWNlYW4tc3R...

GuB-42 3y ago
Rust is to Servo what C is to UNIX. Even though they live their own lives now, the ties are strong. I think programming languages must be developed with their application. For Rust, it is Servo, Go is for Google, LUA is for scripting video games, Swift is for making iOS apps, and of course C is for UNIX.
- SanderSantema 3y ago
  Lua wasn’t made for scripting video games but as a scripting language for a mining company if I remember correctly from this excellent paper[1]. I can highly recommend all the other ACM hopl papers too for those interested in the history of programming languages. The papers don’t seem to be open access but sci-hub might help with that if you’re so inclined. [1] https://dl.acm.org/doi/10.1145/3186277 https://dl.acm.org/doi/10.1145/3186277
  - carterschonwald 3y ago
    The hopl paper on lua seems to indicate it came out of a Brazil university. https://www.lua.org/doc/hopl.pdf https://www.lua.org/doc/hopl.pdf
    - airstrike 3y ago
      Indeed. It was created at PUC-Rio, my alma mater
    - tomjakubowski 3y ago
      Lua means moon in Portuguese! (cognate of Luna)

amelius 3y ago

Cynical prediction: by the time this project is finished, the entire rendering of browsers happens in the GPU.

psychphysic 3y ago
Is this now intended to be a full featured browser? That'd be great. Last I checked this was going to be a sandbox for Rust ideas with no intention of Gecko bring dropped by Firefox. It would be cool if it could at least be a "secure" window with heavy restrictions on add-ons etc. Not full featured, maybe not even much hardware acceleration. Just a single window that is super hardened.
maksimur 3y ago
I hope not, unless GPUs become cheaper.
- capableweb 3y ago
  How much cheaper can they get? Most laptops have CPUs/boards with integrated GPUs, and desktop GPUs can be bought for very cheap, as long as you don't buy the latest greatest edition of everything.
- rollcat 3y ago
  It's hard to lose on this one: even an underpowered, integrated GPU will probably do a better job than an average CPU. Desktops have figured this out a while ago, both OSX and Windows have been rendering on the GPU for a very long time and it's not necessarily to enable any extra graphical effects, but just to make the interaction faster, smoother, and more energy-efficient.
the_third_wave 3y ago
Who knows? A rendering engine will still be needed though so another prediction could be that Servo supports such GPU-based rendering. Maybe a better prediction would be for the CPU/GPU/MPU/APU/xPU distinction to become less relevant since processors will gain those capabilities? A future where processors come in chiplet-based packages with a few generic cores and some more tailored to massively parallel matrix processing maybe?

the_third_wave 3y ago

[dead]

doublerabbit 3y ago

Just to think, if every developer got together and contributed a single line of code to a new internet stack/browser/protocol project we could overtake the corporation poison that's current spreading within the web-space.

meindnoch 3y ago
Ok, here's my contribution: exit(1)
ReactiveJelly 3y ago
But, and I mean this un-ironically, what's in it for me?
- TuringTest 3y ago
  Classics are worth revisiting http://www.pera.net/Stonesoup.html http://www.pera.net/Stonesoup.html
o1y32 3y ago
If there is such a project where every developer can contribute one single line, the result is inevitably that the codebase is a horrible unmaintainable mess. Sorry this is the stupidest thing I have seen this morning.
- doublerabbit 3y ago
  Lack of coffee. Sounded better in my head. The dream of that everyone could get together and make an internet utopia without corporate input would be a pleasing moment. That was the illusion I was trying to make. The internet is so bogged down by corporate walled gardens that nothing is individual anymore. Not to say they don't exist but have an very minute presence.

jmyeet 3y ago

Here is a good article on how important Servo was to the early development of Rust and the feedback loop between the two [1]. I find it interesting to see how Rust chose run-time over compile-time. Some of this is completely understandable (eg the whole borrow-checking mechanism that is so valuable). Generally though, I've found you want to favor compile-time, particularly incremental compile-time. It's better to get something to work first and then optimize performance later than the other way around. [1]: https://pingcap.medium.com/the-rust-compilation-model-calamity-1a8ce781cf6c https://pingcap.medium.com/the-rust-compilation-model-calami...

ReactiveJelly 3y ago
OTOH, dev machines are usually beefier and fewer in number than prod machines. So if you can give yourself head room to make prod _really_ fast, in a few years the dev systems may double in power anyway. Incremental compiles are a common source of bugs, right? I find it's easy to do something from scratch (like imgui painting the whole window every frame) and hard to optimize it not to (like damage in GUIs)
- cookieperson 3y ago
  Thread ripper with nvme drives for rust development make compile times a giggle. Not sure what you mean by bugs due to incremental compilation? I've never seen it happen anyways.
  - kbrosnan 3y ago
    Happens with some frequency with building Gecko. You can see documented instances of it for the CLOBBER file. It allows the person building to optionally have the build system force a clean rebuild. https://hg.mozilla.org/mozilla-central/log/tip/CLOBBER https://hg.mozilla.org/mozilla-central/log/tip/CLOBBER https://firefox-source-docs.mozilla.org/build/buildsystem/mozconfigs.html#mk-add-options https://firefox-source-docs.mozilla.org/build/buildsystem/mo...
jeltz 3y ago
> It's better to get something to work first and then optimize performance later than the other way around. As far as I gather that is one of the issues why Rust is slow to compile. Fast compilers were usually built with performance in mind from the very start while rustc was first made work and then optimized.

smarkov 3y ago

Without downplaying all the effort being put into this, I think we're just digging a deeper hole. Websites do more or less the same thing they did 15 years ago but they are now 20 times more complex to develop and maintain. A good amount of developers would rather donate a kidney than write CSS. Accessibility is a hack. Performance is getting worse despite us having better than ever hardware. We're spending large amounts of time reinventing the wheel. JS is a horrible, bare bones language which is why you can't get anything done without 100 packages. It's time to move away from HTML/CSS/JS. They worked great for as long as they did but instead of further contributing to the mess that they've become, we should be looking into alternatives.

capableweb 3y ago
> Without downplaying all the effort being put into this > Websites do more or less the same thing they did 15 years ago That is a huge downplay if anything :) Websites certainly does the same they always done, the difference nowadays is that there are web apps too, interactive applications, which existed 15 years ago sure, but they didn't have the same scale as today. But, most web apps today should just be websites, but there are some use cases for web apps too, although they are few. Once you start to understand there is a difference between websites and web apps, things start to make sense. There is still a huge misuse of making things into web apps, but at least you start to understand why the ecosystem moves in a direction you seemingly don't grasp. > It's time to move away from HTML/CSS/JS. They worked great for as long as they did but instead of further contributing to the mess that they've become, we should be looking into alternatives. There is huge efforts into this already, which you also seem to have missed. The whole WASM effort is about being able to write code for browsers in any language you want, and it's already usable today. It's missing some vital things like DOM manipulation to be 100x more useful, but again, still useful today. Lots of games are written in Rust and deployed as WASM for example, runnable in the browser.
o1y32 3y ago
The second paragraph is just simply plain wrong throughout. You should actually learn the web stack and look at how things work in 2023 instead of reading other people's rants or secondhand opinions to form your own opinions. CSS is not hard. Performance talking is meaningless without benchmarks. No, you can definitely build a decent small website with a few or even no package dependencies. Maybe do a reality check first. > It's time to move away from HTML/CSS/JS Just meaningless empty talks over and over on HN. People who don't understand web stacks ranting about web without knowing the complexity and nuances. What alternatives do you have? Are they going to provide enough features and customization as the status quo? Will this new thing achieve at least 80% of development speed? Many companies adopted web stack for their application because of the flexibility and time to deliver. They make products, instead of being a purist

Alifatisk 3y ago

What do they mean by ”parallel browser engine”? That it runs in multicore? Also, what’s fhe goal with Servo? I am all for new browser engines to compete against Chromes monopoly!

HellDunkel 3y ago
I think it was designed as the next level browser engine to work with firefox, making heavy use of gpus (probably for mobile). Then things got stuck.

Terretta 3y ago

The recent overall assessment work is fantastic. Every project should do this from time to time, as a heads up reset and refocus. I'll be using the report comparing layout engines as an exemplar for teams thinking about undertaking or already working on migrations. Overall report: https://github.com/servo/servo/wiki/Servo-Layout-Engines-Report https://github.com/servo/servo/wiki/Servo-Layout-Engines-Rep... Feature by feature details: https://github.com/servo/servo/wiki/Layout-2020-and-2013-parity https://github.com/servo/servo/wiki/Layout-2020-and-2013-par... TL;DR on the report: Neither Layout 2013 nor Layout 2020 fully support widely used features like flexbox, grids, or a reliable float implementation. This report proposes focusing on improving Layout 2020, but until the project benefits from the renewed energy and focus it's not ready for projects needing these.

nologic01 3y ago

Could Servo be used to build desktop webview type apps that can leverage all the html/js/css libraries that are available? The main complaint people seem to have about this approach is the large size of the executable, I don't know if Servo can make a different in this respect.

Al0neStar 3y ago
I'm not sure if it can support all the libraries but yes it can be used to make desktop apps. Theres also Sciter. https://sciter.com/ https://sciter.com/
- throwaway290 3y ago
  It's not open source and there is nothing about Servo from what I could find
  - Al0neStar 3y ago
    Seems like they have plans for Q4 2023 https://servo.org/about/ https://servo.org/about/
- wongarsu 3y ago
  I really like sciter for webview-type apps. It's really lightweight, integrates well with native code, and brings some native-app concepts to JS (like the communication between multiple app windows). Sure, it's not open source, but you can have the source code if you pay for it, I can respect that. My main issue is that it's lacking some of the DOM API. It's complete enough that you wouldn't really notice when writing code yourself, but good luck finding a charting library that runs without modifications.
- rice7th 3y ago
  Sciter is very interesting. It uses a custom rendering engine with a custom fork of QuickJS. Extremely lightweight and fast. Quite a nice project honestly.
conradludgate 3y ago

tgtweak 3y ago

A quick test-run on the pages linked from the hackernews front page: hackernews svg logo doesn't render youtube embed on the servo homepage doesn't load https://github.com/tpope/timl https://github.com/tpope/timl -> reloads/rerenders infinitely, uses 100% of 1 core https://akrzemi1.wordpress.com/2023/04/23/the-obvious-final-step/ https://akrzemi1.wordpress.com/2023/04/23/the-obvious-final-... -> hangs while loading the page, uses 100% of 1 core https://equalitytime.github.io/FlowersForTuring/ https://equalitytime.github.io/FlowersForTuring/ -> loads/renders fine https://github.com/reactos/reactos https://github.com/reactos/reactos -> reloads/rerenders infinitely, uses 100% of 1 core https://dolphin-emu.org/blog/2023/05/27/dolphin-steam-indefinitely-postponed/ https://dolphin-emu.org/blog/2023/05/27/dolphin-steam-indefi... -> loads fine but css rendering/placement is off on breadcrumbs and article https://xcp-ng.org/blog/2023/05/23/new-xen-updates-on-risc-v/ https://xcp-ng.org/blog/2023/05/23/new-xen-updates-on-risc-v... -> very long load then hangs while loading javascript/content. Not a great batting average - seems like sites need to be purpose built for this or leverage little/no modern javascript libraries for it to render accurately. Servo has been in this state for the last 5 or 6 years since I first discovered it.

pohl 3y ago
Over how many of those years was there any active development, though? It just re-started recently.
- dathinab 3y ago
  and before it was restarted it wasn't even meant to ever become a full fledged stand alone browser at all...
brundolf 3y ago
It isn't production-ready and I don't think it claims to be
kramerger 3y ago
How does that compare to ladybird? https://awesomekling.github.io/Ladybird-a-new-cross-platform-browser-project/ https://awesomekling.github.io/Ladybird-a-new-cross-platform...

botanical 3y ago

How come since Mozilla let this go, it gets so much engagement through opening of issues? Which types of people are using this?

capableweb 3y ago
Mozilla laid off ~25% of their workforce, the Servo team was mostly (maybe even all?) fired in that layoff. https://www.cnet.com/tech/computing/mozilla-cutting-250-jobs-after-coronavirus-pandemic-cuts-revenue/ https://www.cnet.com/tech/computing/mozilla-cutting-250-jobs... Comments at the time: https://news.ycombinator.com/item?id=24128865 https://news.ycombinator.com/item?id=24128865 (Mozilla Fires Servo Devs and Security Response Teams) https://news.ycombinator.com/item?id=24120336 https://news.ycombinator.com/item?id=24120336 (Mozilla lays off 250 employees while it refocuses on commercial products) In the end, I think Servo is better served by being in the Linux Foundation rather than under Mozilla, as Mozilla seems to stray further and further from the path they were walking a decade ago, sadly.
- wongarsu 3y ago
  Servo seemed like a great project for Firefox. Both in the near term, by merging parts of servo like the CSS engine, and in the long term by promising a much better rendering engine than anything else on the market. But sadly good for Firefox doesn't mean good for Mozilla. Making a great browser isn't necessarily their highest priority.
  - kvark 3y ago
    The CSS engine as well as new renderer from Servo has made it into Firefox successfully. Servo has served well.
ktosobcy 3y ago
well...look at thunderbird - mozilla basically let it go as well and it made spectacular come back with a huge funding from users / community... as if user do like to contribute directly to the software development and not the mozilla org with it's weird golas... food for though...

insanitybit 3y ago

Servo will forever be a testament to Mozilla's absolute failure as an organization. Finally there was a renewed interest in Firefox as a technology and their dipshit CEO fired them all "because covid" while taking their largest ever bonus. I hope that it can become something more than that, but I'll always remember it.

surajrmal 3y ago
Technology doesn't matter if it doesn't convert users. Perhaps the improvements were too small given the level of investment necessary and given the bleak outlook, they decided they couldn't keep it up. I am happier knowing Mozilla will live to see another day than see it die off. As far as pay goes, the Mozilla board ultimately is in charge of setting that. I'm not sure it makes sense to blame the CEO for taking the compensation they were promised. The fact it is correlated with layoffs just speaks to the large incentives those in charge throw at the CEO to perform layoffs when necessary.
- ptx 3y ago
  The technology is what matters to users. Mozilla only matters in that they develop and publish the software that users care about. If the software is forked and development is continued as an open source project under the auspices of another organization, that works just as well for users. Conversely, if the software dies but the Mozilla Corporation survives as the world's leading manufacturer of paperclips, that's of no value to the software's users.
- ohgodplsno 3y ago
  the Mozilla Board is a living proof that the following keywords in absolutely any leadership position are a death sentence: Stanford, Harvard, McKinsey. The Mozilla board are sycophanths that prop eachother up in the various boards they are each a part of to leech off as much as they can before jumping ship to another. https://www.mozilla.org/en-US/about/leadership/boards-of-directors/ https://www.mozilla.org/en-US/about/leadership/boards-of-dir... None of these people have demonstrated any leadership ability, nor justified a single dollar of their pay.
- 3y ago

BSEdlMMldESB 3y ago

[flagged]