|
|
|
|
|
|
by sourcefrog
5233 days ago
|
|
|
> Ability to link to documents, bookmark, meaningfully use history and save pages to the disk for offline use. Ability of the users to customize standard behaviors without reverse-engineering your JavaScript code. Transparency, which often leads to much, much easier debugging and improved usability. No need to run a quad-core 4GB desktop to use the website. You can manipulate the page url/browser history from js, and you can use the url to set the application state. History and bookmarks work perfectly well in gmail, for example. This does take explicit coding. But, if fragments of the page are being replaced as bcx does, then you need to do similar coding anyhow. Otherwise, you're doing whole page loads on every request. js works pretty well on modest smartphones, at which level network latency is usually the major concern... |
|
|
It should not be similar. There is a huge architectural difference between the two approaches. In server-side approach you're adding caching or prefetch to an already working application that has established and working URLs. With client-side approach, you need to implement adapters that transform URL information into the client state that is normally achieved by a series of UI operations and AJAX calls. Then you need to add new code to generate URLs and manipulate history.
The beauty of caching or partial page fetches is that they are generic. History manipulation is not.
js works pretty well on modest smartphones, at which level network latency is usually the major concern...
The last time I tried to browse on Kindle, it choked and died on most JS heavy websites. When 500MHz processor is not fast enough to browse the web, to me, that's a problem.