5 ms·

The new breed of chrome apps has a lot of flaws after I tried to convert my app over: -Previous installed chrome app matches the HTML5 api, the new chrome apps

The new breed of chrome apps has a lot of flaws after I tried to convert my app over: -Previous installed chrome app matches the HTML5 api, the new chrome apps has a lot of restriction where you have to totally rewrite you code in terms of storage. i.e. Chrome.storage instead of localStorage; All chrome storage is async. -The new window format for apps are a huge UI flaw. You can not open an Chrome app in a tab anymore. Basically, you now have an extra window whenever you open a chrome app. This is very annoying since when you click on the existing window the app is hidden in the back, you have to flip through your windows on the mac to find the app you just opened again. -Javascript execution permissions are very strict, and no longer follows that of a normal webpage. The result is, you can no longer build an HTML5 app and prepare it for the chrome store, you have to specifically change the code to package it. This makes it less ubiquitous and creates extra work for developers.

teleclimber 13y ago
I remember from a talk at IO13 that the point of the new Chrome Apps is that they truly behave and feel like what we think of as "native" apps. Therefore, no Chrome tabs or other browser-like stuff. I'd have to look at the talk again but if I remember right they limit how and when JS can be used in order to let you safely do things you can't do in a standard webpage. This session explains it all: https://developers.google.com/events/io/sessions/326973874 https://developers.google.com/events/io/sessions/326973874
deleted 13y ago
[deleted]
georgemcbay 13y ago
Even the older breed of chrome apps had annoying flaws, IMO, when I was playing around with their APIs to get a feel for them about 6 months ago. I was mostly surprised how it felt that in many ways you were actually more restricted than you were with just a normal web app. Also the documentation was trash and confusing in a lot of ways because even prior to these changes they had made a lot of other changes via deprecating APIs and their documentation was poorly managed to the point where it was really difficult to determine which APIs were deprecated or not without trying to use them in the latest Chrome and having them fail on you. Also, there wasn't a clear roadmap as to what APIs you could expect to be pretty stable and what ones they might suddenly deprecate, breaking your app. Hearing that the "new breed" has some of these same flaws and some new ones makes me very disinclined to bother checking in with the current technology.
daleharvey 13y ago
> -Previous installed chrome app matches the HTML5 api, the new chrome apps has a lot of restriction where you have to totally rewrite you code in terms of storage. i.e. Chrome.storage instead of localStorage; All chrome storage is async. I belive this is only localStorage right? (indexedDB is still available afaik) Firefox OS had mentions of disabling localStorage, its been a huge problem due to its synchronous API, I dont think it did end up being disabled though, I would really like to see localStorage being (slowly) deprecated and an async api (possibly even just a helper for idb) being promoted as an alternative full web standard as opposed to chrome specific API's coming in here
- justincormack 13y ago
  Synchronous local storage on a phone would be a real problem due to lags, on desktop it might be OK...
  - lucian1900 13y ago
    It's terrible on a desktop as well, even with an SSD. It fsyncs, which blocks the entire page.
- tyre 13y ago
  indexedDB is available with an entirely async API. Bring on the callbacks!
  - daleharvey 13y ago
    Yup, we have a shared helper in Firefox OS on top of IndexedDB that all the apps use (localStorage is as close to banned as it can be) (https://github.com/mozilla-b2g/gaia/blob/master/shared/js/async_storage.js https://github.com/mozilla-b2g/gaia/blob/master/shared/js/as...) However thats fine when you are building your own apps, but I meant as a long term solution to the web platform, if localStorage needs disabled on one platform in favour of a propietary API, maybe its best to replace it with a non proprietary web api
josteink 13y ago
The result is, you can no longer build an HTML5 app and prepare it for the chrome store, you have to specifically change the code to package it. This makes it less ubiquitous and creates extra work for developers. So a proprietary HTML-based format then? Yay Google for promoting the open web!</s> With Google going down south, we need Firefox OS to get traction, and we need it now.

teleclimber 13y ago

I remember from a talk at IO13 that the point of the new Chrome Apps is that they truly behave and feel like what we think of as "native" apps. Therefore, no Chrome tabs or other browser-like stuff. I'd have to look at the talk again but if I remember right they limit how and when JS can be used in order to let you safely do things you can't do in a standard webpage. This session explains it all: https://developers.google.com/events/io/sessions/326973874 https://developers.google.com/events/io/sessions/326973874

deleted 13y ago

[deleted]

georgemcbay 13y ago

Even the older breed of chrome apps had annoying flaws, IMO, when I was playing around with their APIs to get a feel for them about 6 months ago. I was mostly surprised how it felt that in many ways you were actually more restricted than you were with just a normal web app. Also the documentation was trash and confusing in a lot of ways because even prior to these changes they had made a lot of other changes via deprecating APIs and their documentation was poorly managed to the point where it was really difficult to determine which APIs were deprecated or not without trying to use them in the latest Chrome and having them fail on you. Also, there wasn't a clear roadmap as to what APIs you could expect to be pretty stable and what ones they might suddenly deprecate, breaking your app. Hearing that the "new breed" has some of these same flaws and some new ones makes me very disinclined to bother checking in with the current technology.

daleharvey 13y ago

> -Previous installed chrome app matches the HTML5 api, the new chrome apps has a lot of restriction where you have to totally rewrite you code in terms of storage. i.e. Chrome.storage instead of localStorage; All chrome storage is async. I belive this is only localStorage right? (indexedDB is still available afaik) Firefox OS had mentions of disabling localStorage, its been a huge problem due to its synchronous API, I dont think it did end up being disabled though, I would really like to see localStorage being (slowly) deprecated and an async api (possibly even just a helper for idb) being promoted as an alternative full web standard as opposed to chrome specific API's coming in here

justincormack 13y ago
Synchronous local storage on a phone would be a real problem due to lags, on desktop it might be OK...
- lucian1900 13y ago
  It's terrible on a desktop as well, even with an SSD. It fsyncs, which blocks the entire page.
tyre 13y ago
indexedDB is available with an entirely async API. Bring on the callbacks!
- daleharvey 13y ago
  Yup, we have a shared helper in Firefox OS on top of IndexedDB that all the apps use (localStorage is as close to banned as it can be) (https://github.com/mozilla-b2g/gaia/blob/master/shared/js/async_storage.js https://github.com/mozilla-b2g/gaia/blob/master/shared/js/as...) However thats fine when you are building your own apps, but I meant as a long term solution to the web platform, if localStorage needs disabled on one platform in favour of a propietary API, maybe its best to replace it with a non proprietary web api

josteink 13y ago

The result is, you can no longer build an HTML5 app and prepare it for the chrome store, you have to specifically change the code to package it. This makes it less ubiquitous and creates extra work for developers. So a proprietary HTML-based format then? Yay Google for promoting the open web!</s> With Google going down south, we need Firefox OS to get traction, and we need it now.