Seeing this play out for the last 25 years (a quarter of a century...whoa), I think diversity in the browser space is the only reason we still have an open web. I worked at a large media company that had a stake in the way browsers handled video (ie DRM) when the specs were getting written. The only reason DRM didn't get a stronger foothold was because the spec had to be developed in the open as it was.
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.
But we’re already kinda there. JS goes through so many layers: compilation, translation, optimization, minification, polyfills, obfuscation, that the code you see in the browser is only sorta kinda related to the original source which is what wasm would be. JS is already a just a compilation target for a lot of shops, might as well give people a saner target.
I'm in the same camp, but I haven't seen anyone seriously suggesting view source would ever go away.
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)
I think it's pretty clear what would happen if Google could controlled the web through a browser monoculture. They would rapidly transform it into something more akin to a closed app ecosystem, with more DRM and proprietary features.
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.
... browser monoculture. They would rapidly transform it into something more akin to a closed app ecosystem...
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.
Yes. As Chrome has to compete with more Chromium-based browsers (especially the new Chromium Edge), I expect Google will move more feature development from the open source Chromium core into closed source Chrome code.
Android : Google Play Services :: Chromium : Google Chrome
The relative "slowness" of the evolution of the web is a good thing. It's already too fast IMO.
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...
> I remember when IE6 was the most common browser, it was hard to find a site that wasn't viewable in any other browser
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.
Let's also remember that Firefox broke Internet Explorer's dominance. Without that initial step, who knows what Chrome would have looked like, how much reach it would have had, or whether Google would have seen it as a worth while endeavor.
Chrome Origin Trials (https://developers.chrome.com/origintrials/#/trials/active) has some of the scent of a closed ecosystem -- Google gets to decide who can use certain browser features (if only for limited numbers of users, right now)
If the idea were extended to production features, that's basically a walled-garden model for the web.
If there's an experimental feature you want to test out on your site, you should be able to register for the origin trial. I don't think it's something where Google decides who can register?
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)
Well, it does require a Google account to register for origin trials. Google could conceivably block access for a domain to use origin trials, if they wanted. It may be fully open right now, but perhaps not in the future. These are hypothetical scenarios but very possible.
That’s a pretty big “if”. I could apply the same logic to anyone that releases a closed beta of their software. “If they were to release the production version to a closed audience...”
Or forcing you to login in both the browser and the websites they own.
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.
> So, if browser diversity is important, how do we keep it?
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.)
WebKit has a problem that nobody of consequence ships it on Windows and Android, the two largest operating systems by usage share. Until someone fixes this, Firefox is the only meaningful alternative.
Right, and it makes me wonder if it'd be better for Firefox and diversity of browser engines for FF to use WebKit.
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).
I remain unconvinced that a Blink-WebKit duopoly would be a better situation than what we have now. For one, Apple has more than enough money to fund WebKit development, and I am not sure the sudden addition of the Firefox team would be welcomed or beneficial there. And while Gecko and WebKit share many of the same goals, they diverge in parts of the browser I consider critically important, such as extensibility. Even if Firefox has low market share I consider their contribution to the browser space to be much more than their usage share would imply.
It may no longer be the case but didn't chromium start as a webkit fork? would Firefox being another Webkit fork be as usefull as a fully seperate implemntation of the standards?
For regular consumers, I'd say the biggest value proposition for Firefox on mobile, at least on Android, is the support for browser extensions such as uBlock Origin, and thus mobile ad-blocking.
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.
Edge on both Android and iOS has Adblock built in and Safari on iOS can have ad blocking very easily enabled with a content blocking app like AdGuard. Firefox is arguably harder to set up for ad blocking than either of these.
Yeah, I was only speaking to Android in my post, and iOS is a different beast with different restrictions when it comes to browser implementations. Is Microsoft in any way competitive or innovative in the browser sphere? I haven't used Windows for ages so I'm out of the loop there.
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.
I am helping keep it by taking the time to test my websites in all the browsers I can get my hands on, including classics such as Netscape, IE, Mosaic, Lynx, and Opera (pre-WebKit).
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.
I think that the general guideline here should be to enable good features that are disabled on chrome due to dark design patterns, and to emphasize and focus on these differences.
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.
> Chrome got ahead of Internet Explorer because it was appreciably faster, and had features like tabs.
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.
As someone who was around at the time, it was absolutely because Chrome was a faster and better browser. If I recall Gmail was still in private beta then and Android hadn’t made a big mark yet.
I think you and the GP are talking about two different things. Chrome’s early adoption on desktop was partly due to people finding it a faster browser, and partly users switching browsers without particularly thinking about it because they were exposed to incessant advertising for Chrome on Google properties. But Chrome definitely went to a whole new level of dominance with the rise of mobile, where a substantial number of people around the world use primarily Android phones for browsing, and thus they start off with the stock browser and never think to change it.
Yeah, I am an old man, and in my dotage, I was definitely thinking of the early desktop Chrome era, where it had more features…and now that I really dredge my memory, it was seemingly the time of never-ending ActiveX security exploits.
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.
I was also around at the time. Chrome's performance and features were what made it popular with "power users", but they're only a fraction of the market.
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.
We're already at the point where Chrome is the modern day IE 6.
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.
> We're already at the point where Chrome is the modern day IE 6. [...] As soon as I switch over to Chrome, it works perfectly
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.
I think you have it backwards. Safari is IE 6 (in that things don't work as you'd expect them to). https://caniuse.com/ shows Safari as missing many standard features.
(unless you meant IE 6, in that Chrome ships with "ActiveX"-like features no one else is implementing).
Generally, I think that decentralization of power is a really important aspect of our society, and we should fight to preserve it. Just like we fight for free speech. This is because power tends to become centralized, unless we intentionally strive to do the opposite.
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.
It doesn't matter if Chrome's code is open, what matters is that Google controls Chrome's updating mechanism. The ability to fork the code doesn't mean anything if nobody uses your fork, and if you can't prove to site developers that people are going to use your browser then they won't go to the trouble of making their sites work in your browser, which means your fork has achieved no meaningful change.
I was going to link to a comment of mine that I bring up in response to this comment, when I realized I had made it in response to you. I'm still linking it here, since the comments there (and here) remain the same: https://news.ycombinator.com/item?id=24327219.
And my reply to your comment then still stands. The day a sufficient number of of organizations or companies reject the influence of Google, a viable fork will start to exist. So far no such will exists anywhere so this does not happen but the future is never a linear regression from the present.
However today we have more than just an opportunity. We have a living example for a good competitive browser, and I think we should aspire to maintain it.
Most of the web features beyond html 1.0 were 'proprietary' platform specific features developed internally at Netscape and rolled out with no consensus or standardization. Brandon Eich though something was a cool idea so he shipped it, end of story. I wish Firefox and Safari would start solving problems again and let other vendors decide wether or not to adopt their solution or develop their own. As it stands, google's vision is that all webpages are multi-thousand line programs that require full asynchronous network and local storage access just to display a news article. Requiring js for simply getting the user agent string (and increasingly everything else) is how they keep one step ahead of efforts to stop fingerprinting tracking and targeting.
In almost everything, advancement comes from competition, and competition comes from diversity. Without diversity, things will become stale.
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.
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.
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.
Fair points, but web today is not what web was intended for. It was supposed to be a document delivery network, but it became an application development platform.
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.
I used to worry about these sorts of questions much more. At this point I'm fairly convinced it's already past saving. The current state of browsers is pretty scary. Combining the text-web and the app-web into one client has caused serious issues.
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).
Ironically this is the only reason Safari has the market share it does. If Apple didn't force its browser on iOS users, Chrome would dominate there too.
I'd be interested too. I can't find the stats atm but I wouldn't be surprised if it were around 50%. Still, my hypothesis is it mostly survives because of iOS. Sites must work with iPhones therefore it takes little if any effort for macOS Safari to be supported.
Wouldn't this be solved if they would switch to Chrome as well? Note, I'm not saying they should. But this is exactly the kind of problem that a global single engine would solve. The same things could run on every device where that engine is available.
I'm almost to the point of being indifferent whether companies "destroy the web" through things like a browser monoculture. It would be a tragedy, but you can only ask people to deal with so much, and the web != the internet.
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.
WebAssembly is a red herring because anything useful that these applications do is enabled by the available APIs.
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.
Right, it necessarily affect much in terms of the way the program's functionality is written, but hardly irrelevant or a "red herring". The fact that any language can be compiled to a portable assembly language is important for the model we are discussing, because it isn't bound to local machine architecture. If a browser is simply a remote-program-sandbox, it is an important feature that remote programs are portable to the same degree web assembly is. Otherwise you'd have a remote app that people on ARM couldn't execute, and things of that nature.
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.
> "There are a number of examples of native libraries being compiled to web assembly"
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.
I wonder what a fairly lightweight webapp standard wrapped around WASI might look like. Especially if it had a really nice high-level UI toolkit built it.
> This can be agonizing while you wait for a much needed feature to roll out in all browsers, only to find out five years in the process one browser refuses the entire premise of the feature (RIP HTML Imports).
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.
Some small fraction of less than 1% consider "without opening the pandora's box that is JavaScript" a "clear value-add". The JS method already existed and worked for dynamic content as well. The latter part was Mozilla's reasoning. Also for a while they wanted to see how ES6 modules worked out and apply those lessens before committing to a certain import design for HTML. What they took back was the HTML imports proposal wasn't configurable enough and to make it that configurable you'd basically have the existing JS import method but fossilized and for fewer use cases. Looking at HTML imports it really breaks down into 2 types of use:
- 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.
Why not just replace html entirely with a vm? All websites are obfuscated webasm programs that get a frame buffer to write pixels directly to the browser window. You want to be able to select text? Pray the website implements that "feature". Right click to show source? Ha. Good luck figuring out what the code is doing.
Im describing taking Mozilla's logic to the extreme to show where it has led us.
Requesting the content and injecting it into the document are both first party browser apis though. They didn't want for everyone to make a custom implementation they wanted for people to use the existing browser APIs. Just because something is done in JavaScript doesn't mean it's 3rd party, most of a browsers first party interfaces are in JS.
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.
Many site authors have an active interest in retaining the full control about what the user can do on their site, even against the interests of the user.
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.
Thanks for the pointers. I found those pages before, but they didn't seem very understandable to me, as the reasoning seems to boil down to "the feature can be replicated in JS, so we won't need it", so I was wondering if there was more behind it.
> Some small fraction of less than 1% consider "without opening the pandora's box that is JavaScript" a "clear value-add".
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.
Framing this in relation to diversity is weird. The real question is what is the value of competition in the browser market. Which has an answer that is much more obvious. Because without it, Google would control the entire internet browsing experience.
The web is a collection of standard protocols which browsers support because they do not have enough influence to push their own protocol, which would undoubtedly serve the interests of the company who develops and distributes the browser at the exclusion of other would-be browser competitors. IE6 is a perfect example of what happens when a lack of browser diversity allows one browser to push their own, self-interested, proprietary protocols.
I use both browsers on my desktop simultaneously. I use Firefox for my Gmail and Facebook, so that my tracking is sandboxed in that browser along with tracking cookies, and most other browsing through chrome. If there’s a difference in speed between the two it’s largely academic, because I can’t tell the difference. Plus I’m on an 8 year old desktop that I’ve yet to upgrade.
Browser rendering is what a lot of “normal” users equate with what the Internet “is”. With that in mind, it’s obvious that a lack of browser diversity, open standards and democratic process by necessity leads to a less free Internet for everyone.
> Those features aren’t bad, just not my favorite. “Bad” usually comes in the form of unilaterally shipped features that take a long time to fix, retroactively standardize, or undo (e.g. vendor prefixes, <dialog>, window.event, etc). Again, once shipped, they’re shipped. They linger around in the platform, working in some browsers, never in another, frustrating developers. It produces brittleness.
This is a problem created by browser diversity, not one that browser diversity would solve.
Google has been screwing up the web stardards for a long time (one infamous example is whatwg/url). Pretty clear what would happen if Chrome controls the web.
Zomg I love standards when they don’t benefit the implementation I prefer, but fuck standards when they benefit the implementation I prefer. Great way to encourage companies in the future to contribute to standards you dumb short sighted hypocrites.
Language aside, I do agree. People should be happy that companies are contributing to standards rather than forcing them down people's throats by virtue of having a giant user base.
I've been wondering recently if you could classify Mozilla under the Bullshit Job heading. It seems they only exist at the moment to prevent Google from being regulated.
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?
Frank Herbert has a few writings [0] about a future galactic state that moves at such speed that they have needed to create an official Bureau of Sabotage, whose purpose it is to allow down the working of government to the point that it can be considered and understood in all its implications by the people.
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.
> 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?
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.
Yes, that was my reading of "slow" as well, but ironically, GP's point applies under that reading as well: When Microsoft dominated the web, the pace of spec evolution slowed down as well.
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.
Yes, based on that sentence alone, it would be ambiguous. But the author expanded on this with a whole section clarifying what he meant, which is about the rate of feature development and adoption. Not sure if you missed it, but it starts with "I think the Web platform’s most frustrating aspect is also its greatest asset: it’s slow. It’s not just slow, it’s “it took 10 years1 to ship the <main> element which is just a spicy <div>” kind of slow. It’s glacial."
I think that sentence is misleading, and also that the author eventually gets around to making their meaning clear in the later section headed "Slow, like brisket." That section expands on the somewhat opaque initial formulation.
The difference between Chrome and IE is that IE didn't really benefit Microsoft in a noticeable way. They had no incentive to improve it once they had a monopoly.
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.
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.