

Chrome 28 arrives with Blink, rich notifications for apps - emilepetrone
http://thenextweb.com/google/2013/07/09/chrome-28-arrives-with-rich-notifications-for-apps-and-extensions-on-windows-mac-and-linux-coming-soon/

======
graue
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.

[1] [http://chrome.blogspot.com/2013/05/richer-notifications-
comi...](http://chrome.blogspot.com/2013/05/richer-notifications-coming-to-
chrome.html)

~~~
paulirish
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...](http://blog.chromium.org/2013/05/chrome-28-beta-more-immersive-
web.html) 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](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.

[1]
[https://groups.google.com/a/chromium.org/forum/#!topicsearch...](https://groups.google.com/a/chromium.org/forum/#!topicsearchin/blink-
dev/subject$3Aintent) or spreadsheeted here
[http://goo.gl/loaQ5](http://goo.gl/loaQ5)

~~~
RyanZAG
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.

~~~
lmm
>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).

Doesn't the same logic apply to Mozilla's asm.js?

~~~
pcwalton
asm.js was implemented very quickly, in about a month, and V8 is already
implementing optimizations for it (though without "use asm").

~~~
kingkilr
It's not an optimization for asm.js if you ignore the "use asm". It's just
javascript then.

~~~
Ygg2
Which is what asm.js is mostly. Subset of javascript.

~~~
justinschuh
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.

~~~
pcwalton
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.

~~~
justinschuh
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?

~~~
dherman
> 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.

~~~
justinschuh
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?

~~~
dherman
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.

~~~
justinschuh
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.

------
tibbon
I seriously thought that Chrome was re-implementing the <blink> tag from the
headline.

~~~
cupcake-unicorn
Haha, that was my first thought too. Some kind of retro revival!

------
ricardobeat
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.

~~~
jarek-foksa
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).

------
potch
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](http://www.chromium.org/blink#vendor-prefixes)

~~~
abarth
We're working through the prefixed features we inherited from WebKit:

[https://groups.google.com/a/chromium.org/forum/#!searchin/bl...](https://groups.google.com/a/chromium.org/forum/#!searchin/blink-
dev/unprefix)

Our approach is (1) to avoid adding new prefixed APIs and (2) to unprefix APIs
when we're confident we're not going to cause compatibility problems.

~~~
potch
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.

------
stesch
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(!).

~~~
abarth
Chrome 28 is available now on the stable channel:

[http://googlechromereleases.blogspot.com/2013/07/stable-
chan...](http://googlechromereleases.blogspot.com/2013/07/stable-channel-
update.html)

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.

~~~
stesch
I know about "About Google Chrome". It's still version 27. And it's still an
old version of Flash.

Here are the current versions of Flash:
[http://www.adobe.com/software/flash/about/](http://www.adobe.com/software/flash/about/)

~~~
abarth
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.

~~~
stesch
Found it! Not the updater, but how I can use the more recent version.

In chrome://plugins/ (+ "Details") I can choose between Chrome's Flash and the
"normal" Flash.

------
neckro23
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.

~~~
john_b
I've been considering switching back to Firefox lately and this may be enough
to push me over the edge.

------
nnnnni
… at least it isn't <blink> ?

------
jbrooksuk
Blink seems to be slower at rendering stuff than the original engine for me. I
see the transparency effect when scrolling very quickly.

~~~
lucian1900
It _is_ the same engine, just renamed. Chromium has been using a fork of
WebKit for quite a while now.

------
joejohnson
$34,901.1 is nothing to Google.

------
mkr-hn
Am I the only one who assumed <blink> was making a comeback when they read the
title?

~~~
millerm
For only 1 second, then I remembered reading about the Blink project.

~~~
egwor
For a second I misread it as Bling and thought that was Microsoft's search
engine.... lol. [I just woke up]

------
qoo
Dear Google, Please integrate Mr. Jingles to Chrome. KTHXBAI.

