It just so happens that I'm also juggling a million other things simultaneously. For example, I'm working on power usage improvements on macOS that should help address some of the complaints upthread. Also there's the entirely new GPU font and SVG renderer (which is a novel technique). Also there's making sure WebRender ships. Etc.
ps: a x201 core i5 520m
The thing is that rewriting a browser engine doesn't just happen over night. No bigger browser engine has been written from scratch since the previous millennium. Also, no browser engine implements all currently specified webstandards. So, Mozilla would have to full-pelt develop Gecko to be able to keep up with Blink in webstandards, and then also develop Servo at more than full-pelt to be able to catch up in finite time.
That just doesn't add up, which is why Servo was specifically started as a research project. It might never be completed. They have been able to integrate various components from Servo directly into Gecko, therefore sharing the development work which they didn't really plan with, so that's one tiny reason to still hope for it to ever catch up, but yeah, just don't be too optimistic.
Having said all that, the integration of components from Servo into Gecko isn't done yet. WebRender is still missing, which should bring another good performance boost. It's sort of been overhyped with artificially complicated CSS animations [0], so the real world effect isn't that big, but it's still very much noticeable.
[0]: https://www.youtube.com/watch?v=u0hYIRQRiws
Aside from that, on Android, Mozilla is building a new framework for building Android browsers in general, called "android-components", which also includes a much cleaner integration of Gecko on Android, called "GeckoView". They've already rebased Firefox Focus onto GeckoView and are actively working on rebasing Firefox for Android (Fennec) onto it, too, which is internally called "Fenix". This should also significantly reduce the lagginess and speed up their development in the long-run.
I guess, what I'm mainly trying to say is that there's definitely still things happening.
Chrome is the new IE though. Making whatever specs they need for Google Sites - standards be damned.
The web actually works great without JS, and doesn’t require gigs of memory to browse.
Every month there’s some new JS API being proposed or developed for browsers, with no care for its impact on the web. The JS APIs are still growing and only getting more complicated too! service workers is a perfect example of the problem. Offline browsing worked great 20 fucking years ago, but now multithreaded Turing complete programming languages have to be used to view a website offline. It’s absolutely absurd.
It should be noted there have been side projects to back nodejs with spidermonkey [0] and have electron APIs backed with gecko [1].
I agree with you and the thing I want more than anything is a cross platform browser engine embeddable with a supported C API that's not Chromium. Servo was on its way, but work has definitely slowed. But I acknowledge that even though I would build my own browser UI on top of an embeddable gecko engine, it probably won't affect adoption that much to be worth the effort.
0 - https://github.com/mozilla/spidernode 1 - https://github.com/mozilla/positron
As you said, they could also make a killer electron alternative and it would be very fitted to Servo as you can start with a subset of the spec and focus on performance/footprint, but their lastest attempt is from what I know this : https://github.com/paulrouget/servoshell/blob/master/README.... which is almost 1 year old
They compete for the same money, no?
The next thing seems to be Fission, which is the continuation of the e10s (electrolysis) content process model into full/more Site Isolation. ( https://wiki.mozilla.org/Project_Fission - but it seems hard as fuck: https://mail.mozilla.org/pipermail/firefox-dev/2018-July/006... nowadays they seem to be stripping out the old Gecko XUL stuff and replacing it with something newer and better: https://mail.mozilla.org/pipermail/firefox-dev/2018-November... )