There is also a discussion on the Rust reddit about this: https://www.reddit.com/r/rust/comments/6p9s24/psa_you_can_tr...

I really like this idea of switching over to servo bit by bit. It makes me happy that there might be a real WebKit alternative again.

I'd argue that Gecko is a real WebKit alternative. It has improved quite dramatically lately, have you tried Firefox Nightly?

The problem with in its current state as a WebKit alternative is that it lacks stable api.

We don't see any gecko based apps like we see WebKit based apps (electron, etc) because gecko is so tightly developed around Firefox.

I remember way before Electron there was XULRunner, and there were a few ridiculously bloated non-Mozilla apps that were based on it. Like Songbird[1] -- anyone remember that?

I suppose the idea was largely ahead of its time; in 2006 computers just didn't have enough RAM/CPU to get away with running a full web browser stack for every app like we (sort of) can today.

[1]: https://en.wikipedia.org/wiki/Songbird_(software)

Back then I was a big fan of the concept and I really enjoyed songbird.

I still think that building a html+javascript package, and have the default browser run it chromeless with some expanded privileges (or near chromeless) is a great approach for cross-platform apps, sadly it doesn't seem like anyone is working seriously on such an approach.

HTA (basically a HTML page launched chromelessly with elevated privileges) was a thing back around the Windows 98 era. Everyone I knew at the time universally considered it a horrible and misguided idea by Microsoft. Funny how the history repeats itself.

https://en.wikipedia.org/wiki/HTML_Application

There's Electrino, which provides the Electron api but runs whatever your OS's built-in rendering engine is: https://github.com/pojala/electrino Still in development and relatively limited, but the idea's there!

There's also Sciter, which is supposedly very mature (even more so than Electron), but as it's closed source and released under a mixed licence (there are free and commercial versions), it's not got much traction outside of commercial apps:

https://sciter.com/

OMG, I had never seen Sciter before, All I thought is a lie, ESET, Norton, Avast all were using HTML even before electron exist. I always thought theirs software was made by hand using native APIs and frameworks.

> I still think [it] is a great approach for cross-platform apps

You think so? I find that running a whole second OS for every process is hugely bloated and slow, and that we can do much, much better when there are already very good languages that run cross-platformly, they just need bindings to a good cross-platform UI toolkit.

Unfortunately, nothing looks as good on OS X as Cocoa does.

Yes. Yes I do.

Look at R studio. Wonderful IDE, runs as a safari app. Having a whole extra browser and a node backend running for each app seems a waste, but using the browser that is already running as a runtime environment seems much saner.

I do most of my work in the browser, I wouldn't mind if some of that had better integrated UI.

I also wouldn't mind writing small, easy to produce apps that will work across systems.

I'm not saying programs written in it aren't useful or doable, I just don't think it's a great approach. I think it's a last-resort approach, because there just isn't a better cross-platform toolkit available.

> I still think that building a html+javascript package, and have the default browser run it

I think the thing that kills that approach is the default browser, which on Windows is IE 12 (Edge).

Edge isn't actually that bad to work with these days. But almost no web developers will use that when they could ship Chromium / Electron just as easily and get the exact same browser on all three platforms.

Even Microsoft's own teams will sometimes make that choice (VS Code using Electron.js and not Edge, for example)

I don't think Edge is the problem: the problem is IE11 and people clutching to Windows 7 until the bitter end and whether or not to support them.

You can see bits and pieces where Microsoft's teams are also experimenting with Node on ChakraCore and Electron on Edge.

I don think it's quite the same thing though. Songbird was a XUL app with extension support and a built in browser. Aren't Electron based apps HTML based and running on Website?

They don't run on a website, they are static files (usually) served from a zip file.

Argh, sorry phone auto-corrected Webkit to Website.

True, Gecko lacks a real API for embedding. Servo on the other hand has embedding in mind from the start. There is someone from the Servo team working on it: https://github.com/paulrouget/servoshell

That's good. I don't see a point in having an app that embeds a browser to show an app. It's like having those silly Android apps that are just a wrapper around a web version of the service.

If I want to use a web version I can do it using a browser of my choosing not the one developers want.

The browser rendering environment is only half of electron. Electron (and nw.js) provide a node.js / browser hybrid. You can use native node-modules, instead of browser-based workarounds and you have the same filesystem access a native application would have. You also have hooks into platform specific menu/dock/notifications.

