Chrome 28 arrives with Blink, rich notifications for apps

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

by emilepetrone • 13 years ago

93 116 13 years ago

thenextweb.com

qoo• 13 years ago

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

graue• 13 years ago

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

shadowfox• 13 years ago

I must say that it bothers me mildly too, having been through the latter half of the MS embrace-and-extend era as a professional.

On the other hand, the perception on HN seem to tend towards Google being immune to such power plays. Maybe they are right; I dont know.

yen2232• 13 years ago

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.

paulirish2• 13 years ago

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.

[1] https://groups.google.com/a/chromium.org/forum/#!topicsearch... or spreadsheeted here http://goo.gl/loaQ5

coldtea6• 13 years ago

Thanks for the rundown.

Checking the chromestatus page, I have another question: why so little movement in relation to the new Javascript features?

RyanZAG• 13 years ago

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.

riquito• 13 years ago

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

iamkhush• 13 years ago

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.

jessaustin2• 13 years ago

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.

JohnTHaller4• 13 years ago

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.

nwh• 13 years ago

The raw notifications themselves are already in the latest Safari, though you're right, the "rich" ones will never ever be.

jrockway9• 13 years ago

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.

jfoutz• 13 years ago

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.

coldtea6• 13 years ago

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.

Not to mention that in Android, Chrome IS the IE.

jmillikin• 13 years ago

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.

Skalman• 13 years ago

And since XUL is not standardized, Mozilla has removed support for that in webpages.

Try going to http://www.hevanet.com/acorbin/xul/top.xul in Firefox: "This page uses an unsupported technology that is no longer available by default in Firefox"

est• 13 years ago

It's hard to imagine someone only embrace something without extending it.

gkop• 13 years ago

You're missing the context: https://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish

dannyr• 13 years ago

Would you rather have Google not build anything that is not based on standards?

jrockway9• 13 years ago

I think the average HN reader would rather have Google go out of business. I'm not sure why, but that's what they want.

ahoge3• 13 years ago

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.

Firefox also supports "jar:" URLs for some reason. Here is a demo: http://kaioa.com/b/0907/jartest.html

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.

icebraining• 13 years ago

Parent said or being put into the standardization process. All those ES6 features are obviously in the standardization process.

nnethercote• 13 years ago

2006 was seven years ago; circumstances were different.

Nowadays, at least for the JS stuff, we're much more circumspect about adding features, and really only do it for ES.next kind of stuff.

rogerchucker2• 13 years ago

How else would you like Google to differentiate Chrome in the eyes of a non-techie person?

Ygg23• 13 years ago

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.

workbench2• 13 years ago

To me it's uncomfortable how much Google's tactics with Chrome resemble Microsoft's "embrace and extend" from the late 90s

They're no better than 90s MS at this point, look at what Reader did to the RSS market.

VikingCoder• 13 years ago

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.

mkr-hn• 13 years ago

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

millerm• 13 years ago

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

egwor• 13 years ago

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

_pmf_• 13 years ago

The next engine will probably be called Marquee. It should.

ricardobeat• 13 years ago

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• 13 years ago

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

dragonwriter• 13 years ago

I think the really big changes to packaged apps are in Chrome 29, the current dev channel build.

tibbon• 13 years ago

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

cupcake-unicorn• 13 years ago

Haha, that was my first thought too. Some kind of retro revival!

joejohnson• 13 years ago

$34,901.1 is nothing to Google.

potch2• 13 years ago

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

abarth3• 13 years ago

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

https://groups.google.com/a/chromium.org/forum/#!searchin/bl...

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.

potch2• 13 years ago

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.

stesch3• 13 years ago

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

abarth3• 13 years ago

Chrome 28 is available now on the stable channel:

http://googlechromereleases.blogspot.com/2013/07/stable-chan...

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.

stesch3• 13 years ago

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/

andyhmltn• 13 years ago

Do you have any idea when the Ubuntu/Linux version will be coming?

EDIT: Woops, I just checked and I'm already on 28! Awesome :-)

jbrooksuk2• 13 years ago

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

lucian1900• 13 years ago

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

jbrooksuk2• 13 years ago

I don't know why this has been down voted. It's what I'm experiencing, I'd record it if I had a screen recorder on my work PC.

nnnnni• 13 years ago

… at least it isn't <blink> ?

neckro23• 13 years ago

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• 13 years ago

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

Chrome 28 arrives with Blink, rich notifications for apps

Related Stories