Servo nightly builds on Windows now available | Hacker News Reader

Servo nightly builds on Windows now available

blog.servo.org

351 pointsstshine114 comments

A lot of the Servo work lately has been pushing specific components, in particular the style system and WebRender, toward production quality. (These are the parts that are being integrated into Gecko on an experimental basis.) This is all necessary work for Servo--for instance, we have to have an industrial-grade style system that passes all tests, no matter what. But it doesn't result in immediately-visible improvements as much as some of the stuff we were doing earlier (like the push toward Acid2), as the layout, DOM, and thread manager (constellation) still need lots of work and are usually the source of the brokenness you see from day to day.

So there's plenty of forward progress going on, it's just a bit more behind the scenes. As always, filing issues is super appreciated :)

I think what you guys are doing is really great. It's super exciting.

I loved reading https://github.com/servo/servo/issues/12125. It is a great example of open source persistence despite it not being a priority. Things move forward at snail pace and stalls multiple times. Just when all hope seems lost, they manage to ship it ! This is the case with most opensource projects - things take their own sweet time but they eventually somehow manage.

On a side note, I noted that https://github.com/larsbergstrom owns lars.com. Wow! I wonder how much that is worth given that every 5th german is named lars ;) (though strom seems to indicate he is norwegian)

His "personal" section on Lars.com seems to indicate very strongly that he is American.

It's the 28th most common surname in Sweden (Bergström, that is). Tons of people in the northeast (Edit: Northern midwest rather) US have Swedish names.

What is the back story behind them having swedish surnames?

Alot of swedes emigrated to the US around 1800-1900s and spread all over the country. https://en.wikipedia.org/wiki/Swedish_emigration_to_the_Unit...

Thanks. Tangentially, search for "The Alot is Better Than You at Everything"

Oh, this was awesome. http://hyperboleandahalf.blogspot.com/2010/04/alot-is-better... for the others.

Oh that makes "Alot of swedes" a terrifying concept.

That's exactly the case for my family! However, we lost our umlaut at Ellis Island.

> every 5th german is named lars

That is completely untrue. Lars isn't exactly a rare name in Germany, but I'd be surprised if it was even one of the 20 most common first names. It's definitely nowhere near 1/5th of the population.

GP was making a joke. :)

You're right, of course. I blame low blood sugar.

> every 5th german is named lars ;)

9869 of 40 million, so around 0.025% Yep, one in five :-)

https://de.wiktionary.org/wiki/Verzeichnis:Deutsch/Liste_der...

It really is a nordic name.

http://www.beliebte-vornamen.de/3487-lars.htm

I get an inquiry to buy lars.com about once a month, but never anything more than a few 10ks. Which is a lot of money, but the hourly rate doesn't work out very well when you consider I've been using and would have to update that e-mail address everywhere since 1997.

It has been pointed out more than once to me that I could instead of purchased many other .com names that were available at that time and be semi-retired :-)

I'm really hopeful for this. The world needs a new browser engine, there is dwindling competition in this space and time and time again I find myself dissatisfied with browser offerings.

I've tried every obscure browser out there, and many of them are great at specific things but nearly all of them lack a few key features or present an experience that frequently crashes.

I think the Servo project is the biggest chance that Mozilla has to make an impact in its "Internet for the people mantra."

As a non-dev I will do my part by guinea pigging nightly builds and submitting issues!

> The world needs a new browser engine

> As a non-dev

I expect you are just responding to the inherent lack of performance that the javascript + html + css bundle shamelessly provides, which Servo will do nothing to sort out. Webassembly on the other hand is the first step to bringing superior performance to all browsers.

Servo doesn't really do anything for JavaScript (which is pretty much as fast as it's going to get, thanks to all the hard work of the V8, Spidermonkey, and SquirrelFish teams). But speeding CSS up is kind of the whole point of Servo.

And not just "CSS" but the whole DOM itself, which is more often than not what most people "perceive" as the slowness with web apps (and the entire reason why virtual-DOMs have caught on)

One of the things Servo gives us is the ability to experiment with new models for scripts to interact with a page. Imagine an IPC-based API exposed to WASM for instance.

The concurrency story could also expand on the limited capabilities of web workers support for shared memory.

