What is the value of browser diversity?
daverupert.com
daverupert.com
View source would've been the first to go, though. I still remember arguments about whether that feature would survive back in 2005. I'm sure there were arguments about it even earlier than that.
For example, https://platform.uno/
This whole question is posed backwards... it's not about the value of diversity, it's about the destructive power of a lack of diversity. I would still hold out hope for a firefox empire if they hadn't bowed down to DRM against the desires of pretty much everyone. (1)
1. https://blogs.fsfe.org/agger/2014/05/15/mozilla-sells-out-ad...
They might also give less of a crap about being backward-compatible and not breaking your website. The relative "slowness" of the evolution of the web is a good thing. It's already too fast IMO.
That's the big problem. Unrestrained, Google will turn the browser into Google Web Client. We'll know that's happening when something comparable to Google Play Services appears in Chrome - a set of almost essential facilities applications need. By then it will be too late.
If you want to see what that looks like, see WeChat. There's WeChat for PCs.[1] It's not just for phones. It's an application which plugs you into the closed WeChat ecosystem. You can then access TenCent's replacement for the Web. Run approved WeChat apps. They have a level of control Facebook only dreams about.
Android : Google Play Services :: Chromium : Google Chrome
Chromium-based browsers don't seem to have that problem, so it's probably not a fair comparison.
Absolutely agree. I remember when IE6 was the most common browser, it was hard to find a site that wasn't viewable in any other browser, even the text-based ones, and JS-only "app-sites" (for lack of a better term) pretty much nonexistent. Of course a vocal subset of developers kept complaining about the web "being held back" and wanting to "push the web forward", and once Google took over, the rest is history...
Related article from 2015: https://news.ycombinator.com/item?id=9961613
Man, we have different memories. Mine are of a sea of “best experienced with IE6 and 800x600” messages on sites that had all kinds of CSS flaws in every other browser, including Microsoft’s own IE for Mac. Compared to today it was an absolute mess. Today’s JS-only app sites are pretty good for cross platform compatibility, despite plenty of other flaws.
If the idea were extended to production features, that's basically a walled-garden model for the web.
Origin trials are a reaction to the failure of shipping new features under prefixes, where those experimental features fossilized. By restricting origin trials only to sites that explicitly opt in and making those registrations time limited it's possible to get feedback on whether an experimental feature works without sites becoming dependent on it.
(Disclosure: I work for Google on unrelated things; speaking only for myself)
I can't find any concrete mention of this online, but at some point the "identity consistency between browser and cookie jar" flag to disable this was removed from Chrome. People on HN were making a big deal at the time over Chrome forcing you to attach your Google account to Chrome if you signed in through YouTube or another Google service.
What will plausibly change that? It’s not privacy. I know we like to pretend people care about privacy, but people don’t actually care about privacy, or they care about privacy in that they pay lip service to privacy, and go right ahead and keep using Facebook and TikTok.
Chrome got ahead of Internet Explorer because it was appreciably faster, and had features like tabs. Is it possible to differentiate on features these days? I’d like to think so, but momentum is such a force.
The same way it happened 10 years ago. If your non-techie family and friends for some reason have desktops or notebooks and not just phones and tablets, then ask them to use Firefox (or install it for them yourself). If they don't want to use Firefox but they have a MacBook, check if they're using Chrome, and if so, ask them to use Safari instead. If they're interested in getting a computer and want a recommendation, suggest they get a Mac instead of a Windows machine, and get them to use Safari or Firefox instead of Chrome. If they're trying to decide between an Android device and something from Apple, tell them that either is acceptable, but if they go for Android, ask them to install and use mobile Firefox instead of Chrome.
If a techie friend is thinking about starting a project and there's a chance that they'll choose Electron, ask them to consider building on top of WebKit instead. In general, spread the word far and wide that WebKit exists and avoid feeding into the popular misconception that the only choices are Firefox or Chrome. If you yourself are interested in alternative, non-mainstream browsers, look first for a WebKit-based one, and maybe consider contributing yourself. However, if you're already using Firefox and consider it acceptable, try to keep using it instead of switching to WebKit. If you're looking to switch, try holding on as long as possible, but make sure your criticism is clear. (And it should be well-informed, too; as Frank Hecker mentioned, albeit more politely, there are too many people talking out of their ass when it comes to Mozilla. That goes for detractors and advocates. The level of uninformedness every time Mozilla comes up—including the tweets quoted in the article—is pretty unreal.)
Looking at the StatCounter Aug 2020 stats [1], ignoring browsers less than 2% usage share (because I'm lazy), it looks like:
Chromium based = 74.53%. Safari = 16.82%. Firefox = 4.09% (but effectively 0 on mobile).
And that's with Apple forcing WebKit on Apple mobile devices.
Throwing Firefox's 4% into WebKit could be like strategic voting to strengthen the opposition, stop splitting the vote, and reduce Mozilla's cost of maintaining FF (keeping their recent layoffs in mind).
[1]: https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Su...
That's a fair point. I very much value FF's extensibility.
Of course not. If all browsers effectively turn into slightly different UIs for WebKit, that is zero diversity.
My suggestion is in terms of "strategic voting" [1].
As an example, there's currently no straight-forward way for the average Joe to set up ad-blocking on a mobile device (excl. DoH/DoT using PiHole, NextDNS, etc.). Many non-technical users are, however, familiar with the usage of ad-blocking extensions in their desktop browsers. They might not know the nitty gritty of how ad-blocking works, but most people seem to have one installed. Installing and using such an extension is just as seamless on Firefox for Android as it is on a regular computer.
If AdBlock is a built-in feature in Edge on Android, I assume you still need to opt-in through the settings (e.g., Settings -> Enable AdBlock), no? In which case the setup is Firefox is similarly easy: Addons -> uBlock Origin. Perhaps a bit less intuitive for an average user, but still very straight-forward to set up.
It takes a bit of work, but I am not under any deadlines, because I only work on personal projects.
HTML is very special in its flexible parsing without compilation errors, and I want to do as much as I can to preserve it.
JavaScript is different, because it evolved when browser competition was already in effect, so there was motivation to display errors when the page was written in the wrong flavor, as was practiced by Netscape from the beginning, and joined by IE in this practice.
HTML and HTTP is also special in that they are both human-readable and human-writeable, the former even by non-specialists.
There are not many computer languages out there that have a loose grammar like HTML and HTTP. We have a real gem on our hands, and it would be smart to hold on to it.
For example the differentiation between Firefox sign in and website sign in, the mobile extensions, ad blocking, background playing in YouTube etc... Things that Mozilla can do but Google can't.
People say this all the time, but I'm not sure I 100% believe it.
I suspect Chrome's current dominance was mostly fueled by Android and G-Suite. For many people, it became the default browser at work (thanks to enterprise adoption of G-Suite) and on their smartphone. People like familiarity and the incumbent (IE) had a terrible reputation, so Chrome logically became the new normal. I think for the average user performance and features were just bonuses.
It's not like Firefox performance or feature parity has historically been bad compared to Chrome. If performance and features were what people craved, Firefox would be doing fine.
Mobile Chrome usage is a matter “it’s there”. It’s the system webview, so you’re going to see it at some point, no matter what.
Businesses were slow to transition thanks to dependence on IE features and, in my experience, most "casual" users could not be bothered to install a new browser.
When I'm talking about Chrome's dominance, I'm talking about their dominance across the whole market.
It took a long time for me to convince my parents to switch to Chrome. Now I'm running into the same difficulty trying to convince them to switch away from it. I really think that kind of dominance had less to do with performance and features, and more to so with familiarity.
Infrequently (maybe 1-2 times a week), a website just will not work correctly on desktop Safari for me. As soon as I switch over to Chrome, it works perfectly. It's pretty common for websites to say something akin to "use Chrome for the best experience."
Safari is only relevant today due to iOS's popularity. If it weren't for the iPhone, Safari would just be another specialty browser for a tiny slice of consumers.
Well, at least you can switch... for free. In order to install IE6, you had to pay for an operating system license first, and it was only compatible with that OS.
Not that I'm saying that I like the browser monoculture we're heading into. But I think there're still some differences. You can look into Chrome's engine source code. I've yet to see Microsoft releasing the source for Trident or EdgeHTML.
(unless you meant IE 6, in that Chrome ships with "ActiveX"-like features no one else is implementing).
1) Developing and maintaing a modern browser is fantastically expensive and yet does not directly make any money. Few organisations have that kind of money to burn.
2) Chrome's (and Google's) market share gives them effective control of the "standard". You can fork all the code you like but if you ever stop singing Google's tune you've got a problem.
Safari is the only browser able to effectively fight back against these two issues, and only in a limited way (mostly by dragging its feet as much as possible). They are only able to do this because the iPhone gives them a captive audience. Other organisations don't have this advantage.
The <blink> tag, on the other hand, did result from a drunken outing (before my time) of first floor folks.
I agree that when there is no functioning, consensus-based standards process, browsers should innovate.
Between the fall of Netscape and rise of Firefox; Internet Explorer reigned the Browsers, and to be honest web and web development was a boring field. Once Firefox was released, web and web development revived. It popularized things like web 2.0, table-less css layouts, using web browser as an application development platform, etc.
Monopoly is never good, even if that monopoly is the best and perfect. There's innovation and strength in diversity. I always encourage people to never settle into one tool and always looks for alternatives out there.
Boring is good. It means a stable platform you can rely on.
It popularized things like web 2.0, table-less css layouts, using web browser as an application development platform, etc.
...and now we have sites that would be perfectly fine as static HTML being turned into app-sites that require running megabytes of arbitrary code just to render some static content, consuming resources on every single machine that visits them, every time they visit.
Why? Because we need a sandboxed, distributed application delivery platform, and every previous solution failed or didn't catch on: Java Applets, ActiveX, Flash, Silverlight, etc.
The business case of developing client-side applications trumps the need for a faster web at the moment. Is it ideal? No. Can it be fixed? Yes. How? Come up with a new rich application delivery solution that works in every modern browser in every modern os (mobile/desktop).
EDIT: I partially blame Adobe's hubris for the current situation. They should have made Flash player technology free & open-source and focused on monetizing Flash creation suites. Instead they kept it closed, and that led to Apple dropping it in iOS. After that, for all intents and purposes, Flash was done.
But it doesn't have to be a bad thing. I think the browser will continue its slow death, and eventually be replaced by something new, or maybe a suite of new things tailored to different tasks, rather than a single monolithic application. We've learned a ton from the web, and that knowledge will inform what comes next.
These days I'm much more concerned about the health of the internet (ie what's happening with QUIC, net neutrality, fiber rollout, ipv6, NAT, etc).
The internet will far outlive the web.
Edit: I stand corrected. I learned something about my browser today.
We are in an age of webassembly in browsers. For all the complexity of the modern web, riddle me this: What is the difference between a website executing arbitrary web assembly code in the sandbox of the browser, and any TCP connection sending a program which is loaded in a sandbox and executing on the user's computer? The difference seems to me to be simply the fact that it is integrated into the web, web browsers, etc. If we are truly at the point where this is how we want to do things--like, we want to write web apps in Rust and compile for web assembly--The web is becoming less distinct and therefore less valuable as a paradigm.
I'm not a user of any document-only web alternatives, but in this model, it would be pretty cool to see a re-separation into a web-of-linked-documents and network-of-sandboxed-remote-applications.
Society wouldn't swallow such a thing easily, but if they push the web far enough into a proprietary hellscape, desirable services will likely start to emerge outside of it. All it takes is for those services to be attractive enough to start drawing disenfranchised stragglers, and the next thing you know, your mom is downloading recipes off the new not-web web without a care in the world.
A WAsm program can’t magically bypass the browser and access OS services directly. Everything still needs to go through web APIs, and then you realize that it doesn’t make much difference whether your program bitstream is delivered as minified JS or WAsm.
It also isn't strictly true what you say, that "anything useful" is achieved via APIs. There are a number of examples of native libraries being compiled to web assembly with varying degrees of success. Just because what you write is all API based doesn't make it universally true for all programs everywhere.
Sure, but these are libraries. They don't provide any utility directly to an end-user. An application still has to wrap them into something that provides access through the Web APIs.
Building native libraries for a web target was already possible before WAsm using Emscripten. Surely WAsm is still useful as it offers better performance and memory management, thus expanding the range of projects that can be ported this way, but it's more like an incremental evolution than a revolution.
The team didn't know tons of people were going to be fired in the first place, so why would they know about such a change, or when it's their turn?
Slightly OT, but could someone explain to me why Mozilla was so adamantly against this feature? Allowing modular and dynamic HTML on the client without opening the pandora's box that is JavaScript seems like a clear value-add.
- I want to import static HTML for the same origin
- I want to import static HTML cross origin
The former is relatively inefficient, the static HTML for the page should have been served when the client requested it not served as a request for the client to request it. The latter is odd (I'm sure there are use cases though) and wasn't considered worth implementing a new HTML feature for when the JS method gave better control of the import anyways.
Mozilla's official musings:
https://hacks.mozilla.org/2015/06/the-state-of-web-component...
https://hacks.mozilla.org/2014/12/mozilla-and-web-components...
Im describing taking Mozilla's logic to the extreme to show where it has led us.
What you've extrapolated is what would happen if each interface for funxtionality were left to 3rd parties, not what happens if the browser implements first party interfaces in JS instead of HTML. E.g. in your example of extrapolating it all the way it wouldn't be "everyone has to create a button and draw it to the screen" it'd be "to create a button you can create it in JS instead of HTML"
And even then that's only assuming that because they made one choice on one thing the same choice would make as much sense for other things.
So even if a functionality could in theory be delegated to the browser, I think there are real incentives for sites to implement it themselves if this gives them more control about user behavior. A website just being WASM + canvas would actually be in the interests of many site operators.
I don't think the presence or absence of the "import HTML" feature would change a lot in this incentive structure, so this is more of a tangent. However, including the feature would at least have sites that don't want to go this way some support.
I think all the discussion and attention about trackers, paywalls, popups, etc paints a different picture. JS is turing-complete, which makes it extremely hard to in many cases impossible to predict what a particular JS program will do. It's much easier to verify that a HTML-only page won't do anything shady.
This is a problem created by browser diversity, not one that browser diversity would solve.
"opera africa lending"
Their stances on privacy and an open web don't seem to impact the browser any more than a chrome add-on would. Even this post is all about preventing Google from doing something malicious instead of the value they add.
Is this an efficient society, to spend the lives of hundreds of extremely intelligent people duplicating solutions purely to slow down another organization? Isn't there a better solution to this?
Perhaps we really are at that state in some ways/places, where just slowing down is a net good. Does the web really need all of this progress? Or is it more being dragged at increasing speeds in a harmful direction?
[0] I know about "Whipping Star" and "The Dosadi Experiment", but there may be others.
Monocultures are a Bad Thing, even if it seems inefficient to have multiple competing implementations of a standard. Unfortunately the article does a poor job exploring why, it just rambles about slow-moving standards, so here's a short article from the IndieWeb folks [0]. It's good that we have various browsers, operating systems, compilers, standard library implementations, etc.
(Crypto might be the exception, as implementations are very hard to get right, very costly to get wrong, and are highly reusable.)
Would a single browser make the Web fast? No, it wouldn't. If Microsoft Explorer had won and locked down users and websites, would the Web today be fast? No, the Web would not be fast.
Are there fast websites? Yes, I'm typing into one. I think the reason the web is slow is feature creep by both browsers and websites. Diversity is not the problem. Complexity is the problem.
It is very difficult to parse that sentence and come to your conclusion. I'll grant you, the author talks about innovation as well, but not in that sentence. You're free to mark it up to bad reading but perhaps it is bad writing.
Chrome being faster, better and more feature-rich makes users stay in their browsers longer which benefits Google directly (which some might argue is actually a bad thing). But still, Google would have an incentive to not let Chrome stagnant even if they had 100% of the market.