Very happy to see Mozilla raising awareness around this issue.
Personally, I have Firefox and Chrome open side by side for development. If those two work, Safari and Edge generally will too. I'll add IE specific rules/hacks afterward.
Your CUSTOMERS do not want to see "To use this site / app, stop using the web browser you've chosen to use (or your company has chosen for you) and go install this instead!"
Servo is a modern, high-performance browser engine designed for both application and embedded use.
Sponsored by Mozilla and written in the new systems programming language Rust, the Servo project aims to achieve better parallelism, security, modularity, and performance.
EDIT seeing Etzos's answer, I see better what you meant (de-facto "standardizing" around electron). positron looks like a better answer then. But long term, there's clear interest from Servo developers, see http://blog.servo.org/2015/05/01/forward/ and Ctrl+F for "Chromium Embedded Framework"
There's a talk about this at https://air.mozilla.org/bay-area-rust-meetup-february-2016/ (HN discussion: https://news.ycombinator.com/item?id=11175258)
browser.html is just the current "skin" for Servo.
- At 03:00: pcwalton explains how this experiment leans on the GPU-ization of our Intel CPUs since Haswell.
- At 14:50: slide says "WebRender supports OpenGL ES 2.1 and OpenGL 3.x"
- "Benchmarks" at 26:00 running on his macbook, which may fit what you are looking for
TL;DR, yes this early work is for "integrated graphics such as those in normal laptops". Or try it yourself on your laptop with a nightly build: http://blog.servo.org/2016/06/30/servo-nightlies/
Software rendering makes it choke sometimes (other times it works surprisingly smoothly, but it depends on the load), but that is to be expected :)
Positron is indeed the thing you are looking for.
Obviously Mozilla tried and failed with Firefox OS to play in that market at the mobile level.
It might be nice to see an Electron and/or Cordova-compatible view engine from Mozilla, but I'm not sure how much adoption or testing it would see unless it became the default (and even then you probably would have a bunch of web developers revert to Chrome views simply because its comfortable to what they know).
Even when it did work, working with XPCOM sucked.
Positron https://github.com/mozilla/positron is the new XULRunner. WIP, doesn't actually work yet. :-(
I'm aware there is a setting which has to do with subpixel rendering or whatever this is called, I tried switching it on and off for no perceivable visual change. So I gave up on Chrome.
IE also has had broken font rendering since they moved to subpixel rendering several years ago, but at least it draws fonts in a strong and dark fashion making them more readable than in Chrome.
Personally, I design for Firefox which I consider the gold standard of web development. Then, at some intervals I check if things are okay in IE and Chrome and usually they are fine. Chrome was useful once in helping me spot some sort of a race condition, its developer tools also conveniently allow you to quickly bypass caching for testing purposes, but other than that I found it useless and unusable.
Yes I know about e10s and servo, but they aren't in the regular Firefox right now, and especially weren't several years ago when I was forced to change from Firefox to Chrome. I'd love to go back ...
Not a problem really. Never used Chrome before. Only installed it out of curiosity and also for testing purposes. Within the first day of using it on my development machine it became clear I wouldn't be using this piece of software in the future either.
I find the opposite: never could stand Firefox's font rendering -- and I've used the thing for years back in early 00s.
Instead W3C should have chosen simpler primitives from which developers can build complicated (formatting) rules themselves.
Simpler primitives is also better from a security perspective.
By designing the web for average users instead of for developers, W3C has shot itself in the foot.
There are hundreds of web technologies, each with their own spec. None of which are actually that complicated if you read them.
> Simpler primitives ... formatting rules ... better from a security perspective.
So you mean CSS? What does that have to do with security?
> Designing the web for average users
Not sure what you're trying to say.
The first part is true. There are indeed hundreds of web technologies. The second is absolutely false. A lot of them are (and have historically been) horribly complicated to implement, with lots of edge cases and strange interactions.
In fact prominent web standards people have talked about such cases many times.
>So you mean CSS? What does that have to do with security?
No, he means "simpler primitives" across the board. And even CSS has to do with security (e.g. loading third party fonts, etc).
>>Designing the web for average users
>Not sure what you're trying to say.
He's obviously tries to say that W3C et al piled features to please end users and satisfy end user needs, without giving much care about how to make them more consistent and coherent for web developers.
I'm not sure if end users are the people W3C is trying to satisfy. Browser vendors do enough of that. If anything, they're trying to satisfy media corporations that want DRM standards, or ad corporations that want pervasive tracking.
CSS, for one, is notorious for being complicated to understand, with tons of complex cases, especially in the layout department, where whole cottage industries of "tips" and "workarounds" for the simplest of stuff -- and I'm not talking browser incompatibilities -- thrived for decades (until, at least, flexbox and the like).
I agree with your overall point, but there is a reason sites like MDN exist. It's because some of the HTML/CSS/JS specs are crazy complicated, contain years and years of edge cases and bugs that have become standard, and are written in standard-eze (which is easy enough to read once you know it, but it can be a bit of a learning curve for someone who just wants to know the order of function parameters).
For a more nuanced understanding of browser behavior, you have to read the spec. Worked on a high performance network app, and I think I know the XHR spec by heart now.
I am curious, can you elaborate on this? :) What part of the performance related work involved peeking at the XHR spec so much?