Improving HTML + CSS performance is absolutely one of the goals of Servo. Here's a video from pcwalton demonstrating reflow (HTML), repainting, and CSS animations on the GPU in Servo: https://air.mozilla.org/bay-area-rust-meetup-february-2016/#... (much of this code is being uplifted to Firefox as WebRender). It's true that Servo won't have any effect on Javascript performance, but WASM won't have any effect on HTML or CSS performance.

I understand that, but the idea that HTML + CSS can only be sped up by some hugely parallel structure requiring a whole new programming language and browser engine is really quite shocking. I think once webassembly is established and in use, we will start to see steps in the direction of replacing HTML + CSS altogether, with something that has performance in mind.

A new programming language is not required, it's just a bonus to help developers handling safety and concurrency.

It seems like a valid point that many of the details of HTML and CSS, while you can use all kinds of fancy techniques to make them a little faster, impose limits on performance.

It's true that the DOM is a bottleneck on many apps (I don't think anybody is disputing that), but "a little faster" undersells what Servo is trying to achieve: order-of-magnitude speedups on GPU-parallelizable tasks, and at least factor-of-two speedups on CPU-parallelizable tasks, all while providing stronger guarantees WRT user security than any contemporary browser.

If you mean throwing out the DOM entirely for something canvas-based, I'm sure that will happen in some cases but I'm very skeptical that it will ever be anything close to the dominant paradigm for the web.

If you listen to talks about the design architecture of Servo you will understand the HTML CSS is not the problem. It actually is an advantage when you want to build an engine that works like a high performance game engine.

I'm not so sure. I remember a presentation of Webrender with nice demos : https://www.youtube.com/watch?v=erfnCaeLxSI&spfreload=10

Everything was perfecty smooth, but according to pcwalton the bottleneck was CSS handling.

It's building an engine from scratch as opposed to using legacy code and design decisions.

Why wouldn't you expect that to be faster?

Would web assembly help out with desktop web applications running on stuff like electron?

It can help there exactly as much as it can help non-desktop web apps.

More that half the browsers I experience crash or freeze on a constant basis, and yet Chrome seems to handle it in significantly more cases.

Servo plus browserhtml could become a nice alternative considering that mozilla plans to kill XUL and thus firefox interface customization.

