5 ms·

Exactly; those of us "vituperating priests" who rail against JavaScript abuse are mostly complaining about things like plain text (or even text plus photos) req

Exactly; those of us "vituperating priests" who rail against JavaScript abuse are mostly complaining about things like plain text (or even text plus photos) requiring JavaScript. You want to create some whiz bang new thing that needs Turing completeness? Go to town with JavaScript. You want to require enabling a possible malware vector and chew through computer resources like they're candy just to read a few paragraphs of text? Forget you, I'll keep browsing. And so will crawlers, so you'll never get linked. Attention is scarce, information is not - do the math.

twistedpair 13y ago
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.
dllthomas 13y ago
Entirely an aside, and not meant as criticism but merely an interesting (hopefully) point noted in passing: If you are doing something that requires Turing-completeness, you're doing something that can't be done on real computers, because any collection of digital hardware can be represented as a (flippin' ginormous) finite state machine.
- eru 13y ago
  Turing machines are not infinite. There are merely big enough for everything you want to do. (I.e. actual infinity vs potential infinity.)
  - dllthomas 13y ago
    Turing defined the machines with reference to an infinite tape. Obviously any given machine (that halts) isn't going to use all of it. If you give any specific hard bound, you have a system which can be implemented on a sufficiently large FSM. There is, therefore, a sense in which you can never "need" a Turing complete system to solve any given problem that you can solve with finite resources.
    - eru 13y ago
      No hard bound, but the tape is only potential infinite. (Compare https://en.wikipedia.org/wiki/Actual_infinity https://en.wikipedia.org/wiki/Actual_infinity)
      - dllthomas 13y ago
        I don't see that that actually has any bearing on what I said, though. Reality will always give some hard bound, on any practical problem.
        eru 13y ago
        Not if you are prepared to buy more RAM (or disk space for swapping) as the program is running.

twistedpair 13y ago

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.

dllthomas 13y ago

Entirely an aside, and not meant as criticism but merely an interesting (hopefully) point noted in passing: If you are doing something that requires Turing-completeness, you're doing something that can't be done on real computers, because any collection of digital hardware can be represented as a (flippin' ginormous) finite state machine.

eru 13y ago
Turing machines are not infinite. There are merely big enough for everything you want to do. (I.e. actual infinity vs potential infinity.)
- dllthomas 13y ago
  Turing defined the machines with reference to an infinite tape. Obviously any given machine (that halts) isn't going to use all of it. If you give any specific hard bound, you have a system which can be implemented on a sufficiently large FSM. There is, therefore, a sense in which you can never "need" a Turing complete system to solve any given problem that you can solve with finite resources.
  - eru 13y ago
    No hard bound, but the tape is only potential infinite. (Compare https://en.wikipedia.org/wiki/Actual_infinity https://en.wikipedia.org/wiki/Actual_infinity)
    - dllthomas 13y ago
      I don't see that that actually has any bearing on what I said, though. Reality will always give some hard bound, on any practical problem.
      - eru 13y ago
        Not if you are prepared to buy more RAM (or disk space for swapping) as the program is running.