Shared publicly  - 
 
Fizz is an exciting new effort by the chromium team aimed at making web applications first-class citizens on mobile by giving developers more powerful and safe capabilities to the web platform:

- Service Workers¹ provide a way for applications to reliably "go offline".
- Push API² used by application servers to send messages to web apps, whether or not the app is active in a browser window.
- Network Information API³ to access the underlying connection information of the device.
- Geofencing API⁴ makes it possible to be notified when a device enters or leaves specific regions.

¹ https://github.com/slightlyoff/ServiceWorker/
² https://dvcs.w3.org/hg/push/raw-file/tip/index.html
³ https://plus.google.com/+IlyaGrigorik/posts/QwTUPrcxyJp
https://docs.google.com/document/d/1f0YwJDRvoGko4OaD8gWJdmgLIPTMs_SiOd3rjHyd_Yo

Source: http://crbug.com/352648
167
29
Art Cowles's profile photoQasim Obaidullah's profile photoScott Walsh's profile photoLIU SHR YAN (modeerf)'s profile photo
27 comments
Vu Dinh
+
6
7
6
 
I thought Francois plays League for a moment there.

EDIT: I get it now. The chromium team names the project Fizz, independent of the reference. Francois, possibly also a League player, borrows the picture for... illustrative purposes.
Un Lo
 
Please don't tease. I thought my prayers had been answered and i'd soon need nothing more than my Chromebook to make it through the day including my League Fix. 
 
Now all I want to see in Chrome mobile is the ability for web apps to be placed in the app drawer.
I'm a little surprised Google Now Launcher didn't bring this.
 
+Jerzy Głowacki The fizz effort is very similar to the WebAPI project at Mozilla without the focus on Firefox OS. Why do you see them as opposed?
 
I seriously doubt this is a wholehearted effort on Google's side. We have been burnt too many times with Google (together with Apple) leaving browser in the dust, specifically to NOT LET Web Apps compete with the native Apps. Android default Web browser is a new IE6 disaster. Chrome exists on Android for 3 years and yet this outdated browser is still a default. And do not get me started on Webview. Chromeview has been years in making, and even now it is available only on 4.4+. And do not tell me that Packaged Apps, now renamed Chrome Apps, are about to restore parity with the native apps. We need secure dynamic loading of Web Apps that will allow native level access to device capabilities, not a centralized app store for Web Apps where with each small update in css Web App needs to be submitted for an update in the Play Store. Please bring this article on Hash URIs to the attention of Fizz team: https://clipperz.is/blog/2014/06/12/web-crypto-moving-forward/
 
+Gene Vayngrib "Chromeview has been years in making, and even now it is available only on 4.4+"

When 4.4 was announced several Google employees have been asked about this and have said that something is in the works (might be through Google Play Services).

"We need secure dynamic loading of Web Apps that will allow native level access to device capabilities, not a centralized app store for Web Apps where with each small update in css Web App needs to be submitted for an update in the Play Store"

What you're asking for sounds like Service Workers, which is highlighted above.
 
you are right, I was following service workers for a while and the idea of implementing hash-URIs with it crossed my mind. But even if it is possible, it would be a course change for Google, to shift from chrome store based web apps, to restoring a decentralized model for web apps. This, as you can judge by the bitter tone of my prior comment, I do not have much hope for as, as a money making machine of a Play Store will be a powerful magnet to model the chrome store on.
 
and before you add "go do it yourself", it is not possible - device access privileges are completely controlled by google, opening push and geo-fencing to regular sites working in tabs (and even not active) is very very nice, but dream on about bluetooth and many other apis available only to chrome apps.
 
So you have no hope that something Google is building and supporting will be built and supported by Google, because they're also building and supporting something else.
 
haha, they are conflicted alright, you nailed it! And the result is the loss of the Web to native apps, this is a huge step back for the society and I am ticked off. Halfhearted efforts by Google make it even worse, make us web developers hopeful again, only to drop us on our backs.
 
