--- start quote ---
He’s absolutely right. Implementing a browser engine from scratch was a lot of work in 1999/2000, it’s close to impossible today.
--- end quote ---
[1] https://twitter.com/LarsKnoll/status/1421121639845187585
--- start quote ---
He’s absolutely right. Implementing a browser engine from scratch was a lot of work in 1999/2000, it’s close to impossible today.
--- end quote ---
[1] https://twitter.com/LarsKnoll/status/1421121639845187585
You mention that "[Google] rarely agree with users on what's important", but I'm not sure that's true. I think the HN crowd, and those adjacent to it, often disagree with Google's practices, but my intuition is that Google's browser changes have been effectively silent improvements for the vast majority of users. If you installed a massively outdated version of Chrome on a random user's phone or PC, they'd probably be almost immediately upset at some missing feature or function.
At some point, these selfish advancements either become obsolete via the "official" way of doing things being implemented, or become themselves part of the spec. Should Google, Apple et al. have this much control over the future of the browser spec? My instinct is "of course not", but when I think about the history of the web, and how important these selfish decisions have been, it becomes harder to decide.
My original point you're replying to was moreso "why should a small independant team be able to build a browser", and I'm not sure you replied to that.
They are not theoretical. Too bad webapicontroversy.com has been shut down (it looked like this [1]), but you can scroll down to "defer" and "considered harmful" in Mozilla's positions here: [2]
There are more, of course, but they are not visible unless you're willing to follow thousands of issues across hundreds of GitHub repositories. One that springs to mind is, of course Constructible Stylesheets. Mozilla and Safari: the spec describes an algorithm that leads to deadlock in trivial code, we wont implement it until this is fixed. [3] Chrome: ship it, because lit-html (developed by Google) wants it and is already using it. And then procedes to gaslight people and misrepresent their positions (cant' find the relevant link, but at this point I can't find the will to dive into the cesspool).
[1] https://user-images.githubusercontent.com/32768/108985355-3f...
[2] https://mozilla.github.io/standards-positions/
[3] https://github.com/WICG/construct-stylesheets/issues/45#issu...
Browsers are the new OS. Most attempts at a feature-complete OS that is able to run software intended for other OSes would be incredibly expensive.
Plan 9's been in development for over 29 years, and it's still niche.
Also what’s the point of standards if nobody can realisticly implement them?
Yes, I can see that Apple perhaps isn’t giving WebKit sufficient attention, but Google and Chromiums dominans is the bigger problem.
And sure, you could disable an API or this and that feature, but it means you're spending a lot of time to keep reintegrating upstream, because google changes a lot of things all the time, so you really have to pick and choose what diversions you afford yourself. you can poke around the brave repo a bit to see the devs bemoan that.
Even with the fork they can't keep up: https://web-confluence.appspot.com/#!/confluence
Mozilla survives by whatever money Google is giving them, laid off most of their staff and shut down development on engine improvements like Servo (whether you like it or not, Servo is dead).
That leaves WebKit as almost the only meaningful opposition in the face of Chrome's onslaught. And it's going to get worse.
No, no, that's incorrect ;)
I'm doing more work these days in a browser than in any other application environment. The browser loads arbitrary code from external storage and executes it. It provides a standardized abstraction onto the hardware layer (mouse, keyboard, screen, audio, and in my case head-tracking).
One could argue that it's less operating system and more glorified UI toolkit, but I can't name a UI tool kit that also has to provide security sandboxing to prevent arbitrary code from misusing its hardware interfacing.
Perhaps we could consider it a virtual machine running atop an operating system. On the other hand, I think Chromebooks suggest that you can build the host for that virtual machine very thin.