7 ms·
> But if only a single browser will be able to display it, this not only questions the longevity claim, but also questions the whole web stack. New CSS specs ca
by wyqydsyq 8y ago
> But if only a single browser will be able to display it, this not only questions the longevity claim, but also questions the whole web stack. New CSS specs can't be reviewed and proven with independent implementations, and web specs will, even more so than they already do, become "whatever Chrome does".
Safari and Konqueror still use WebKit, Firefox still uses Gecko, so not "only a single browser will be able to display it", but multiple maintained browsers using 3 different implementations will still be able to display it. Additionally, even in that worst-case scenario of Chromium/Blink/V8 becoming the de-facto implementation and making standards irrelevant, it wouldn't be "whatever Chrome does", but "whatever Chromium does". Being in that situation Chromium would be in use by everyone, so if anything that only places more power in the hands of the community because Chromium is an open-source project. Why should every browser have their own competing (and often incompatible) implementations of each standard to the detriment of the web? How is that more beneficial than browser developers all collaborating on a common, shared implementation? Very rarely have implementation-specific differences between browsers benefited the web, generally such differences will either remain implementation-specific and become redundant (e.g. all the IE-only APIs) or are experimental implementations of a standard that's only in draft state and will be updated to be consistent once the relevant standard is finalised, in both cases they're just neat toys for developers to play with that aren't practical to employ in production (because they'll only work for a fraction of viewers).
> This is a terrible and fatal result for the web as we know it. Because why would we continue the practice of creating baroque, power-inefficient web frontends with JavaScript and the browser stack monstrosity when we're essentially targetting a single browser? We could as well use a much leaner and lighter GUI framework designed for the purpose, and a saner language.
This is a fantastic and wonderful result for the web as we know it. With less implementations to support, the web would be substantially faster and more efficient. Because why would we want to load our asset bundles with megabytes of polyfills and shims just so things don't explode on the odd chance someone tries to view your website in the default browser of their OS that's either outdated or poorly implements specs?
If every major browser ran Blink/Webkit + V8, the web could be written once in native ES2018 javascript and consistently execute anywhere. This is not the case today because implementations behave differently, you can't write a webapp purely following the established specs because the specs are inconsistently implemented. For example `navigator.mediaDevices` API works differently across browsers, some browsers support-sub features that others don't etc. This ends up requiring checks and work-arounds that waste processing power to execute and human resources to implement.
- tannhaeuser 8y agoMaking some WebKit derivative the de-facto engine would be very short-sighted. There will come a time, maybe in a distant future, when we need to get rid of C and our whole approach to mobile O/Ss, CMOS, and everything else. In any case, the situation we have now -- that of the web getting out-of-hand -- is what WHATWG, W3C, and co. should have avoided. They totally fubar'd it instead, so the world has to move to something else. HTML is a means to an end, not an end in itself. HTML hasn't changed much since the beginning, although it has been supplanted with the disgrace that is CSS and JavaScript. Can you seriously recommend to write a dissertation, a school book, a law text, a contract, or anything that matters in HTML at this point?
- jhasse 8y agoWebKit isn't written in C, but in C++.