+Mounir Lamouri I don't see your and Mozilla's effort in opposition, but rather in synergy. That's why I'd like to ask you to implement the majority of WebAPI, including: Alarm API, Camera API, Contacts API, FileHandle API, Web Telephony API, Ambient Light Events, Proximity Events, Web Activities, Mobile Connection.
 
Mozilla is very happy to standardise these APIs with Google and others where it makes sense. Web App Manifest and Service Workers are a great start! Some of those "Web API"s are currently only exposed to packaged apps on Firefox OS (you could call them Firefox Apps) similar to Chrome Apps. In an effort parallel to Google's we are exploring ways to expose more APIs to web apps, through designing new APIs and/or new security models. Mozilla is always open to collaboration on standardising those, in fact that's one of the core goals of the Firefox OS project. I think Mounir already knows this :)
 
+Ben Francis
This effort only cover a fraction of what native platforms offer.  IMNSHO, the whole idea of DUPLICATING the Native level into the Open Web will forever handicap the Web because the work needed is simply put too heavy and in some cases not even possible as we recently saw with W3C WebCrypto.Next.

A better idea is COMBINING these layers which also allows OTHER PARTIES introducing new stuff rather than waiting for years on features that already are used in PRODUCTION with Android and iOS!
 
+Anders Rundgren "the work needed is simply put too heavy" it's not that adding the feature is difficult, it's that making the feature an open standard is difficult.

Browser devs could easily just slap on native app functions in a heartbeat (as browsers are native apps), it's just that everyone wants to do these things in a way that works for every intended use case and won't later be a problem for future APIs.

Also allowing other parties to introduce new stuff is done all of the time (again browsers are native apps). Safari, Chrome, Firefox, Opera, IE and others all support non-standard APIs that aren't in any W3C spec.

"A better idea is COMBINING these layers"
navigator.connect is already in the works https://docs.google.com/document/d/16iX4Tj4i0dL6CRnLYx3ekLQ5h2GVPDWuAClsI9CLg04/
 
+Hugh Isaacs II
"Browser devs could easily just slap on native app functions in a heartbeat"

The only "slap" I have seen was by Google in the face of a large user group:
https://lists.w3.org/Archives/Public/public-web-security/2015Feb/0034.html

That is,  only things that the browser-vendors like may get support.  In the referred case the browser-vendors didn't offer any option since they have unilaterally decided removing plugins but without considering the millions of people using them.  Note I don't want plugins back, but there are other ways linking Web and Native but since "purity" apparently is more important than "utility" nothing happens.

Anyway, this is mainly an issue for Mozilla who have made things much more complicated (for themselves...) by insisting that protected local Web APIs should be standardized.  The competitors do not care a hoot about standardizing Android and iOS and IMO they are right.
 
+Anders Rundgren "That is,  only things that the browser-vendors like may get support."
The browser vendors are arguably the largest contributors to the specifications themselves.
Shoot a Google employee authored the HTML5 spec (go check for yourself).

And remember Microsoft at one point wasn't supporting HTML5 at all.

" they have unilaterally decided removing plugins but without considering the millions of people using them"
Check that link I sent about navigator.connect it should fix this problem if standardized (it'll let web and native apps communicate and it's being authored by Google and Samsung).

And Mozilla's local APIs aren't being standardized because they were rushed in favor of putting out a product quickly. Such as Firefox OS's background sync API, they're already working on replacing it with the Service Workers API (found in Chrome).
 
+Hugh Isaacs II
navigator.connect is great but it does not replace this:
http://www.cnet.com/news/google-paves-over-hole-left-by-chrome-plug-in-ban/
without a total redesign.

Google claims the want to remove native messaging also :-(

Regarding Mozilla's standardization quest was thinking about stuff like NFC, Bluetooth, TCP Sockets, Security Elements etc. which they IMO should deal with in the same way as their non-HTML5/JS buddies.

The speed of Web developments in hot areas like mobile payments is a joke and everybody knows it but nobody even wants to talk about it.   "The emperor is naked" as it is called in a Danish fairy tale.
Add a comment...