>If you run an app like gmail for example, you can store most everything in cache, >and local storage (browser), including logos, button graphics etc. Resulting

>If you run an app like gmail for example, you can store most everything in cache, >and local storage (browser), including logos, button graphics etc. Resulting to >an app that loads almost instantly most of the time as it's coming from disk >(relatively speaking, many would argue that disk access is extremely slow). Does this extend to other thick client apps like SAP or even ftp just for thinking's sake? >This information stored should obviously not be time sensitive. But if you're >running a client for social networks or such, it's perfectly a good idea to cache >the last 10 posts seen for example, so that when the user loads the page, he >instantly has something to look at while the browser is fetching the fresh >content. Correct but now this is why I say an API because each app can have its own way of caching the last few items (http objects, files, posts whatever might be tagged) >One key consideration is security: do not cache things on the browser that may be >private or sensitive information, unless encrypted, but even then the argument >could be made to not do it at all. That said, storing your application graphics >and most of the UI bits in local storage can certainly improve the user >experience greatly. Is it because of the browser? Say I remove it out of the browser and place it somewhere else, encrypt it store it and wont display until I verify the end user with SSO etc, would that take away this concerns. Depends on the user(most UI bits I agree need be cached and harmless either way) for what bits might be cacheable