It is, it's just hard to track what's going on in a way. The browser saw new ideas, and rollbacks (hello ? IIRC). There's the XUL layers, Electrolysis, the actual engine. I have to admit If you clean your mind from memories of high latency Firefox GUI, it's now near chrome-fast on the UX side. Memory use is adequate if not #1. Tabs are well handled too.

Servo's WebRender is also in the Firefox tree. I've seen some crazy benchmarks using it. It's not ready to be enabled widely yet, though.

Note that the current webrender pref on nightly will be slower, since it runs stuff through webrender and then the regular renderer. They're focusing on getting it feature complete first, after which that pref will probably be switched over to be pure webrender.

I'm new to frontend in general and wondering if I could trouble you for some context. Why is Firefox's CSS styling engine not already "in" the browser? To me it seems like Stylo is just a parallelized replacement for the old system, Servo. What am I missing here?

Also, why are you celebrating an alternative for WebKit? Isn't it already supported by most major browsers?

> Why is Firefox's CSS styling engine not already "in" the browser?

It is, Firefox can do CSS and styles just now. Stylo is a replacement for that.

> To me it seems like Stylo is just a parallelized replacement for the old system, Servo. What am I missing here?

Servo isn’t the old system. Servo is a research project to build a layout engine (analogous to Gecko which Firefox currently uses) in Rust, of which Stylo is a part.

> Also, why are you celebrating an alternative for WebKit? Isn't it already supported by most major browsers?

It sounds like you’re confused about what WebKit is. WebKit and its forks are used by a number of browsers (Chrome, Safari etc.).

EdgeHTML, Gecko and WebKit are, broadly speaking, competitors which attempt to implement certain standards and frequently disagree about how to do so. It’s important that there be alternatives to WebKit with significant market share because otherwise how WebKit implements a feature becomes the de facto reference implementation.

Thanks to you (and all the other commenters) for the detailed answers! I learned a lot!

Servo is a complete (although WIP) browser engine in Rust. Stylo is a project to plug the style parts of Servo into Firefox, which currently uses the Gecko browser engine. This is part of Mozilla's ongoing efforts to modernize Firefox by gradually rewriting it in Rust.

WebKit is technically only used by Safari. Chrome uses a WebKit fork called Blink, and MS Edge uses its own engine called Chakra.

I assume the above commenter was expressing relief that someone besides Google is making a fast, modern web browser these days.

Chakra is just the JS implementation in Edge; it's the equivalent of JavaScriptCore in Safari, V8 in Chrome, or SpiderMonkey in Firefox.

The layout engine bits in Edge are https://en.wikipedia.org/wiki/EdgeHTML

Servo is not Firefox's browser engine. Gecko is. Servo is an experimental highly-parallel browser engine in Rust. It's a separate project.

Stylo takes Servo's styling engine and puts it inside Gecko.

"again" ?

Was there a real alternative to WebKit in the embedded browser space before? (genuine question)

Pretty cool that changing layout engine doesn't require a restart!

It's not the entire layout engine that changes. They only switch to the CSS Style system of Servo: https://www.reddit.com/r/rust/comments/6p9s24/psa_you_can_tr...

It's still pretty cool though :)

Wow, I restarted my browser because I assumed it was necessary.

The proposed flag in about:config exists in Firefox Developer Edition too. I tried to enable it, then loaded some pages. There seems to be no distinction in visuals. Did it work seamlessly or is it currently NOP?

The flag exists in Firefox Developer Edition but it doesn't do anything yet. You have to be on Nightly for it to have an actual effect: https://www.reddit.com/r/rust/comments/6p9s24/psa_you_can_tr...

You can check in about:support to see if it's actually enabled.

It won't be for dev edition; dev edition didn't build it by default.

about:config isn't user-facing so it will show prefs that do nothing on the current release channel or build.

Very cool.

What parts of Servo are already in Firefox? What is missing? Is there a list of what will get into Firefox over time?

We have:

- Stylo, built by default, off by default

- Webrender, built by default, off by default, current pref makes it render things through both engines.

- rust-url for url parsing, built by default, off by default, current pref makes it parse through both parsers and compare. I intend to bring this across the finish line once done with stylo

- encoding_rs for dealing with string encodings. built and on by default. Not exactly a servo component (servo used to use rust-encoding), but i think servo uses it now.