After seeing a youtube demo[[1] of how the aggressive parallelisation that is done in Servo (safely possible by using Rust) speeds up this browser, i'm really excited for Servo! Also, i think this will give us a great base for all kinds of browser embedding what is not based on ancient webkit-gtk.

There is another nice presentation on Rust and Servo: https://www.youtube.com/watch?v=7q9vIMXSTzc

[1]: https://youtu.be/UGl9VVIOo3E?t=1019

I'm hoping for Servo-based alternative to Electron. If it could deliver some performance/memory improvements it would be good advertisement for the project, and also for Rust.

Not sure if that's realistic, Servo app ran on macOS takes about 200MB of RAM usage.

And slack on my macOS takes 800 mb. And WhatsApp as well. And Discord.

Servo isn't going to use any less CPU than other rendering engines, it will just be able to increase user-visible performance significantly by reducing latency by making better use of multiple cores.

I can't wait for people to start using this instead of chrome/electron to make desktop web apps. As much as I understand the philosophical (and at this point pragmatic) arguments against electron, there's something to be said about making deadlines and using technology your developers know well.

Not just for Electron, but also for embedded webviews on Android. Especially considering how Servo seems to be mostly lagging behind in supporting all the tiny edge cases and workarounds necessary for older sites, but not necessarily for modern web apps built specifically for it.

And then hopefully people will start to notice that some of those applications are much faster on Android than they are on iOS, and Apple will allow other webviews than WebKit on there.

Apple has a huge avantage because of the single-threaded performance in their SoCs, so they may afford to do nothing for a while.

Very, very nonresponsive. Sometimes when I press a letter in a form, it won't respond at all, but when I press it again, it will show up... and then when I press the next letter, the previous letter shows up. Which I thought was strange behavior.

EDIT: When I say "won't respond at all," I counted to 30 before the next keypress eventually just to verify I was really seeing what I was seeing.

Did you build with --release flag?

I didn't build it at all, I downloaded the Windows installer.

I have the same issue. I don't think it's unresponsive in a sense of "slow", because page rendering and UI rendering is ok'ish... It drove me nuts when trying to enter an URL into the address field. (btw. you have to prepend http://).

That's most likely because the current nightly isn't build with https://github.com/servo/servo/pull/16198 yet.

You probably didn't transfer ownership to the form..

Just so you Servo folks know, we appreciate the plan of shipping components incrementally in Firefox, and realize the necessity, and how big a project building a whole browser is…

…and yet…

…I think you know we're all waiting for Servo itself to be usable as our main browser :-) Good luck!

Servo doesn't even support SVG yet, and I can remember how long it took Firefox to get SVG animation once plain SVG was in there. One can hope things will go faster this time around ;-)

I was an early adopter of tech like XML and SVG. Even did a website in XForms. There was a lot of talk about making browsers support all of it. In the time since SVG was standardized, I think I've run into just one... maybe a few... media that I was sure was SVG. Everything else was a different tech.

I'm not worried about whether Servo supports SVG.

Tried Servo in Linux, even though the browser is slow in starting up, the page was loading very fast and scrolling the page is butter smooth! This Servo with Rust will redefine Browser and i wish this will restore the Crown back to Mozilla Firefox!

The experience was pretty good for what they were doing. I found a critical bug in UI that I submitted. I enjoyed watching how quickly they tackled the bug even more than how quickly it was rendering the sites. They're doing great work. I might fire it up again in near future and put it through it's paces.

A *.zip file would be useful for users who do not have admin privileges, as well as people who do not like giving elevated access to development software and who do not have access to a development computer nor a virtual environment.

MSI supports direct extraction, I just tried with servo-latest.msi :

http://stackoverflow.com/questions/3403733/silent-administra...

Shouldn't be too bad - we already build the zip and would just need to upload it, too! https://github.com/servo/servo/issues/16437

Doesn't even launch. The window appears very briefly then closes immediately. If any of the maintainers are here let me know how can I help you with this. I'm on Windows 10 version 1703 (OS Build 15063.13) x64

Same here. There don't seem to be any command line options to help debug it either. Even `servo --help` didn't print anything.

Might be an OpenGL versioning issue, sounds like the symptoms I've seen when trying to run on laptops with older Intel integrated graphics.

On Linux it's theoretically possible to force Servo into software-rendering mode, though when I've tried that it has done nothing even after 20 minutes.

However it's not yet available on other platforms:

https://github.com/servo/servo/issues/15259

Is there an accessible tutorial, for someone who is starting to learn Rust too, for embedding Servo within a Rust program? I haven't been able to find anything with a Google search.

Nice.

I wondered, for what kind of problems should I bother to file issues? The page says:

> so please file issues about anything that doesn’t work as expected!

Wouldn't that be quite a lot of obvious stuff? I just opened one web page and see over ten rendering errors.

Even the text edit control of the built-in search-bar doesn't work as expected (text selection doesn't work, both with mouse and keyboard). There seems to be no way to scroll.

Then it crashed.

We don't mind stuff that seems obvious because it may not be to others. Keyboard selection in the URL bar is supposed to work, for example.

Meanwhile, the Linux nightly build has been broken on all major distros for a while (see https://github.com/servo/servo/issues/12015 ), because the project won't bundle openssl. For a nightly. Which they already do for Firefox (all release channels). And of course, there are bundling it for this Windows nightly as well…

And I just checked, it's the same on MacOS, where libssl is bundled. I guess they've made their mind on the priorities.

The awesome avadacatavra is working on a plan right now to move us off of OpenSSL: https://github.com/servo/servo/issues/7888#issuecomment-2934...

TBH, it's been hard to prioritize work to fix OpenSSL issues when we all knew it was going away from the dependency list. However, I don't think anybody anticipated the scope of work required to get there :-)

Sorry for the inconvenience!

I understand, but then why bundle it for MacOS & Windows, and not Linux ? Couldn't they, too, wait for OpenSSL to go away ?

Note that I fully support using a clean rust-based TLS implementation. Given how young servo is, it will have time to mature before Servo becomes widely-deployed. I just think this is an orthogonal problem.

PS: thanks for taking the time to answer here and keep up the good work !

We're all exited about Servo (and Rust) and I'm really looking forward to using it.

