Happy to answer questions (when I wake up; getting this ready has been a lot of work, needless to say) :)
It goes without saying, but as this is the very first nightly (not by any means a full-fledged release), expect severe bugs, crashes, and missing functionality. Many of your favorite sites will be broken. Don't expect to use this as your everyday browser. We'd love feedback on what issues folks hit the most, so we can prioritize—especially if you're a Web developer!
Yes, this is using WebRender by default. The WebRender 2/WebRender Next branch can render most content just fine at this point, but we went with the mainline branch for the initial nightlies, as it's more mature and stable.
A very general question: what's the high-level plan for Servo regarding Firefox? I see a lot of requests/issues dealing with stuff that doesn't seem related to a layout engine. Is the plan to have browser.html as a temporary incubator for Servo and eventually migrate it to replace FF's layout engine, or is it to "grow" an entire new browser around this new engine?
There are efforts to make various components work in Firefox. The largest effort is "Stylo", which replaces Firefox's selector matching with ours. I'm not sure what the future is on Firefox using Webrender or our layout; though I suspect it depends on how well stylo works.
The plan seems to be to let Servo continue to evolve as a testbed for new ideas (like webrender), and share components with firefox whenever ready. An independent Servo product is not likely in the near future, since there's a lot of work to make it fully web compat. In the far future ... well, we can't tell :)
I feel like mobile (Android, really) needs a fast, secure and extensible browser, I hope that Servo can help Firefox achieve those first two goals so that it could be my browser of choice
browser.html is just the browser chrome (er, not to be confused with the browser Chrome), it's an independent Mozilla project to create a frontend entirely in web technologies, which, since these are all standardized, should theoretically work with any browser engine, not just Servo.
As for Firefox, later on this year we should see the integration of Servo's style engine ("Stylo") into Gecko, and going forward we should expect to see the two codebases share even more components. However, wholesale replacement of Gecko with Servo in Firefox isn't on the table at the moment.
Things like history management. While tabs in browser.html are just iframes, browser.html needs more access to the contained documents to be able to fully do its job. For security reasons, you can't get at an iframe's current location/title/favicon if the loaded document is from another domain. We need this information to show a proper title in the title bar and the tabs list, and to show a back button and things like that.
In addition, the browser needs to act as a sort of broker between sites and the OS. Storing cookies and session data, showing notifications or dialogs, and entering fullscreen mode are just a few examples of this. (Note that most of these things aren't even implemented yet. Browsers are complex applications in their own right, even after accounting for the browser engine.)
Parsing CSS, the selector matching to apply style rules to nodes, and the cascade of properties to other nodes.
Servo's style engine is parallelized and scales nearly linearly with number of cores, and style time is a non-trivial amount of the total rendering time.
We're hoping for days, but it needs a lot more testing. We're (unfortunately, due to some font-related issues) still building Windows with the mingw toolchain, which makes build & packaging more complicated.
The Windows version is not availiable because mozjs the JavaScript engine, Or say, SpiderMonkey, fails to compile on windows currently, and servo developers can not know when it will be fixed. Once it can be build on windows, windows version may come out soon.
This is not true. Servo and Spidermonkey compile fine on windows using the mingw toolchain. For the MSVC toolchain we don't have that fully working, but obviously Spidermonkey is not the problem there since the official Firefox builds use MSVC. Mostly we have to fix the build glue.
The Windows port didn't ship yesterday because of technical glitches post-install. Servo works fine, but after installation it had some strange behavior we couldn't track down in time. It should come in a few days.
> It's made by system developers and for people comfortable with debugging low level issues like kernel panics caused by faulty drivers.
Fixed that for you :P
PS. It is considered bad etiquette to ignore the issues of a Windows user and simply "recommend Linux" in a tech community like this, especially when a Windows build has already been promised. You don't know the reasons why someone is using Windows (ex. because of a policy of their employer).
I sorry to inform you, but Windows is considered harmful, so this is good etiquette now, also known as "word of mouth". You can download and run Linux in fraction of time you will need to argue that this is bad for a user.
Download Linux. Download Servo. Run Linux. Run Servo. Profit.
Yeah I wish Linux desktop was that great. I run Xubuntu for dev work (Rust actually). Even really trivial things, like making the edges of the windows easy to grab to resize -- they get totally wrong: the target area is 1px or so. (Yes I know, Alt+Right click is an option, and I should really just use XMonad.) I go search for this issue. Sure enough, many years ago people were talking about this issue, and it's just one excuse after another. Never resolved; maybe it's a theme issue (with all in-box themes), maybe it should be solved somewhere else. Whatever. End result, out of box, it's difficult to resize a bloody window. I think that sums it up pretty well.
I've less and less love for MS (though Visual Studio...), but even with having to install crappy hacks to fix Win8, it's _still_ a smoother end-user experience than Linux desktop.
With Win10's Linux layer, assuming there's an accelerated X server for Windows, I can't think I'll keep even a VM around much. (If I can turn off Win10's spyware.)
The Linux philosophy is to do one thing, and do it well, this is why they get impeccable codebases, but bad UI/UX design.
Jokes aside, I stopped fighting desktop environments and embraced Ubuntu's Unity some years ago, at the end I learned to appreciate it and nowadays I feel more comfortable with Ubuntu than with OS X.
I still prefer Windows over Ubuntu, but because I have added several utilities to my workflow like Everything Search Engine or WinSplit Revolution (now defunct), not because of Windows' own merits.
I just wish there could be a way to have OS X's hotkeys in Windows, since CMD + <anything> is more comfortable to press than Ctrl + <anything>. I also miss having the behavior CMD + Tab / CMD + ` and the ubiquity of CMD + ,
Hey, stop that. This topic is about nightly builds and contributing to open source project. Linux is great for that because it made by developers and for developers, and not because it has a polished UI/UX. Linux UI is rough. Accept that.
This specific branch was to ask for an ETA for the Windows Nightly, and you hijacked it. I advised you to refrain from hijacking it and you began spitting anti-Windows nonsense like a freshman who drank the Linux cool-aid for the first time.
This is not the place to discuss about operating systems, and people expect from you to respect their preference.
Linux has its technical merits, and because of them it is the most used OS in servers, supercomputers and niches like web development, but it also has its weaknesses, and because of them it isn't the most used OS in homes or corporations.
OTOH, there already exists a Linux distribution which is more popular than Windows, it's named Android, you've probably heard of it. It is a disaster in comparison with Windows, it gets locked, bloated and abandoned by phone manufacturers, phones get declared obsolete ridiculously fast and people are left without even security updates, you don't even have the ability to "format" a phone unless someone breaks a vulnerability to gain root access.
People blinded by Linux usually overlook the disaster behind Android because they're too accustomed to focus their attention in the issues of Windows, but no OS is perfect and people will choose the OS that works better for them, you must learn to accept and respect their decision.
It looks like you are Windows fanatic. Replace "Windows" by "C++" and "Linux" by "Rust" and reread my comments, please. I am talking about development and developers, nightly builds and contribution. You are talking about users. This version of Servo is not for users. This topic is not for users. Stop blaming me for your own error.
Thanks for the suggestion but I'm already using Linux where it makes sense for me (my website, Gitlab instance, etc). I asked about the Windows version since that's what I'm using most of the time being a .Net dev.
Looks like visiting a Youtube video linked to via reddit.com/r/videos crashed it. The whole UX is locked up, so I can't click the "Click to submit report" button either. screenshot [1]
Either way, I'm already impressed by how zippy it is :D
There's a more serious error in the url parsing
that caused this, due to some wierd stuff google
is doing with punycode. I haven't looked into that yet. But youtube no longer crashes -- so you can now enjoy window-shopping on youtube!
> expect severe bugs, crashes, and missing functionality.
I really don't mean this in a snarky way: wasn't this kind of thing supposed to be obviated by the switch to Rust? It often seems that every other post about Rust on HN says that if it compiles, it works.
No language can fix missing functionality, that seems pretty clear.
Your compiler doesn't know what you're trying to do, so you can't prevent all bugs.
That leaves crashes, and ... well it may also depend on what you mean by a crash. The UI becomes unresponsive? Might have absolutely nothing to do with memory issues or even code written in rust. Maybe your rust code is fine but you're trying to open and write to the same file from two places which you don't realise because the users file system is case insensitive but you've only tested on a case sensitive one, etc.
It's also multi-threaded and while languages can significantly help improve the safety of multi-threaded code, I don't think anything can stop you from creating a deadlock or putting your system into an inconsistent state.
And finally, they may not even particularly expect those things, but putting out early nightly builds to a wider audience and expecting nothing to go wrong would be cavalier. A typical warning on many early releases is "don't blame me if this destroys all your files".
>Maybe your rust code is fine but you're trying to open and write to the same file from two places which you don't realise because the users file system is case insensitive but you've only tested on a case sensitive one, etc
That sounds too precise to be just an example :) We've all been there!
Haha, yes, this kind of thing has bitten me a few times. I remember getting SVN really confused where the server thought files were different but my machine thought they were the same (or similar). I think I had to make a whole new repo.
It's now on my mental list for "but it works on my machine", checking filenames and their cases.
To clarify, a panic in rust is the result of an unhandled exception. Usually this is due to laziness rather than a real bug. For example Servo might encounter an IMG tag, start to load the body. The result might be stored in an option because something could have gone wrong during loading (peer disconnected etc.) but the developer didn't feel like implementing robust image handling that day and instead called .expect to extract the image. This throws a panic and exits the application if the image is not there.
This is just a hypothetical example, I bet image loading is one of the things Servo does fine. Just to give you an idea of when Rust might panic.
We were basically panicking when an invalid URL was given to us. There was a comment there noting this -- which means that this was probably written when it wasn't so important to handle all the cases, and more important to handle some cases so that we can test out various ideas. We're still sort of in that stage, and you may see other comments like this throughout the code :)
I do things like this all the time in Haskell when quickly prototyping new code and then swiftly kick myself because of it. Safe languages are nice, but there's really no way to prevent a developer from saying "Yeah fuck it, this case will never happen anyway" and then calling a fromJust on a Maybe monad which turns out was a Nothing and throws a runtime exception.
Well, there is a way: Don't allow partial functions like fromJust or head. But a) it's going to make prototyping so tedious that no one will bother using this hypothetical language, and b) there are problems that you just cannot solve without partial functions (e.g. foldl1).
And importantly, a panic is not a result of a memory safety bug, and those are the crashes (with their potential security risks) that Rust is aiming to get rid of.
It would be quite nice if there was a synonym for expect (say unimplemented_expect) that meant 'I haven't bothered to implement the proper error handling yet' rather than 'error handling shouldn't be required'. That would really enhance auditability of in-progress code.
Python has a nice built-in exception for this: NotImplementedError. It's intended usage was related to abstract base classes, but it's taken on this secondary use case recently.
Yeah, I use that, but it obviously requires more work than a simple unwrap or expect, so the temptation is to just use those and think you'll remember to flesh it out later :-)
> It often seems that every other post about Rust on HN says that if it compiles, it works.
I'm always careful not to say that "if it compiles, it works"--no language can guarantee that (well, except those that prove your program correct). Instead I like to say "if it compiles, it will fail for a not-stupid reason". :)
In pure Rust that never uses "unsafe", maybe. (Though even then, you only get memory safety; it's still possible to e.g. go into an infinite loop and use all CPU and/or memory).
Rust intercepts most stack overflows and aborts the program when they occur. There are some more difficult cases where legit stack overflows are still possible, the resolution to which is blocked on LLVM support on most platforms (notably, Windows is the best here).
Well ultimately any useful program will use a library that uses unsafe. All I/O is unsafe at the bare metal so while you can safely wrap it it still is unsafe internallly.
When talking about the usage of unsafe code in rust, we generally ignore encapsulated unsafe code in libstd since it has the same safety guarantees as tgr compiler itself. all unsafe code encapsulated in a safe API has these guarantees, but you trust libstd more :)
Any reasonably large program will have at least some amounts of unsafe code. And that's not a big deal. The point of Rust is to very clearly isolate the unsafe parts, so that you only need to audit 1% or less for memory safety.
If it uses any external libraries (for example, for image handling) then I believe it does by definition, since the API wrapper you end up writing ends up being a small shim that wraps the actual library call in unsafe (because object code is unsafe, as the term in used in Rust).
I miss SVGs, <audio>, Youtube embeds, and the layouting is off.
Sometimes mouse wheel doesn't work, was stuck once scrolled. Biggest problem is keyboard layout isn't right.
I tested on OSX, nice work overall!
There is a fix in the pipelien for keyboard layout,
and we are aware of the mouse wheel issue.
Please file bugs for layout being off -- we know
that this sometimes happens, but it's good to have testcases. As for embeds, that's not priority now, but we should eventually get them.
I noticed that the Servo Nightly build is already about as big as Chrome or Firefox. As it's not yet a complete browser, I expected it to have a lighter executable. Do you know what lead to this? Is it a matter of build artifacts or optimization? Is Servo going to grow even larger while achieving feature-parity with other engines?
It looks like Servo could be a great alternative for Chromium Content -- one of the things that keeps me from (ab)using Electron/NW/CEF is the massive initial overhead, and a WebRender-based UI with lower admittance price would change the whole scenario.
It goes without saying, but as this is the very first nightly (not by any means a full-fledged release), expect severe bugs, crashes, and missing functionality. Many of your favorite sites will be broken. Don't expect to use this as your everyday browser. We'd love feedback on what issues folks hit the most, so we can prioritize—especially if you're a Web developer!