Comments on: LABjs: why not just concat? http://blog.getify.com/2009/11/labjs-why-not-just-concat/ open-source, performance, javascript & ui musings Tue, 07 Sep 2010 17:21:05 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Filipe Martins http://blog.getify.com/2009/11/labjs-why-not-just-concat/comment-page-1/#comment-585 Filipe Martins Tue, 07 Sep 2010 17:21:05 +0000 http://blog.getify.com/?p=97#comment-585 I'm not claiming that a 200ms or 1s delay isn't noticeable. I'm saying that it probably won't be important because it's a one time only thing (don't we love the cache?). I do agree with you about the visual feedback, though. I’m not claiming that a 200ms or 1s delay isn’t noticeable. I’m saying that it probably won’t be important because it’s a one time only thing (don’t we love the cache?).
I do agree with you about the visual feedback, though.

]]> By: getify http://blog.getify.com/2009/11/labjs-why-not-just-concat/comment-page-1/#comment-584 getify Tue, 07 Sep 2010 12:06:45 +0000 http://blog.getify.com/?p=97#comment-584 "One second" was kind of an exaggeration. It's been shown that users can perceive a delay if it's over 200ms, which is quite possible if there's a decent sized JavaScript file (or several) that need to be loaded when a user clicks a button. Of course, even a really small file could take 200ms if there's high network latency involved. Because you can't really guarantee someone's connection speeds, I'd tend to assume loading files when a button is clicked <strong>could</strong> have a noticeable delay and would avoid it. But certainly if you are going to do this, give some sort of visual indication (like a loader/spinner) even for the short loads (so that it's present if the load is really long) so users aren't multiple-clicking things because they click and don't see a response quickly enough. “One second” was kind of an exaggeration. It’s been shown that users can perceive a delay if it’s over 200ms, which is quite possible if there’s a decent sized JavaScript file (or several) that need to be loaded when a user clicks a button. Of course, even a really small file could take 200ms if there’s high network latency involved. Because you can’t really guarantee someone’s connection speeds, I’d tend to assume loading files when a button is clicked could have a noticeable delay and would avoid it.

But certainly if you are going to do this, give some sort of visual indication (like a loader/spinner) even for the short loads (so that it’s present if the load is really long) so users aren’t multiple-clicking things because they click and don’t see a response quickly enough.

]]> By: Filipe Martins http://blog.getify.com/2009/11/labjs-why-not-just-concat/comment-page-1/#comment-583 Filipe Martins Tue, 07 Sep 2010 09:50:27 +0000 http://blog.getify.com/?p=97#comment-583 You make a good point, but I'm not sure that's a problem because we're talking about a one second delay (give or take, on a bad day) only on the first click. But that's something for me think about. Thanks for responding. Filipe Martins You make a good point, but I’m not sure that’s a problem because we’re talking about a one second delay (give or take, on a bad day) only on the first click. But that’s something for me think about. Thanks for responding.

Filipe Martins

]]> By: getify http://blog.getify.com/2009/11/labjs-why-not-just-concat/comment-page-1/#comment-582 getify Mon, 06 Sep 2010 20:31:34 +0000 http://blog.getify.com/?p=97#comment-582 I'm definitely a big fan of load-on-demand and load-when-needed approaches. For instance, Facebook now has a "bootstrapper" script (called "Primer") that they load at the beginning of the page, which can handle default actions, and then they layer in additional functionality with futher downloads as the page loads and gets more complicated. You do have to balance on-demand with potential slow-downs that can occur if it takes a second to download code when someone clicks a button to do some action. If the user can see these delays when they are interacting with elements, it can detract from the UX. So, I'm in favor of an approach that progressively downloads more behavioral JS in the background so there's less chance that a user will have to wait on the JS. I’m definitely a big fan of load-on-demand and load-when-needed approaches. For instance, Facebook now has a “bootstrapper” script (called “Primer”) that they load at the beginning of the page, which can handle default actions, and then they layer in additional functionality with futher downloads as the page loads and gets more complicated.

You do have to balance on-demand with potential slow-downs that can occur if it takes a second to download code when someone clicks a button to do some action. If the user can see these delays when they are interacting with elements, it can detract from the UX. So, I’m in favor of an approach that progressively downloads more behavioral JS in the background so there’s less chance that a user will have to wait on the JS.

]]> By: Filipe Martins http://blog.getify.com/2009/11/labjs-why-not-just-concat/comment-page-1/#comment-581 Filipe Martins Mon, 06 Sep 2010 17:28:08 +0000 http://blog.getify.com/?p=97#comment-581 Hello. I'm not convinced with that "huge is ok" approach. I'm fond of the download-the-code-when-needed approach. Meaning, you click a button and the needed code is downloaded and executed. If the button isn't clicked the code is not downloaded. The REST architecture itself praises "Code-On-Demand". What's your opinion on this? Hello. I’m not convinced with that “huge is ok” approach.
I’m fond of the download-the-code-when-needed approach. Meaning, you click a button and the needed code is downloaded and executed. If the button isn’t clicked the code is not downloaded. The REST architecture itself praises “Code-On-Demand”.

What’s your opinion on this?

]]>