4 ms·

Totally agree! Ever tried the new Twitter? You now have to wait 12 seconds to see the Tweets. Why not load the page in 1 sec. without the use of Javascript an

by tintin 15y ago

Totally agree! Ever tried the new Twitter? You now have to wait 12 seconds to see the Tweets. Why not load the page in 1 sec. without the use of Javascript and use Javascript for realtime updates? Because it's cool to use Javascript and make your page slow as hell? Whats wrong with page-reload-apps that are lightning fast? Maybe the hip Javascript developers don't realize a Javascript driven page needs at least 3 request (page + javascript + content) instead of 1 (page)?

Roboprog 15y ago
Some potential mitigating factors, if you break it up as follows: * a tiny anchor HTML page with data key info * a general purpose .js file (or small number of such) * template HTML pages * content (e.g. - JSON) The tiny "anchor" page should be small (latency still hurts, of course); The JS should be cached locally once the app has been used for the day; The HTML templates pages should also cache; The content must be loaded, suffering latency -- however, if the content is large, your app can display something while the content is being generated (perhaps by a big, slow, legacy data source???). Another consideration: if all content is delivered via a REST API as JSON or (ugh) XML, there is a better chance it will be properly encoded for display. Hopefully, I can save a nice JavaScript fragment in a submission to said site, and the AJAX page construction code will simply add it to the resulting page to be displayed, rather than to be run. Hmmmm, perhaps I want my testing fixtures to fill the test database with XSS samples while I am at it, such as the newer entries in http://ha.ckers.org/xss.html http://ha.ckers.org/xss.html (or a more recent list), and then to display that data on a few pages of manual testing.
brunoc 15y ago
There are ways around that. One of the easy ways is to simply in-line your JSON model when you generate the initial page. So essentially your webpage contains the html structure you need, followed by something like <script> Myapp.start( { tasks: [ { id: 1, title: 'do something' } ]) </script> So essentially you bootstrap your application in order to avoid a large AJAX call right off the bat.
- prateekdayal 15y ago
  In fact Backbone's documentation on fetch (the method for populating collections using an AJAX call) specifically recommends this pattern - http://documentcloud.github.com/backbone/#Collection-fetch http://documentcloud.github.com/backbone/#Collection-fetch
- radicalbyte 15y ago
  I did almost exactly that on my last project. Works a treat. With html5 features (i.e. local storage) you can just cache data client-side and sync in the background. I.e. build a disconnected client-server application.

by tintin 15y ago

Roboprog 15y ago

Some potential mitigating factors, if you break it up as follows: * a tiny anchor HTML page with data key info * a general purpose .js file (or small number of such) * template HTML pages * content (e.g. - JSON) The tiny "anchor" page should be small (latency still hurts, of course); The JS should be cached locally once the app has been used for the day; The HTML templates pages should also cache; The content must be loaded, suffering latency -- however, if the content is large, your app can display something while the content is being generated (perhaps by a big, slow, legacy data source???). Another consideration: if all content is delivered via a REST API as JSON or (ugh) XML, there is a better chance it will be properly encoded for display. Hopefully, I can save a nice JavaScript fragment in a submission to said site, and the AJAX page construction code will simply add it to the resulting page to be displayed, rather than to be run. Hmmmm, perhaps I want my testing fixtures to fill the test database with XSS samples while I am at it, such as the newer entries in http://ha.ckers.org/xss.html http://ha.ckers.org/xss.html (or a more recent list), and then to display that data on a few pages of manual testing.

brunoc 15y ago

There are ways around that. One of the easy ways is to simply in-line your JSON model when you generate the initial page. So essentially your webpage contains the html structure you need, followed by something like <script> Myapp.start( { tasks: [ { id: 1, title: 'do something' } ]) </script> So essentially you bootstrap your application in order to avoid a large AJAX call right off the bat.

prateekdayal 15y ago
In fact Backbone's documentation on fetch (the method for populating collections using an AJAX call) specifically recommends this pattern - http://documentcloud.github.com/backbone/#Collection-fetch http://documentcloud.github.com/backbone/#Collection-fetch
radicalbyte 15y ago
I did almost exactly that on my last project. Works a treat. With html5 features (i.e. local storage) you can just cache data client-side and sync in the background. I.e. build a disconnected client-server application.