11–20 of 20 posts
cache https://webcache.googleusercontent.com/search?q=cache:http:/...
btw a worthwhile read http://www.alistapart.com/articles/application-cache-is-a-do...
As others have pointed out, the major problem I face is to inform the users that some features are not available when they are offline (e.g. file uploads). If you're not careful with the user experience, this leads to lots of support headache.
Another problem is dealing with legacy client data. If you are storing anything at all in the local storage, you need to realize that it's going to be always there once you write it. So handling with data migrations on the client storage becomes very important, and definitely must be thought ahead.
So, in other words, the web is rediscovering client/server programming. Welcome to 1990, everyone! More seriously, though, I think a lot of the reason for the historical tendency towards server side rendering has been: * Clients were slow: remember, until V8 raised the standard for speed, Javascript VMs were slow . So doing a lot of rendering or data processing in Javascript was a bad idea, since it negatively affect…
What we are really discovering here is that we can do software that uses the (big) network.
The opportunity is in that, differently from the past, this time we suck less at the UX design.
Earlier quoted context omitted.
It's also a change in mindset in the 'developer community'. Up until let's say 5 years ago, Javascript was considered plain dirty. Javascript was a non-portable hack that was only to be touched in the most extreme circumstances. Websites that didn't work on Lynx were reviled. Oh how things have changed, and yet have stayed the same at that same time (i.e., your 'welcome to 1990' comment). On a related note, the last…
I once read a book about MFC (Microsoft foundation classes) programming in Windows. This book had some web programming chapters, and one of them was DTHML (dynamic HTML) how it was called then. The author even said "Silly HTML" to it (it makes more sense in German, because silly starts with a "d" in German) and said that this is absolutely worthless, cause it will never work in more than one browser. These were the d…
This is because of the adoption of the technology and its evolution. It is not just the technology per se.
If a tree falls in the forest and no one is around to hear it does it make a sound?
People are consuming more content on mobile year on year, and using offline storage and capabilities have been around for the past year or two; how this is only just bubbling at the surface at conferences is beyond me. Take THE white elephant example; Facebook mobile. The shift is evident, my girlfriend doesn't use a traditional desktop/laptop anymore she consumes all her Facebook glutton through her mobile. If it ta…
I'm planning on queuing up updates when offline for my app. On the technical side of things, it's incredibly easy when done from the ground up. In fact I think it's made the entire thing much cleaner and far easier to develop. The harder part seems to be communicating with the user. If/how to let them know they've gone offline, and what that means for their experience, and if they're allowed to create/update content,…
Earlier quoted context omitted.
It's still quite tricky to to detect a reliable 'offline' state with HTML5. Using navigator.onLine tells you that you 'might have' internet access but even then you may actually be offline. Bu I agree that the most important issue is how to communicate the degradation to the end user.
Yeah, I saw a lib the other day that tried to offer this but was pretty hit and miss, and checking into the methods available didn't fill me with confidence. Right now I'm only considering the client offline if an attempt to hit the server fails. If they're trying to save something, queue it up to do later, if they're trying to retrieve something, check if theres a copy locally, if not let them know what's going on.…
So, in other words, the web is rediscovering client/server programming. Welcome to 1990, everyone! More seriously, though, I think a lot of the reason for the historical tendency towards server side rendering has been: * Clients were slow: remember, until V8 raised the standard for speed, Javascript VMs were slow . So doing a lot of rendering or data processing in Javascript was a bad idea, since it negatively affect…
So, in other words, the web is rediscovering client/server programming. Welcome to 1990, everyone! More seriously, though, I think a lot of the reason for the historical tendency towards server side rendering has been: * Clients were slow: remember, until V8 raised the standard for speed, Javascript VMs were slow . So doing a lot of rendering or data processing in Javascript was a bad idea, since it negatively affect…
Actually, it was Apple, not Google, that kicked off the JS performance wars. Apple and Mozilla were deep into JIT tech before anyone knew about the existence of Chrome.