3. There's no way for a user to grant unlimited storage permissions without going through a proprietary web store and registering as a user of a third party company.
4. There's no support for first-class binary keys in IndexedDB.
5. LocalStorage is broken.
6. Data api in WebRTC is of lesser priority than video/audio (should be the other way round, in fact providing UDP or TCP directly with appropriate permissions would solve this more elegantly).
Browsers must provide primitive CS APIs. TCP, UDP, and POSIX, all as per the Node.js api, with the user granting permissions.
There has been a tendency for the web specs to optimize towards protecting developers and users from "shooting themselves in the foot". The web specs need to be written from the point of view of enabling the next operating system. They need to give more power to developers and to users. Browsers are hoarding the problem and ruining the solution in the process, by trying to solve something that can only be solved higher up in the stack. Instead they should enable things to be done in the most direct way possible with a minimum of red tape. The web specs have tended to go for simplicity instead of directness. But directness is better than simplicity.
The trend of writing HTML-5 to do list demos needs to give way to writing HTML-5 operating system demos.
Funny I was just talking to a friend this weekend about his new iOS app. I listed like 15 different failure modes his developer didn't think about.
I am old enough to remember my modem disconnecting on me in the middle of sessions and later in the middle of web pages loading over a SLIP link. :)
I know most of the younger crowd will think that us older techs always talk about walking up hill both ways on the road to school and home again.
That said it is funny how many things in tech really are foundational and every generation of technologists seems to have to re-learn them over and over.
I wonder what the next generation will take for granted?
Sometimes having walked up hill both ways is a great way to learn. And then later you learn to take another route.
I often mentor young technologists and enjoy the experience because they can "teach an old dog new tricks" and I can "teach a new dog old tricks". It keeps me current and gives them the advantage of not duplicating my mistakes and coming up with new and creative mistakes to make.
You are freaking right, youngsters waste everything, bandwidth, processor cycles, space... Having someone who's experienced the tough old days would help deliver apps that work with baseline devices.
Both the App Store app and Facebook had hiccups on my iOS devices before - the stylesheet for their webviews failed to load. Looks terrible and unprofessional. This is a problem as soon as you even embed the tiniest remote web view. :(
If the main problem with the mobile browsers is the lack of a reload button, then you could just write a tiny little javascript reload button and have that as the first thing that loads on your page...
This is not a browser-land problem, it's a developer-land problem. Developers simply need to start writing HTML5 apps as distributed applications.
And this is where browsers need to assist developers:
1. websocket performance in Chrome is poor (http://code.google.com/p/chromium/issues/detail?id=123228)
2. IndexedDB is at least an order of magnitude slower than LevelDB, and read transactions block read transactions (!) (http://code.google.com/p/chromium/issues/detail?id=128865)
3. There's no way for a user to grant unlimited storage permissions without going through a proprietary web store and registering as a user of a third party company.
4. There's no support for first-class binary keys in IndexedDB.
5. LocalStorage is broken.
6. Data api in WebRTC is of lesser priority than video/audio (should be the other way round, in fact providing UDP or TCP directly with appropriate permissions would solve this more elegantly).
Browsers must provide primitive CS APIs. TCP, UDP, and POSIX, all as per the Node.js api, with the user granting permissions.
There has been a tendency for the web specs to optimize towards protecting developers and users from "shooting themselves in the foot". The web specs need to be written from the point of view of enabling the next operating system. They need to give more power to developers and to users. Browsers are hoarding the problem and ruining the solution in the process, by trying to solve something that can only be solved higher up in the stack. Instead they should enable things to be done in the most direct way possible with a minimum of red tape. The web specs have tended to go for simplicity instead of directness. But directness is better than simplicity.
The trend of writing HTML-5 to do list demos needs to give way to writing HTML-5 operating system demos.