I feel like I’m missing something, because I keep seeing blog posts that tell me a browser monoculture is bad (and the irony of Microsoft saying this is nearly too much), but none of them tell me why. I understand that it was bad in the IE6 days, but IE6 was also closed source and could only be run on Windows (see also the irony of Microsoft discontinuing IE on Mac, not wanting to compete with Safari, a browser made…
Browsers
71–80 of 316 posts
Re: Browsers
#72The biggest danger to the web in terms of control right now is browser monopoly , not engine monopoly . And this move is probably the most effective way at combatting that. I think this is the right move at this time not just for Microsoft, but for the web. Borrowing from a previous comment I made, think of it this way: do you think it helps or hurts Google to have every version of Windows come pre-installed with wha…
> I can't wait to see what the same company that gave us VSCode is able to build on top of Blink, and eventually separate from Blink. The situation here is very different from WebKit and Blink. Google was already the plurality contributor to WebKit at the time of the fork. By contrast, Microsoft has contributed virtually nothing to Blink, and they intend to be identical to upstream Chromium. Microsoft is not going to…
I feel people don’t analyze this move realistically in the current context, but instead compare it to some imagined magical alternative where we snap our fingers and have a fresh new viable competitor or people just decide to switch away from a browser most people like.
Regarding the specific example you gave, I’m fairly certain Microdift’s wrapped Chromium can exclude participation to those lists. And frankly I’d be surprised if they didn’t. Microsoft didn’t sign on Google as an OEM provider of a browser for their OS, they are building their own browser on top of Google’s engine. Im not super worried about Microsoft being bullied, they’re probably the best suited to do something like this in a defensible way.
Re: Browsers
#73The idea was that javascript libraries would be created that would replicate SQLite in the browser (albeit horribly inefficiently with terrible APIs compared to shipped-with-the-browser native C implementation that is SQLite).
Anyway, now that Firefox has become less relevant than ever with Microsoft's adoption of Chrome, I wonder if there's any chance that WebSQL will live on despite its deprecation? After all, it's still available in Chrome and Safari, which dominate the browser market.
IndexedDB is fine if NoSQL is how you store your data, but an absolute PoS if you want to work efficiently in a relational model with joins, grouping, etc.
Such a shame, every server-side language under the sun compiles to javascript now; imagine being able to share SQL statements between client and server; being able to aggregate data, count & sum with reckless abandon. Instead we have to do it all by hand in javascript, such a step backward [3]
/rant
[3] https://news.ycombinator.com/item?id=9978540
[1] https://hacks.mozilla.org/2010/06/beyond-html5-database-apis...
[2] https://hacks.mozilla.org/2010/06/comparing-indexeddb-and-we...
Re: Browsers
#74This move by Microsoft may probably help Microsoft have Windows users using its browser, but I seriously doubt if it's good for the web. There are people claiming that Microsoft could easily fork from Chromium, but honestly, do you see that happening in the next few years? Having read that Microsoft's Edge team was a very small one, I don't believe Microsoft will fork Chromium anytime in the next two or three years (…
Disclaimer: independent browser author, unpaid.
Re: Browsers
#75OT, but I was and am still pretty steamed that Mozilla spearheaded the effort to deprecate WebSQL back in 2010 [1], while providing a replacement that left many disappointed [2] (see comments in both threads universally deriding the decision). The idea was that javascript libraries would be created that would replicate SQLite in the browser (albeit horribly inefficiently with terrible APIs compared to shipped-with-th…
Re: Browsers
#76Re: Browsers
#77Honestly I just see all this, even despite the author claiming taking time to "mull it over", as a knee-jerk reaction. There is little evidence that MS changing to Blink/V8 will have any tangible impact on the web. Microsoft has hardly offered much as far as competition and diversity goes since IE6, basically the only web "innovations" they're responsible for is a bunch of IE-specific APIs that didn't work in any oth…
The problem is this: HTML (+CSS) is supposed to be a standardized and recommendable format for publishing rich text with the expectation that it can be rendered for a long time to come. 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 w…
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.
Re: Browsers
#78I feel like I’m missing something, because I keep seeing blog posts that tell me a browser monoculture is bad (and the irony of Microsoft saying this is nearly too much), but none of them tell me why. I understand that it was bad in the IE6 days, but IE6 was also closed source and could only be run on Windows (see also the irony of Microsoft discontinuing IE on Mac, not wanting to compete with Safari, a browser made…
Google is a business like any other - and when they have the power to lever a monopolized situation - they will.
For example, they may start integrating technologies for which they have exclusive, or at least 'special' access. Can you imagine if all of a sudden Google apps start performing better than anyone else's?
Or what if they integrate technology that de-facto collects usage and behaviour - even from other domains - and then lever that competitively?
The power that Google already has, relatively unregulated is crazy. Remember that Google is the company that could change the outcome of elections ... possibly without us even knowing. They could drive markets up or down at will.
This would probably happen as a 'slow drip' - not one step being close enough to consumer awareness to create problems, and what with 'business friendly' politicians, nary a worry of legislation getting in the way.
They could introduce these technologies under the guise of 'improving user experience' (and maybe legitimately so to start), but other PM's, new CEO's etc. just take the opportunity before them. Why wouldn't they?
We worry a lot about 'Net Neutrality' at the network level, like it's a religion ... but that we don't worry about 'information neutrality' as well I find quite bizarre.
I suggest that having '1 major provider' may be a problem, doubly so if it's an entity like Google, and that frankly we don't really gain much from this fact at all. If Mozilla were the provider, great. Even Apple might be a better choice simply because they are not in the business of managing our information - at least right now, for them, it's a headache, not a revenue source.
So the concern is real.
Re: Browsers
#79Earlier quoted context omitted.
So the only competitor to Google’s monopoly on web browsers is... funded almost entirely by Google? Yikes
While Safari’s desktop market share is minimal and it really only competes with Chrome directly on Macs. No one is going to use Chrome only features that don’t work on iPhones.
Re: Browsers
#80OT, but I was and am still pretty steamed that Mozilla spearheaded the effort to deprecate WebSQL back in 2010 [1], while providing a replacement that left many disappointed [2] (see comments in both threads universally deriding the decision). The idea was that javascript libraries would be created that would replicate SQLite in the browser (albeit horribly inefficiently with terrible APIs compared to shipped-with-th…
You couldn't share SQL statements between the backend and the frontend. It's for the same reason it was shot down: SQL implementations are incredibly varied.
Ideally you'd have a translation layer, so instead of writing error prone string-y SQL, you'd have a type safe DSL in the vein of LINQ to SQL, Esqueleto, Slick, Quill, etc. that generates approriate SQL based on the target driver. That way you write the same query once, with the same model, and dispense with the inefficient square wheel that is IndexedDB + javascript.