javascript and hardware access

[RickP]

Loading more than 5mb on a phone could take a noticeable while, so it's not something you want to do every page load.

Data reads just need to be asynchronous and read at time of request. The standard can't worry about how people might mess up using the feature (not security but performance). A program on my desktop takes time to load and read data. A web app shouldn't be any different given it has the same functionality as the desktop app. The web world needs to stop worrying about performance so much and just work on functionality first. Don't limit functionality because a fear of performance. Of course work on performance but if I can't do it at all, then it's worthless.

The web world is used to "pages need to load fast". They only need to load fast when they are incredibly simple and "dumb" pages. When the world of actual useful/powerful web apps start coming, people will expect and be OK with load times of a web app.

When the web apps start being more like http://www.youtube.com/watch?v=HCwH9BGgtdQ it's OK to take a little time to load. Users will put up with it because it's so much more powerful than some semi-dynamic web page.

I think this is a mind shift. Powerful web apps need more access to hardware and the standard should be helping with this.

I'm excited to see your work in the storage space to help fill the gap though!

[rnd me]

Originally Posted by RickP

Data reads just need to be asynchronous and read at time of request.

The standard can't worry about how people might mess up using the feature (not security but performance).

well localStorage is sync, so it's not the droids you are looking for.

if a feature is frozen and devs start commonly abusing it, or it has some accumulation flaw, to the detriment of the UX, it's harmful on the balance, and we would have been better off with existent workarounds, which are ample but convoluted.

[RickP]

well localStorage is sync, so it's not the droids you are looking for.

They can create a "new" local storage concept that is async. Leave the old one in place. Or better yet just extend the new one so it's still backwards compatible.

[rnd me]

Originally Posted by RickP

They can create a "new" local storage concept that is async. Leave the old one in place. Or better yet just extend the new one so it's still backwards compatible.

how can one provide backwards compat to code expecting a sync interface to one expecting a callback? you can catch the writes, but there would be no way to load.


i have not had time to make my fully unified script, i've been in the middle of a launch the past week. I was going to squeeze the heck out of the polyfill, add deflate(), a localStorage[]-fallback, and an ajax plugin to allow for unlimited storage using a server backend through the unified interface. those aren't that complicated or lofty of implementation ideals, but i've just not had time. maybe you can polish it up.



here is a unified indexedDB/webSQL package, which was/is to be the core of my tool. it should provide at lease 5 more megs. In FF, i think its 50mb, in chrome it actually varies, and in IE10 i think its 5 megs, but that's unconfirmed.

The websql polyfill provides an indexed DB api to a higher-leven abstractino script i'd found. I tried to code all the low-level stuff myself, but after 4 or 5 hours of banging my head against browser quirks, stale docs, and invisible errors, i gave up.


anyway, it's is tested in IE10, FF, Ch, and Op.

http://danml.com/js/localstorage2.js


the api is one function, overloaded by arguments according to task.

usages:

function dump(e){ console.info(e); }

//load
localStorage2( "lastName", dump );

//save
localStorage2( "lastName", "smith" ); // OR:
localStorage2( "lastName", "smith", dump );

//list
localStorage2( dump );

//delete
localStorage2( "DELETE", "lastName", dump );

i'll still work on it one day, but here's what i got to build on.
right now, it's not a bad way to store in webworker threads, since localStorage is blocked in those...