To me it's uncomfortable how much Google's tactics with Chrome resemble Microsoft's "embrace and extend" from the late 90s.
I'm pretty sure Emacs came up with this idea: "embrace and extend" TECO.
They seem to want everyone to make Chrome apps, not web apps. If that happens, ultimately we all suffer from the loss of an open web.
Stallman seemed to want everyone to make Emacs apps, not TECO macros. If that happens, ultimately we all suffer from the loss of an open TECO community. (How is a Chrome/Chromium App different from a Gtk3 app or a Tk app? Those aren't open standards. They're just libraries the authors wanted to write and to share with the world. Not everything needs to be a standards process, sometimes you just do something and see if anyone likes it.)
More seriously, there are quite a few differences between adding a feature to an open-source project and adding a feature to a web browser shipped as an inseparable component of the operating system installed on 99% of personal computers. As a thought experiment, imagine you want to use some dongle you just bought. There is a driver that comes with Windows, but you use Linux. Do you think you'll be using your dongle anytime soon? Probably not. But imagine the driver comes with FreeBSD instead. While you probably can't use the driver code verbatim (different APIs), you can probably port it in significantly less time than it would take to reverse engineer. So while FreeBSD may have bypassed the standards process for supporting that dongle, it still works for you with very little effort.
I think if you're going to get outraged, it should be about how much memory Chrome uses, not that websites can now have prettier notifications when running under Chrome.
That's a cute argument, but Microsoft never held a gun to a developer's head and said "use this feature or else!" Neither will Google.
IE was just a nice feature to have available. If you happen to need a web browser control, there's one built in for you right there on every copy of windows. You could get in touch with Netscape and figure out what's required to redistribute their runtime, or just make the call to load up the ActiveX control. whichever is easier for you, dear developer.
Notifications will work great on chrome, and non-chrome clients will kinda degrade gracefully by throwing a javascript error. It's fine. it's just there if you decide you need it, no gun to your head.
> That's a cute argument, but Microsoft never held a gun to a developer's head and said "use this feature or else!" Neither will Google.
I'd rather not go back to websites that have to specifically say which browser you have to run them in on the homepage. The web needs to be based on standards, not proprietary code.
Standards are two ends of one spectrum, but the code that the article is about is open source, so it's neither proprietary nor standard. It's just a feature in an open source project.
I think you're right. Back when ActiveX was the thing to hate, it was annoying because web developers didn't care to support multiple browsers, not because ActiveX simply existed. Using ActiveX was probably a rational solution when you realized that 99% of your users could use it, and it was just those crazy Mac and Linux users that were out of luck. It sucked when you were a Mac or Linux user, that's for sure.
Now that each browser has a significant number of users, web developers have learned that they need to either target the standards or maintain different versions of their application for every browser. And pretty much every web site and app I've seen does this: it works the same in Firefox as it does in Chrome. (Actually, for many years, my former bank said "this website only supports IE and Firefox, don't use Chrome". But Chrome worked anyway.)
So I think complaining about notifications in Chrome being the end of the open web is a bit premature. The open web began when developers started trying to support multiple browsers. It will only end when they stop doing that.
Microsoft purposefully built the add/remove applications list using the IE control despite it being a poor use for the job just so European courts couldn't force them to decouple IE from Windows
>Stallman seemed to want everyone to make Emacs apps, not TECO macros. If that happens, ultimately we all suffer from the loss of an open TECO community.
Only nobody cares from the TECO community -- and you can still use TECO for your texts without the new "apps".
But a web where people code for a specific browser, is less fun (or even downright unusable) to surf with another browser. We learned that in the Netscape/IE wars era.
>More seriously, there are quite a few differences between adding a feature to an open-source project and adding a feature to a web browser shipped as an inseparable component of the operating system installed on 99% of personal computers.
That's all well, but browsers can gain market share too. IE had a minority share at first, despite being bundled with Windows -- people just preferred Netscape. So that Chrome is not bundled with an OS is not much guarantee.
Android has its own webkit-based browser. The Nexus-branded devices (Nexus 4,7,10, possibly the Galaxy Nexus) come with Chrome and not the Android browser.
Don't forget ChromeOS, where literally the only user-facing application is Google Chrome. This OS ships on thousands of devices every day and takes browser-OS coupling to the furthest conceivable extreme.
While true, I'm not sure how that's particularly nefarious. It's just another platform that's not an existing platform. iOS is like this. Android is like this. FirefoxOS is like this. They all are their own ecosystem and have their own APIs, and they all seem to be working out pretty well for both developers and users of both native apps and web sites.
What would be worrisome is if the platform creators locked them down in such a way as to prohibit choice; if Chrome were ported to iOS and Apple denied permission to distribute it, for example. But that's simply not happening anywhere anymore. Every owner of a locked-down platform is being pretty open about letting users choose which apps to use, even for core functionality like the web browser. Perhaps this is the lesson we learned in the 90s with the browser war and we are actually trying not to repeat the past!
I'm personally quite attracted to the idea of a native app that I can program in Javascript, and wouldn't want ChromeOS to not exist simply because of concerns of being "unfair". I never really used my laptop much because it was too hard to keep in sync with my desktop. But since I switched to ChromeOS for my laptop, I've used it a lot more, because everything stays up to date. Yes, I have to give some control to Google, but I always have the option of compiling it from source and making my own sync server. So overall, I'm really happy that ChromeOS exists and is open-source, even if there is no standards process for web-browser-centric operating systems :)
>What would be worrisome is if the platform creators locked them down in such a way as to prohibit choice; if Chrome were ported to iOS and Apple denied permission to distribute it, for example. But that's simply not happening anywhere anymore.
Wait -- that does happen. For example Google wasn't even allowed to port Chrome to iOS. What they did is they made a "fake Chrome", all UI, which underneath uses the iOS Webkit engine.
I'm pretty sure Emacs came up with this idea: "embrace and extend" TECO.
They seem to want everyone to make Chrome apps, not web apps. If that happens, ultimately we all suffer from the loss of an open web.
Stallman seemed to want everyone to make Emacs apps, not TECO macros. If that happens, ultimately we all suffer from the loss of an open TECO community. (How is a Chrome/Chromium App different from a Gtk3 app or a Tk app? Those aren't open standards. They're just libraries the authors wanted to write and to share with the world. Not everything needs to be a standards process, sometimes you just do something and see if anyone likes it.)
More seriously, there are quite a few differences between adding a feature to an open-source project and adding a feature to a web browser shipped as an inseparable component of the operating system installed on 99% of personal computers. As a thought experiment, imagine you want to use some dongle you just bought. There is a driver that comes with Windows, but you use Linux. Do you think you'll be using your dongle anytime soon? Probably not. But imagine the driver comes with FreeBSD instead. While you probably can't use the driver code verbatim (different APIs), you can probably port it in significantly less time than it would take to reverse engineer. So while FreeBSD may have bypassed the standards process for supporting that dongle, it still works for you with very little effort.
I think if you're going to get outraged, it should be about how much memory Chrome uses, not that websites can now have prettier notifications when running under Chrome.