But what makes software that's used everyday feel great are the small details.

I can't use Chrome (for consumption, though I use it for development) because of the way it renders text and a few other UI annoyances.

A browser is a lot of things, but to me, it's first and foremost a reading platform. So please, do whatever you can to use the OS's native text rendering.

>> So please, do whatever you can to use the OS's native text rendering.

That seems odd and would mean different quality on different platforms. Yes, if native is better than built-in then I agree. But what if their GL based text rendering is just fine, shouldn't they use it everywhere because it's portable?

The user doesn't care whether the text rendering of one app is consistent with the same app on a different platform, the user cares whether the rendering is consistent with the other apps he uses on the same platform.

I, for one, care mostly about absolute quality. If the rendering is better than native then that's splendid.

I don't use Windows, so maybe GL text rendering is better there.

But on the Mac, light thin fonts on dark backgrounds look much better with Cocoa text on retina screen than anything else. That's why I can't use anything but Terminal.app, despite all the niceties other terminals provide.

Besides, I don't want to give up on the built in dictionary, spell checking, etc

They invented a new font rendering engine based on the rust-based font-rs, called Pathfinder. Look into it, it seems to be progressing nicely.

I just tried it out. It froze when looking at a reddit comments page, it froze when I tried to use the URL bar. Pretty exciting nonetheless.

The URL bar does seem buggy and incomplete. I don't think it even supports copy/paste yet. It also won't let me type "https://..."

There's a fix already for text input on Windows, it just didn't land in the current nightly

This project has moved real slowly but keep remembering how often Eich referred to this as the most important aspect of Mozilla.

Talking is easy, Coding is Hard. Servo is still the most important aspect of Mozilla in terms of Security and Speed, I really think after the full development it will definitely beat the Google Chrome.

Haha. As if there is no development going on in V8. Rewriting anything doesn't mean it will beat it's competitors.

It's doing a completely different thing to why KHTML/WebKit/Blink is good.

I would be unsurprised if Google were quietly doing something similar, of course, particularly with Mozilla having been quite open about this project for several years.

First of, isn't V8 the JavaScript engine of Chrome?

That's a bit apples to oranges comparison, no? One thing Servo didn't touch is JS Virtual machine, it's still SpiderMonkey. Rewriting that AND the layout engine would be suicidal.

And I think they didn't touch it because that's the place where they can't use advantage of parallel execution - javascript's model suppose that user's code is single threaded.

He meant Blink, but he raises a valid point. Development on Blink is just as rapid as it is on Servo if not more so.

Sorry! I meant Blink.

No, rewriting alone doesn't make software great. But you have to realize that all modern browser engines started out before 2000. They were not built with multi-core processors in mind, nor with GPUs, as the web was still mostly text. And it does require rewriting a lot of things to change that architecture out. Google won't be able to compete with that in the long run just by continuously updating their browser engine.

Rewriting anything in a new language is a very time consuming and expensive process. To maintain feature parity with the latest and keeping up with bugs introduced could be very difficult. Google has much more juice to pull something like this off with lots of money. I doubt Mozilla could actually compete in the long run without generating lots of money like Google does.

You make it sound like the Google Chrome developers have completed their development and have gone home. By the time Firefox finishes their new Servo engine Chrome will be on version 65+. So lets see where we stand in terms of security and performance when Firefox actually starts shipping a production version of their new engine instead of calling it right now.

Silver bullets often fail in the world technology. Especially when Chrome has taken up such a huge market share. There might not be any Mozilla if they don't ship it fast enough.

Moved slowly or is monumental in scope?

Does servo make any speed gains on machines that dont have dedicated gpus?

Even on an iGPU you should see improvements since by offloading things to that GPU the CPU will have time to do other things.

Not having a dedicated GPU doesn't mean not having a GPU at all. You still have a GPU, it's just built into the same chip as your CPU and at this point in time, it takes up about half of the surface area. This silicon stays nearly unused in other browser engines (only used for hardware-accelerating video decoding and such). Servo will make use of that and makes use of it in the same way that video games do (which is called "retained mode", as opposed to "immediate mode"), so yes, it should still cause a significant performance improvement. Basically, if you've ever wondered why you can run some games at multiple hundreds of FPS, but your browser doesn't manage 60 FPS when scrolling Wikipedia, this is the difference between retained mode and immediate mode, and therefore should be corrected by Servo.

