Every time Firefox introduces a cool new feature, they emphasize how it's standard, or being put into the standardization process, and how every web developer will be able to use it.
Chrome? Not so much. And it isn't just that this news article left something out — the official Chrome blog[1] never hints that this feature will ever work on anything but Chrome.
To me it's uncomfortable how much Google's tactics with Chrome resemble Microsoft's "embrace and extend" from the late 90s. 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.
Part of this communication difference is that the Chrome blog's audience is users, people who aren't concerned with web standards.
The Chromium blog, however, is where the developer story is told. Chrome 28's was covered the same time as the post you link: http://blog.chromium.org/2013/05/chrome-28-beta-more-immersi... Here, the W3C standard fullscreen API was covered for Android as well as the web standards WebGL and WebRTC being available through about:flags. Then CSP, @supports, Custom Elements.. all standard stuff.
Mozilla does a great job communicating the web standards story of the features they're working on. This definitely inspired the Chrome team when we released Blink, so we worked on http://chromestatus.com to capture the full cross-browser standardization story and give everyone a means to shame Chrome if we're implementing something for the web platform that doesn't have cross-vendor buy in.
There is a lot of exciting APIs available in Chrome Apps but it's certainly not slowing down on the web platform side of things. I would definitely recommend you check out the "Intent to Implement/Ship" threads [1] on blink-dev. Here you can see the activity and discussions around compatibility risk, standardization and responsibly adding new features to the platform.
That's great and all, but you didn't address the issue. We're discussing this new notification system that will only ever work properly on Chrome. The latest posts on that chromium blog are even worse:
1) Richer access to Google services and better OS
integration in Chrome packaged apps
- Identity API - Google only
- In App Payments API - Google Wallet only
- Analytics API - Google Analytics only
- Native Messaging API - The problem we are discussing
2) Dart - obviously a way to create a two-tier web with
Chrome being the only option for performance. (You can
bet it will be incredibly difficult for other browsers
to package/integrate the Dart VM easily).
Your roundabout answer to this question leaves me very concerned for the future of the web if Google actually thinks this isn't a problem. I do believe it's looking like the only responsible option for an open web is to ditch Chrome and try my best to lower Chrome market share.
We're going to look back on this in 5 years and kick ourselves over letting Google do this. I hate to say it, but Google is now the biggest threat to an open web.
To be fair, the first one you cited is for Chrome packaged apps, so I feel like it's a little different than special APIs exposed to normal web page javascript. It's the difference between saying "build apps for our browser, we give you powerful features" and "build web pages that only work in our browser."
Now, if you think it's bad that Chrome is trying to entice browser app developers with powerful feature sets, that seems like a related but different complaint.
It's possible I'm unclear on the scope of the Open Web movement. When it refers to web technologies, does it mean technologies employed in the service of presenting web pages (i.e. everything you can do with javascript, html, css, etc.), or any technologies that a browser serves as a platform for? Because the latter seems like a wider scope that encompasses more than just web pages.
It's not just this though, there are even more damaging cases of embrace extend extinguish going on right now like With PepperFlash for example.
There Chrome has broken video recording three times the past year by pushing untested code, it's not possible to permanently disable it and the last change actually requires users to click both the Flash allow box and the WebRTC allow box!
That's without even mentioning the bug that if a user doesn't notice the second allow and refreshes the page, like every user does, the Allow box is never shown again.
I think other folks covered this one, but yeah the difference here is that this expanded notification API is for Chrome apps, much like Mozilla has non-standards track APIs that are targeting Firefox OS apps.
Chrome supports the W3C standard Notifications API: http://caniuse.com/#feat=notifications as well as edits the spec for it: https://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.h... This works today in Chrome, Firefox, Opera.
The permission model on packaged apps is completely different, and allows for APIs that have a lot more power (raw USB, TCP access) and as such, it's hard to find a way to expose them to the open web without permission bar overload. :/ I'd personally love to find a way to bring some of the powerful APIs that browsers are developing and exposing them to the web, but it seems like we're not there yet.
For Dart.. think of it as another compile-to-JS language that was designed for large app authoring & maintenance productivity. Its performance as compiled JS seems to be pretty good already so you can target all modern browsers with Dart apps already.
But, ultimately, I'm an open web kind of guy. My money's on APIs that the web shares and I see compatibility across the web as the characteristic that drives its power and reach. Chrome's working on a lot of APIs for the open web platform (see my links above) and is constantly working with other browser vendors to get feedback, buy-in, and identify the best APIs that the web can share.
It's worth noting that all of the APIs you mention in (1) are only available to Chrome packaged apps. These are essentially the .exe files of Chrome OS. They cannot be hosted on webpages (otherwise Google calls them hosted apps, and they can't access these APIs) and can only be distributed and accessed via the Chrome Web Store.
It's essentially not much different from Windows having Windows-specific APIs for downloadable programs. "Chrome Packaged Apps" are the downloadable programs of Chrome OS.
>Dart - obviously a way to create a two-tier web with Chrome being the only option for performance. (You can bet it will be incredibly difficult for other browsers to package/integrate the Dart VM easily).
No, it's an IR that happens to have an identical representation in JavaScript. But that clever hack gets muddy already with things like Math.imul. And it's going to diverge far more given the demand for e.g. threading, sync primitives, shared memory, and vectored operations. I honestly don't see how asm.js can be made into anything beyond its current demo state without major changes to the JavaScript language and APIs.
Those changes would benefit regular JavaScript as well, so it's not a divergence. Regular JavaScript developers are already asking for SIMD (and that's why Dart is implementing it, after all). They were asking for more predictable math operations, and Math.imul is good for that. Threading too. Changes made for asm.js lift all boats.
The parent comment said that asm.js was a subset of JavaScript. You said "no", but none of the things you said contradict that. asm.js is, right now, a subset of JavaScript. Which, of course, is its entire raison d'être.
My statement was correct. It's not JavaScript, which is why you use a keyword to switch to a different compiler mode. It's a clever hack to use an equivalent subset of JavaScript as an IR (accepting a few polyfills). However, it's not exactly honest to frame it as "just JavaScript."
What really does worry me is the ugly things that will be necessary to make asm.js genuinely viable as a platform. Yes, some proposals will have general utility for JavaScript, but many will not. And some will be downright dangerous. For example, how are you going to address pthreads compatibility, which e.g. Epic is saying they need?
> My statement was correct. It's not JavaScript, which is why you use a keyword to switch to a different compiler mode.
I'm afraid your statement really wasn't correct. asm.js is both syntactically and semantically JavaScript. OdinMonkey is a pure optimization; any observable divergence in behavior (other than timing, which of course all engines are allowed to do) is a bug that will be fixed. The fact that SpiderMonkey uses a prolog directive (not a keyword), which is also of course valid ECMAScript, to trigger a different kind of optimization does not change the fact that it is a valid implementation of JavaScript.
I'm sorry if I'm coming across negatively. It's not my intent. And please don't presume that my concerns about asm.js are in any way tied to projects that other people in Google/Chrome work on, or that I'm entirely supportive of them. That said, I am curious if you really are committing to to future versions of asm.js not using any divergent APIs or observable divergent behavior from JavaScript as used on the web?
Diverging from JS would require standardization, but it's too early to consider something like that. I don't know what our ultimate plan for threads will be or where asm.js will eventually end up; there are plenty more discussions to be had.
Thanks, that's a bit of helpful context. I appreciate that it's too early to say where exactly asm.js will go. I'm just afraid of private APIs or other divergence from JavaScript in order to mainstream asm.js. Sorry if that apprehension came across as overly negative.
I also want to add that the "it's just JS" thing is not somehow an argument of the shining nobility of asm.js. It's purely practical as what we believe is a viable approach to moving the web in the same direction that e.g. the PNaCl team has been trying to move it. I get so disheartened at these mud-flinging contests. Our companies want the same things for the web (and we <3 the PNaCl team and have friendly conversations with them!). We share the same goals. We just believe that asm.js is a more viable approach to getting the web there.
I'm pleased to hear that - my perception has been that Mozilla has been moving in a more isolated, NiH-ish direction of late (not just dart but e.g. h264 support in <video&rt;). Does this mean there's a chance of PNaCl support being added to firefox if it shows itself to be effective in practice?
Dart and PNaCl have been rejected by not only Mozilla but also upstream WebKit (Apple) and Microsoft. In other words, Google is the only proponent of these technologies. I have no idea how you could paint that as "isolated" or "NIH".
"use asm" is not a keyword. It can be ignored, as V8 does. This is possible because asm.js is JavaScript as defined by ECMA-262. It executes according to the semantics specified in that document.
I don't really want this to turn into a back-and-forth, but it's unfortunate that this has devolved into outright accusations of dishonesty.
Note that I framed it as "not exactly honest" rather than saying it's an overt lie. Because I don't consider it an overt lie, but it's hard not to read it as a bit equivocal to claim that asm.js as just JavaScript.
And really, I'm far more concerned with the future plans, particularly with regard to things like multi-threading APIs. I don't see how those can be incorporated in a way that supports asm.js as an easy target for existing code while not causing it to diverge from JavaScript as used in the browser.
To be clear, I really do think those of you working on asm.js have the best of intentions and really want to make something that works for the Web. However, I expect that supporting existing codebases and commonly used APIs is going to mean compromises. They'll start small and polyfills will work well enough, but I just don't see how asm.js doesn't eventually diverge in significant ways from normal JavaScript, or end up introducing special purpose hacks. Maybe I'm wrong, but I don't see my position as unrealistic.
It's an IR that currently is compatible with JS, but that's not necessarily the case longterm. And I personally don't see how it can retain that property while adding some of the things the platform needs (e.g. thread support that works for existing codebases). I asked dherman this elsewhere in the thread, and it seems like diverging from JS hasn't been ruled out. https://news.ycombinator.com/item?id=6023902
So, my concern here is that asm.js will either be forced to diverge from JS to make it generally useful, or it will need to add APIs to JS that are not appropriate outside of asm.js. If it gets to that place, then I feel that the compromises necessary for asm.js were a waste, and it would have clearly been better to just introduce a new IR that wasn't bound by the constraints of asm.js.
asm.js is a subset of javascript. Nothing more. If you implement the optimisations without needing the "use asm" then you just have the same benefits for non asm tagged code -- and all the benefits of asm.
The "use asm" is totally optional functionality wise.
Did you actually want to say "OdinMonkey was implemented very quickly, in about a month"?
I am not sure I understand what people try to prove or imply when they say that.
OdinMonkey takes an extremely limited statically typed language with an almost non-existent runtime library as an input, checks the types and pipes fully typed IR further through the existing backend (IonMonkey). Does it come as a surprise to anyone that this can be implemented quickly?
> Dart - obviously a way to create a two-tier web with Chrome being the only option for performance.
The performance of the generated JavaScript is okay. Typically, it's somewhere around 75% of the performance of handwritten JavaScript and it's still getting better.
Those -25% may sound like a big deal, but it's comparable to the performance from JS engines from last year.
I'm pretty sure dart2js runs faster than Dartium. Dartium is just for reducing the time the edit/test cycle takes and from what I've read on the mailing list, not intended to be something that end-users will ever see. In that respect, Dart is exactly like CoffeeScript or the many other attempts to fix Javascript.
The Dart FAQ says:
Q. Is Dart going to divert community effort from JavaScript-based web development?
If people like Dart and use it, then to a certain extent, yes, but isn't this true of any improvement to existing web development? Nothing is zero-effort to learn or 100% back-compatible to legacy browsers, so people use both new and old. You might look at it this way: Google is putting significant effort behind both Dart and JavaScript, choosing to develop Dart while at the same time using JavaScript extensively, and working on JavaScript tools, implementation, and language spec. We're doing both because we think Dart is worth it.
Server-side web programming finds room for many languages: does Python divert effort from Perl, and does Java undercut C++? Again, to a certain extent, yes they do, but people generally consider that a healthy situation, better than if we all used a single programming language. Multiple languages have allowed for faster change than any single language has achieved through a standards process. Furthermore, languages coexist in different niches: does Groovy really compete directly with C++? People face different engineering tradeoffs and choose different languages to meet them. Ultimately, we think client-side developers should have this kind of flexibility.
Q. Is Google planning to put Dart under the control of a standards body?
Yes, we hope to. Once Dart reaches a certain level of maturity and acceptance, we expect that a standards process will be the next step.
As for the various APIs you describe above, those are all for packaged apps, which really have nothing to do with the web except that they happen to run inside Chrome. It's like complaining that iOS in-app purchases go through Apple, or that Gnome has Bluetooth support. (Or even that Firefox extensions don't work in Safari.)
You're right. I'm still pretty sure Dartium isn't supposed to end up in the hands of end-users, but is more of a benchmark to see how much dart2js can be improved. But since this is HN and there are always the conspiracy theorists around, I really have no idea what the plan is.
(Remember that you can write server-side software with Dart, too, so the VM can exist for that purpose without being some evil scheme to eliminate Javascript. Not that I would mourn the passing of Javascript :)
>You're right. I'm still pretty sure Dartium isn't supposed to end up in the hands of end-users, but is more of a benchmark to see how much dart2js can be improved. But since this is HN and there are always the conspiracy theorists around, I really have no idea what the plan is.
I'm not sure. If that was the case, I don't think they'd put a hot ass team (including Lars Bak IIRC) on the Dart VM and spend millions on it.
I believe Google would very much like Dart (the VM) to succeed, but they know that realistically it can not for now, and so they invest in the JS translation in order for it to be a credible player.
As you mention, one way that Dark can make a dent, though, is on the server side. It's a decent dynamic language, that's an order of magnitude faster than Python/Ruby. With enough library support, it can get places that even node, tied as it is to the async callback model, might not. A decent web framework, for example, could have Dart see a lot of adoption.
That said, it's still too early to tell -- it's not even out of beta yet.
The whole point of dart is to have a dynamic language for the web that is type-safe and super fast by default. If Dartium never gets into Chrome, then that would make Dart kind of useless. The plan is to implement Dartium into Chromium once Darts stabilizes.
Dart is already very useful, so I disagree with that assertion. It's the Dart compiler that handles type-checking, not the runtime. If you write "String foo = 42; return foo + 8;" and compile without type checking, you generate code that will work fine. But if you turn on type-checking, you get the type error at compile-time.
Furthermore, the compiler is responsible for resolving the dependencies your main program uses ("tree shaking" to remove stuff you don't actually use [1]), so there has to be a compiler even if your browser had a Dart VM built in.
I use Dart because it allows me to organize and test my code in a way that is very inconvenient with Javascript. Any speed improvements or IDE support is incidental, I have not yet had any speed problems in Javascript and I don't use their IDE :) The type-checking, library system, and the language itself is wonderful, though.
You completely skipped the answer about Native Messaging API, is worrysome. And RyanZAG nailed it, the chromium blog is full of references to Google-only apis
> Every time Firefox introduces a cool new feature, they emphasize how it's standard, or being put into the standardization process [...]
No, not really. They just added `let`, iterators/generators, destructuring assignment, etc in 2006 without asking anyone. Today, you can even use it without opting-in (via: type="application/javascript;version=1.7"). This stuff is supposed to be in ES6 in the future.
Same deal with APNG. They just added it in 2008. It also isn't standardized.
Well, all browser vendors are like that and it's generally a good thing. If one of those experimental things turns out to be useful, other browsers will adopt it. Good examples for that are things like JavaScript, XHR, or text-overflow:ellipsis.
No, not really. They just added `let`, iterators/generators, destructuring assignment, etc in 2006 without asking anyone. Today, you can even use it without opting-in (via: type="application/javascript;version=1.7"). This stuff is supposed to be in ES6 in the future.
Parent said or being put into the standardization process. All those ES6 features are obviously in the standardization process.
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.
The blog post mentions that the notifications API is for use by extensions and Chrome-based desktop apps. That means it's roughly equivalent to Firefox's XUL APIs, which are definitely not standardized.
Chrome apps are like Firefox addons, they have their own non-standard APIs. So complaining that Chrome Apps have their own non-standard APIs is not a valid argument when compared to Firefox.
Every time Firefox introduces a cool new feature, they emphasize how it's standard, or being put into the standardization process, and how every web developer will be able to use it.
Except that's not really up to them is it? A feature that's only ever present in Firefox can't really be called a "standard". I know Mozilla's hearts are in the right place most of the time, but at some level they're trying to improve Firefox in largely the same ways that Google are trying to improve Chrome. The major exception to this would be if Google started imposing a "strategy tax" on Chrome: e.g. a deep inescapable G+ integration or something similarly awful. I can imagine Google doing that, while I can't imagine it of Mozilla.
One big difference is that Mozilla is a non-profit whose stated purpose is to help move the open web forward. And they follow through on that time and again. So much of our open web today would be nowhere near what it is without them.
> So much of our open web today would be nowhere near what it is without them.
You mean like WebRTC, WebM, WebP, Web Components, SPDY, WebSockets, the Chrome UI and process system copied by all, a huge part of the HTML5 api (Ian Hickson), also who's been paying Mozilla bills for the last 10 years? Yeoman? Closure compiler? etc.
There're no other companies or non-profits who have spent as many human and financial resources as Google has on the web platform, we're talking billions of dollars here and thousands of people. I love Mozilla and I know bashing Google is a lot of fun, but you have to give Google credits here. Their dedication to the open web platform is simply unmatched.
WebM and WebP aren't widely used and WebM is patent-encumbered and dead in the water (being unencumbered by patents was its big advantage over the MPAA-backed formats and they lost that). The Chrome process system isn't being copied by all, just the other webkit/chrome folks and is much less efficient with lots of tabs open. The Chrome UI was a basic refinement of the UI progression amongst many browsers including web-pioneer Opera (who never seems to get much credit). In short, none of these are happening in a vacuum and Google generally seems to implement things that benefit their advertising/corporate arm rather than the open web (see: proprietary Chrome 'apps' vs open web apps).
Mozilla and the volunteers around the world that have worked on Netscape since it went open source as well as Netscape before that have far more man-hours into this than Google does.
Google wasn't 'paying Mozilla's bills' out of kindness or dedication to the open web. They were giving them a percentage of the MASSIVE amount of money they made because Mozilla had Google as the default search engine. Same reason other companies pay for inclusion or being the default in other countries. Heck, many argue (rather correctly, I say) that one reason for Chrome was so Google could control more of the web and have to pay Mozilla less money.
I'm not a 'Google-basher' and use many of their cloud products within reason (knowing that they can pull the plug on them or me on a whim and I have zero recourse), but you're giving them too much credit. Mind you, none of this is meant to minimize Google's contributions, but their contributions are more on the search side and the mobile OS side than the 'open' web side in many ways.
> being unencumbered by patents was its big advantage over the MPAA-backed formats and they lost that
They didn't lose that. They just signed an agreement with MPEGLA that anyone can use WebM for free. Firefox implemented WebM support. WebP is already being used by Facebook and many others and saves them millions making the open web faster, it'll be in Firefox soon. You also conveniently forgot WebSockets, Web Components, SPDY and WebRTC (they spent millions on iLBC and others that they just gave away for free to everyone including Mozilla, saving everyone years of R&D) and all the amazing work Ian Hickson has done on the _whole_ HTML5 API. Edit: there's also https://code.google.com/p/angleproject/ without which Firefox wouldn't have WebGL on windows. There is more but you get the idea.
Criticizing Chrome 'apps' for having non-standards API is ridiculous because Firefox does the exact same thing: Firefox addons. They have their own proprietary non-standard API: https://addons.mozilla.org/en-us/developers/docs/reference How evil! What people don't seem to understand is that Chrome Apps are just like Firefox Addons, so it's hypocritical to criticize the former and not the latter. And the Chrome UI did revolutionize the field, every browsers copied it and that's a good thing! Just saying that it was a huge contribution (among tons of others from Google, way more than Mozilla).
Google has been sponsoring Firefox for a long time even when they had an insignificant market share at the time. What you don't understand is that what's good for the web is good for Google. That's why they support even insignificant projects that may help the open web in the future (they even sponsor Open Street Map).
I'm not giving Google too much credit, they have literally spent more resources than Mozilla on the open web whether you like it or not. Are you seriously saying that Mozilla has a bigger budget than Google when it comes to the Open Web? If you think about it, Mozilla itself is part of Google's budget for the Open Web. They have also spent more than any other company be it Apple, or Microsoft or any other really. Just educate yourself on the topic.
They lost it. WebM is officially patent-encumbered. So, license or no, it's non-Free. Making it no better than MPEG now that MPEG is basically under the same license. Plus, unlike WebM, MPEG has widespread hardware acceleration on mobile devices, making WebM basically DOA. I was a fan of WebM and thought it could supplant MPEG on mobile. Mozilla did, too, which is why they took the stance of supporting WebM but not MPEG. Google, however, supported MPEG for commercial reasons, so WebM never had a chance.
WebP isn't used by Firefox yet and won't be used by IE or Safari anytime soon, making it useless for most sites. It's handy for some mobile apps. I know Facebook uses it in their mobile apps. But it's pretty useless on the open web due to lack of widespread support.
I will give you SPDY's small latency improvements, of course. As well as WebSockets now that it isn't horrendously broken and insecure anymore. WebRTC is quite cool and will hopefully achieve wider support.
Chrome's apps are definitively not the same as Firefox extensions. Chrome's extensions are the same as Firefox's extensions. Chrome's apps are a proprietary grab at the desktop and keeping people locked into Chrome instead of being able to use open web apps in a browser of their choice. This is by design and not exactly a secret.
Chrome's UI was simply evolutionary, not revolutionary and is the direction things were already headed in. Take a look at Opera 9.5 released the year before Chrome existed. Tabs up top. Forward/back to the left of the URL bar. Chrome evolved having the menu bar hidden by default and simplifying the visual controls a bit. But it didn't completely change what was already occurring in other browsers. Firefox took more note of Chrome than Opera because Chrome started stealing market share.
Mozilla/Netscape has put more man-hours into the open web than Google. Google doesn't 'sponsor' Mozilla. Google pays Mozilla for a service that nets Google far more money than they give Mozilla. It isn't just about money thrown at things, it's about actual hours and results. The majority of Mozilla's man-hours being unpaid doesn't mean they don't count, despite your insistence on only measuring dollars.
And, as for the open web, Mozilla is the only one fighting for it on mobile via Firefox OS, which will use open web apps with additional open source connectors into local functionality (storage, camera, etc). This is an attempt to fight against the closed ecosystem of Apple and the partially closed ecosystem of Android's app store. You'll be able to 'install' web apps from any website without the need of an app store and without needing to side-load onto your phone.
Chrome's apps are a proprietary grab at the desktop and keeping people locked into Chrome instead of being able to use open web apps in a browser of their choice. This is by design and not exactly a secret.
This is overstating the case. A "packaged app" is just a web app stored locally, with some additional APIs available. There's nothing to stop any other browser from treating the app in the obvious way, leveraging the html5-standard "manifest". Indeed this is the same way that Chrome OS and the Firefox OS of which you've spoken highly handle installed apps. If you're concerned about the expanded API, keep in mind that useful APIs are often ported from one browser to another: this is why we have XmlHttpRequest.
Most Firefox contributors are paid employees thanks to Google's money. It doesn't happen for free. Of course dollars matter. Plus, Chromium is open source too and Chrome gets unpaid contributions too.
> And, as for the open web, Mozilla is the only one fighting for it on mobile via Firefox OS
So is Google. Who was the first huge company to release a 100% web centered OS? Google Chrome OS. They also ported Chrome to Android but right now, the web is just too slow compared to native (and it's going to last http://sealedabstract.com/rants/why-mobile-web-apps-are-slow...) so it doesn't stand a chance. Look at how ridiculously slow FirefoxOS apps are. Google is realistic enough not to do the same mistake but still, they ported Chrome to Android and it supports all the things that FirefoxOS does plus AOSP is open source so it shows that Google actually care about openness even when the web is not a good fit. Oh, and any idea what FirefoxOS uses as a base? Yep, Google's Android.
WebP is huge in apps but not on the open web due to lack of support. It saves Facebook a lot of bandwidth in their native app, though. WebM could have been swapped out for MPEG in WebRTC. It would actually be better due to hardware support.
Chrome apps are still web apps packaged for a single browser in a proprietary app store. It's not the open web.
You do realize there are a ton of Firefox contributors that don't work for Mozilla, right? And, for the third time, Google is paying Mozilla for a service that Google makes a TON of money on. It's not charity as you seem to keep implying. Without Mozilla, Google wouldn't be where it is today. And vice versa. But you seem to only harp on the latter.
You mean the other techs I already acknowledged but you continue to harp on?
On speed, Firefox OS isn't bad for a 1.0 on middling hardware. It'll get faster (remember, Android was a DOG in its initial released on the TMobile G1, which I still have sitting on my desk). And ASM.js will make things interesting, too (and is far more open than Google's native code in the browser attempt). And the article you mentioned is talking about mobile Safari mostly which, don't forget, is completely gimped for packaged web apps on iOS due to Apple's anti-competitive 'you can't use the faster Javascript engine' stance for everything except Safari.
Google Chrome OS is a web-centered OS but it's not an open web OS like Firefox OS is. It supports Chrome apps but it don't think they have any plans to support other ones. It's also funny that you mention Chrome OS and that the web is too slow in the next sentence.
Firefox OS uses the Android internals as a base, which is in turn built on top of Linux. I'm aware of all of that as I've tested it. And I have an Android phone. I think I'm missing your point here as it's unrelated to what we're discussing.
In the end, I have a lot of respect for Google and the contributions they've made. I think they can be a force for good when they want to. And, honestly, I'd love the chance to work at a company like that. But let's keep a balanced eye on their motivations and contributions compared to Mozilla. You make it sound like Google has done everything and Mozilla nothing. I get that you're a Google fan. I am, too. But I'm also a fan of Mozilla and their commitment to openness and a level playing field for everybody.
The difference between Google and Microsoft is their business model. Microsoft sells software, and so it's in their interest to lock users into Internet Explorer, and by extension Windows. Google sells advertisements. They don't actually care which browser you use, as long as you're using a Google service. There's no incentive (yet) for them to lock users into Chrome.
FWIW Google pays Mozilla a lot of money to keep Google the default search engine on Firefox. They probably aren't too concerned if everyone switched to Firefox.
But mostly they also assist in making the technology standardized, so that other players can use it as well.
As they call it - pushing the web forward.
That's a crap argument, because MS always purposefully left the status of the IP up in the air, while Google tries to standardize, and releases open source code.
How about on performance? Differentiating on a standard is not really following standard. That is to say, I'm not against it doing something crazy, like a replacement language for JS. Extraordinary efforts should bring equally extraordinary results.
I doubt these matter much to people outside the tech world. Everybody more or less now knows that Chrome is crazy fast. Also, I'm pretty sure the day Google decided to launch an entire OS based on this browser, everybody should have assumed that they wouldn't be that dogmatic about standards anymore.
That's conflating problems. Google doesn't need to add non-standard API to Chrome Browser so that Chrome OS can use non-standard API. They probably have branches.
One more thing that is coming (back) with Chrome 28 is packaged apps - stand-alone browser-based applications with access to file/network APIs (think Mozilla Prism/Fluid.app). I'm surprised they didn't mention it.
If you use Chrome 28 then packaged apps are still not listed or searchable on Chrome Web Store. I don't think there were many changes since Chrome 27 in this field (especially on Linux).
Legitimately excited to see Blink-based Chrome released. However, Chrome 28 still does not support un-prefixed CSS transitions, transforms, and animations. What gives?? http://www.chromium.org/blink#vendor-prefixes
Given that the standard is well-locked down on those bits of CSS3, why not support the un-prefixed version? I'm not saying you have to stop supporting the prefixed version - I know that would cause all manner of compat issues.
As the site has currently some problems, I can't read the article.
When is Chrome 28 arriving? I'm using Firefox and Chrome on my Mac. And today I've updated Flash for all browsers, except Chrome. The Flash plugin in Chrome is old now and needs an update. But no new Chrome there. :-(
Flash will bring Chrome down. They even have their own Flash bugs they don't fix as fast as Adobe(!).
The update is rolling out gradually. If you would like to make sure you're on the latest version, you can select "About Google Chrome" from the "Chrome" menu on Mac. That will take you to a page that shows you which version you're running and checks for updates.
As the release blog mentions, the Flash update is rolling out via the component updater, which updates Flash independently of the rest of Chrome.
I just tested this on my laptop (which I keep on the stable channel). For some reason, I needed to reload the page to trigger the update check.
After the update to Chrome 28, I still had Flash 11.7. The blog post says that Flash 11.8.800.97 (the latest version) is rolling out via the component updater. I don't think there's any UI to trigger a component update, but it should happen naturally by itself.
Can't help but notice that the --disable-new-menu-style switch no longer works, which is terrible news if you hate Superfluous Google Whitespace as much as I do.
Chrome? Not so much. And it isn't just that this news article left something out — the official Chrome blog[1] never hints that this feature will ever work on anything but Chrome.
To me it's uncomfortable how much Google's tactics with Chrome resemble Microsoft's "embrace and extend" from the late 90s. 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.
[1] http://chrome.blogspot.com/2013/05/richer-notifications-comi...