A GitHub search suggests that Servo isn’t using encoding_rs.

There is a wiki page about Project Quantum: https://wiki.mozilla.org/Quantum

Currently Quantum CSS (Stylo) and Quantum Render (Webrender) are both in Firefox Nightly, but they are unstable and can cause really bad performance, especially Quantum Render. They won't be done until at least Firefox 57 and some most likely later.

Quantum Compositor is in Release already I believe. It's the out of process compositor for Firefox.

Changes from Quantum Flow are continuing to be implemented into Nightly and later on Beta.

I haven't ready much about the progress around Quantum DOM, and I have no idea for which release it is targeted.

Do I get this right.

Servo is the experimental browser (engine?)?

Quantum is the project that ports parts of Servo to Firefox over time?

Quantum is now also a bit of an umbrella project for initiatives making Firefox faster. "Quantum Flow", for example, is an engine-wide effort to push performance in the bits that still C++.

Right. Servo is an engine that will be embeddable into apps that need to render HTML, not just browsers.

Ah, so like the omni-present webkit view?

Yeah, exactly. It doesn't include a JS engine so for now it uses SpiderMonkey, but eventually you should be able to plug others in.

Whoa I didn't know webrender was shipping on nightly already, even if it's unstable.

Currently with Webrender enabled Firefox renders it both on Webrender and the old renderer which causes it to be really slow.

I see, that would explain the performance issues. Why is it set up like that?

There's a lot of refactoring to do in Gecko's graphics stack to fit the new rendering model. While they do that, they can also accelerate one thing at a time with WebRender, testing incrementally. Things like SVG which WebRender doesn't have yet, can also use the old system and be included in WebRender as images.

The old system will still be needed post-WebRender for printing at the very least.

> The old system will still be needed post-WebRender for printing at the very least.

Isn't it possible to take a frame from WebRender and print that? Having two separate systems seems like allot of unnecessary maintenance. Especially if one of those systems is only used on rare occasions like printing.

My understanding is that WebRender doesn't support everything yet, so right now it's mostly about validating correctness.

Ah I see, so it basically enables a parallel run of webrender to gather compatibility/correctness stats.

So it renders it two times and compares the results?

It renders it in series -- stuff goes through webrender first, and then whatever webrender couldn't handle gets dealt with with the regular renderer.

You can also try webrender, but it still has more issues than stylo in my experience. It gobbles up a lot of gfx memory for starters, which can actually slow things down if you don't have enough. But that's a known issue.

gfx.webrender.enabled = true (restart required)

According to the Reddit thread, enabling this will run both webrender and the regular renderer for now, so it will be both slower and more memory intensive.

I cannot find the flag in about:config - my version is "56.0a1 (2017-07-23) (64-bit)", so it should be in there, no?

I have the flag in my about:config with build `56.0a1 (2017-07-25) (64-bit)` under Linux. You're SO two days ago! Update your Nightly :)

Hmm, I got it through `ppa:ubuntu-mozilla-daily/ppa` on Ubuntu, so this is generally a couple days behind? Did you download it manually?

Looks like that disables Servo at build time. Someone on Reddit had the same problem - https://www.reddit.com/r/firefox/comments/6p9t83/psa_you_can...

Indeed, same issue. Thanks for the pointer.

Yes, I like to run the official self-updating build from https://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-c... , because it's the official build (which is appreciated when reporting bugs) and always fresh.

- You could switch to that too (I run it even on my job Ubuntu machine, never saw any benefit to using the official Ubuntu PPA apart from proper packaging, which I don't care about, this Firefox lives in /opt/firefox and that's okay with me, and getting updates are a matter of hitting Help -> About, easy).

- Or just wait a few days for the PPA to serve a fresher build. EDIT forget about this and read bzbarsky's answer above. Thanks, Boris :)

It's entirely possible that Ubuntu is not compiling in stylo at all.

In fact it's likely: Firefox nightlies on Linux have been shipping stylo (preffed off) for close to three weeks, so if a two-day-old Ubuntu build doesn't have it, chances are neither will a newer one until they change their build configuration to use --enable-stylo.

When will this be incorporated in Firefox Mainstream release ?

It should go out in Firefox 57 which is scheduled for November 14.

The target, IIRC, is 57.

Cool, and when will servo go mainstream ?

Does anyone have any links to benchmarks?