Also, current browser engines don't utilize multi-core processors, which Servo does, so even if you don't have a GPU at all, it should even there provide significant performance gains.

Mind the difference here between "browser engine" and "browser". Most browsers by now do utilize multi-core processors, but they only do so to run multiple tabs or the GUI in parallel. The actual browser engine still only stays on one processor. And well, with HTML being structured like a tree, it's actually incredibly well suited for parallelization, as you can process individual subtrees in parallel.

(And if you're asking yourself why no modern browser engine does utilize multi-core processors, that's because all of them were architectured in the previous millennium when multi-core CPUs weren't really a thing on desktop PCs. Also, the web was still mostly text, which is why no browser engine properly uses the GPU. So, yes, it's high-time for a browser engine being written from scratch.)

> only used for hardware-accelerating video decoding and such

Not true. GPU layer compositing is implemented in all modern engines. That's how the CSS 3d transforms work. That's why the translateZ(0) hack existed to speed up animations (it created a new GPU layer. Now there's an official property for this, will-change.)

WebRender (used in Servo) goes a step further — it's not just compositing, it's actually rendering the colors, gradients, borders, shadows, rounded corners and so on in OpenGL. Look at the shaders: https://github.com/servo/webrender/tree/master/webrender/res

I just tried the Servo nightly tech demo on TheVerge.com. The first attempt crashed it and the second attempt rendered the page incorrectly. Memory usage was 1.27 GB.

Awesome progress. Feels like a real alpha but I'm happy it's even displaying stuff and you can navigate some websites already.

Can you also offer a Zip package? (portable)

Why only this MSI package?

See speps answer here - msi allows direct zip extraction:

https://news.ycombinator.com/item?id=14104825

Why should the user do that? The project should do it with an automatic build script.

Every open source project worth mentioning releases also portable ZIP packages of the software. Mozilla's Servo windows builds get released only as MSI - why?

(BTW their win builds were available already for many months, just not linked from the frontpage, see bug tracker for more info)

Shouldn't be too bad - we already build the zip and would just need to upload it, too! https://github.com/servo/servo/issues/16437

Thanks for the fast response and for creating the Github issue!

  VCRUNTIME140.dll required

Why are open source projects built with Visual Studio these days? Especially as binaries built with VS2015 (release and up to service pack 2) are known to phone home "by accident". There are the GNU, Mingw, Msys, LLVM options on Windows - completely open source. Offer binary builds with at least one of these compilers on Windows platform.

I found the answer on moz hacks https://hacks.mozilla.org/2017/04/hacking-contributing-to-se...

Thanks, that's answer.

@Mozilla: so please make the Mingw builds as download package as well. And don't forget to release everything as ZIP packages as well. (not just MSI)

Servo is written primarily in Rust...

I'm not a Windows developer by any means, but my understanding was that the major different compilers on Windows aren't ABI compatible. Also it's entirely possible Servo links against an external library that is built with VS.

they don't allow the use of the latest api. ex: listening to dpi changes.

but what they could do is to link statically with the runtime.

Rust can currently statically link the VC CRT, looks like servo doesn't compile with that option at the moment is all

like it or not, VC is a very good compiler and a windows standard, and since not exactly recently, available for free for personal use. you don't have to use visual studio in order to compile software with cl.

It is a windows standard but I wouldn't call it a good compiler. It has traditionally has lacked in the standards department and compiler & code gen bugs have not been fixed with any kind of urgency.

Got some proof of phoning home?

Tried installing it on 3 computers and 2 VMs ... failed on all

How well should it be expected to work under Wine?

I suspect it won't, but you can try (please file bugs if it doesn't)!

We have had Linux nightlies for ages now though.

Oh, that would count as a valid bug? I shall :-)

Add self-update feature please.

Self-updates are great for browsers that people are using every day, but please, please don't use Servo as your everyday browser just yet. :)

I'm not going to use it every day, it would be just much more handy - opened it, clicked "update" or "yes" in "new release is here, do you want to update?" window, and it's done. Now you need to visit download page and download/install it every time.

Reply on news.ycombinator.com