4 ms·

I've been building 100% JS apps for 4 years now. With proper fragment loading, rendering optimization, and CDN usage, the apps appear to load just fast as an as

I've been building 100% JS apps for 4 years now. With proper fragment loading, rendering optimization, and CDN usage, the apps appear to load just fast as an asp/php/jsp page (i.e. 200ms). Once the base page is loaded, page loads are instant (i.e. 10ms) smoking a non JS web app. Blogger is sadly a dog and has been for the longest time. Profiling it just now, some of the blocking JS dependencies take > 800ms to load. Frankly there are many things wrong with it, but it should not serve as an example of a well designed JS web app.

repsilat 13y ago
On slow connections I can sometimes only get the base html to load. No images, no external CSS or js. Extra requests for content are just asking for trouble. Worse, when I'm halfway around the world my ping is atrocious. It doesn't matter how quickly you generate your content for me, it's going to take twice as long for me to get it if you don't send it the first time I ask for it. If I click on a link on your page and you have a faster way to get me there than a full page refresh then great, let's do that. On the first page load, though, there is no good excuse to make me request the site template and the content sequentially and smoosh them together myself. Do that on your end.
- twistedpair 13y ago
  In that case, you'd likely prefer a JS based app that used its app manifest to cache the actual moving parts (JS/images) before you headed on vacation and landed on that slow connection. Now it only makes a bare minimum of compressed RPC's to provide the page with the content to render itself. Depending on the content being rendered, you could even get an RPC down to one or two packets, much better than sending you the entire site frame over and over for a minor change (I'm looking at you classic postback driven ASP app).
  - masklinn 13y ago
    > In that case, you'd likely prefer a JS based app that used its app manifest Speaking as somebody who's been in that case, no. 1. The app manifest doesn't need "JS-based apps", they're indepedendents 2. Assets caching doesn't need the app manifest either 3. Stop breaking stuff which works. HTML works, your shitty application does not.
sergiosgc 13y ago
I hope the 10ms quote is for a localhost connection, otherwise I'll read it like I do huge fish weight on my father's last fishing trip.
- rgbrgb 13y ago
  No, the 10ms is because you don't have to hit the server on every page load.
  - FedRegister 13y ago
    But presumably you'd need to hit the server for new content. The RTT on that alone would take more than 10 ms.
- twistedpair 13y ago
  Since you can have a local cache of objects of interest to the user, many subsequent user interactions don't require an RPC. For example, you loaded this month in the calendar, but once loaded did an extra RPC to fetch month N-1 and N+1's content. Now when the user visits month N+1, you can just render the calendar with that content without any requests or apparent delay to the user. Further, if the user clicked on a calendar day, you could show the day details with no additional RPC. I quote 10ms as client side code to produce the new HTML and browser painting events can take time, but if you used a canvas or similar you could cut down even further on that render time.

repsilat 13y ago

On slow connections I can sometimes only get the base html to load. No images, no external CSS or js. Extra requests for content are just asking for trouble. Worse, when I'm halfway around the world my ping is atrocious. It doesn't matter how quickly you generate your content for me, it's going to take twice as long for me to get it if you don't send it the first time I ask for it. If I click on a link on your page and you have a faster way to get me there than a full page refresh then great, let's do that. On the first page load, though, there is no good excuse to make me request the site template and the content sequentially and smoosh them together myself. Do that on your end.

twistedpair 13y ago
In that case, you'd likely prefer a JS based app that used its app manifest to cache the actual moving parts (JS/images) before you headed on vacation and landed on that slow connection. Now it only makes a bare minimum of compressed RPC's to provide the page with the content to render itself. Depending on the content being rendered, you could even get an RPC down to one or two packets, much better than sending you the entire site frame over and over for a minor change (I'm looking at you classic postback driven ASP app).
- masklinn 13y ago
  > In that case, you'd likely prefer a JS based app that used its app manifest Speaking as somebody who's been in that case, no. 1. The app manifest doesn't need "JS-based apps", they're indepedendents 2. Assets caching doesn't need the app manifest either 3. Stop breaking stuff which works. HTML works, your shitty application does not.

sergiosgc 13y ago

I hope the 10ms quote is for a localhost connection, otherwise I'll read it like I do huge fish weight on my father's last fishing trip.

rgbrgb 13y ago
No, the 10ms is because you don't have to hit the server on every page load.
- FedRegister 13y ago
  But presumably you'd need to hit the server for new content. The RTT on that alone would take more than 10 ms.
twistedpair 13y ago
Since you can have a local cache of objects of interest to the user, many subsequent user interactions don't require an RPC. For example, you loaded this month in the calendar, but once loaded did an extra RPC to fetch month N-1 and N+1's content. Now when the user visits month N+1, you can just render the calendar with that content without any requests or apparent delay to the user. Further, if the user clicked on a calendar day, you could show the day details with no additional RPC. I quote 10ms as client side code to produce the new HTML and browser painting events can take time, but if you used a canvas or similar you could cut down even further on that render time.