Calendar Control

function LoadJS(obj) {
$LAB.script(‘JS/jscal2.js’).script(‘JS/en.js’).block();
alert(‘hi’);
}

<!–
–>

No more need to nest $LAB calls for loading scripts after blocking.. simply continue the main chain of calls and LABjs will manage the loading order/execution for you.

If you haven’t checked out LABjs yet, you really should give it a try. It’s simply the best way to load JS onto your pages.

http://labjs.com/LABjs-0.6.zip

So, now that I have done some further investigation and digging into his code (Ch4 and Ch5), I have some thoughts/comparisons with it versus the direction I took with LABjs.

Short:
Souders’ method, which he has named “EFWS” (name of his book “Even Faster Web Sites”) is really awesome, but has some admitted limitations which run contrary to some of LABjs’ motivating factors. In addition, I think depending on certain conditions (which I will discuss below) LABjs may achieve similar performance in general with EFWS. So both scripts stand on their own as good strong choices for web authors, but for different reasons.

Long:
I’ve written a more detailed evaluation comparison here: http://labjs.com/LABjs_vs_Souders.html

My Conclusions:
My guess is there are some sets of pages out there which have a couple of very proportionally large script assets compared to few numbers of other smaller page assets (images, CSS, etc), and it’s possible that in those cases Souders’ method may squeeze a little more performance in total page load.

But there are also plenty of sites which the balance would be more swayed the other way, with more (or larger) page assets, and compartively smaller (or fewer) numbers of script assets, in which case I think LABjs might perform better.

So, I highly respect the work that Souders has done, and I encourage others to take a look at his code, even try it out on your own pages.

But I think LABjs serves a slightly different audience and use case. The code is smaller and simpler, and is also more flexible to be used at any time during the life of a page. This gives page authors a lot of great choices they didn’t have before.

I hope this helps clarify to those reading the choices they have available to choose from, and why they might look to LABjs and/or Souders’ EFWS method for loading JS into a page.

I think and hope it’s a good, simple, first step to start getting more and more regular websites to improve the performance of their script loading. IMHO, it’s badly needed. My tool is definitely intended for “the masses”. :)

LONG: It’s sad that developers have to do so much work to get around something browsers should do automatically. Even the newer browsers that support parallel script loading (IE8, FF 3.5, Saf 4, and Chr 2) still block other, later resources from being downloaded. I’ve shared my thoughts with some folks involved in HTML5 on my proposal for the SCRIPT tag to handle DEFER, ASYNC, and POSTONLOAD attributes. (I’ll write a blog post about that soon.)

Back to LABjs, let’s revisit the goal. I totally understand that external scripts that depend on each other have to be *executed* in order, but there’s no reason they can’t be *downloaded* in parallel. We’ve seen newer browsers move in this direction, but as I mention in Chapter 4 of Even Faster Web Sites and in my blog post on Loading Scripts Without Blocking, they still block later downloads. Until browsers get better at loading scripts in parallel (and IE 6&7 disappear), developers can use advanced script loading techniques to make their pages faster.

The issue with LABjs is that, when a developer has two scripts that depend on each other (as is often the case when using frameworks like jQuery and Dojo), LABjs requires that the developer use the blocking functionality. This defeats the original goal of loading scripts in parallel.

There is a workaround to this that is compatible across all browsers. I describe it in my book, but the code sample is available without buying the book. The loadScripts Different Domains sample contains the JS implementation to do this. It allows two scripts that depend on each other to be loaded in parallel but executed sequentially. It works in all browsers except Safari 3 and Chrome 1.

Hats off to Kyle for pushing the envelope and making this library available. It would be great if he took it to the next level to support parallel loading of scripts with dependencies, avoiding the blocking behavior that is the motivation behind this work.

*sigh* *depressed*

In these cases, you cannot combine files. On my sites, I’ve now put LABjs into play, by loading in parallel all these external scripts, and *also* combined my own scripts into one or a couple of files at most, to reduce the amount of loading.

Also, on the topic of combining… It’s a good approach in general, but can quickly lead to problems if the file is big and any part of it has change at any relatively medium to high frequency. In those cases, the users have to redownload an entire new file because you tweaked one line of JS. I think there needs to be a happy balance of combining files, and still utilizing (as much as is possible) the power of the browser cache to keep average viewing user experience optimal.

In any case, rare is it that a website can (or should) have ONE js file on a page, usually more. And sometimes they have dependencies. That’s where LABjs comes in, making it easy to load those, manage dependency blocking, and still let the rest of the page load quickly in parallel.

And what about your one JS file? Are you loading that with a regular blocking script tag? Odds are, if it’s “big”, and you’re so in the HEAD of your page, you’re not getting a lot of optimization benefit. A single call to LABjs for your one file would still improve things because you would let the rest of the page load while your big mammoth file loads.

@BenGerrissen – I design enterprise apps, that have mutliple js files that are compiled into one file before they reach prod. It’s fast, and it works well. I wonder why you aren’t defining the API for 3rd parties. If you let them define their own, of course you are going to be frustrated…

It should also be noted that this approach allows the rest of the page to keep loading, as well, instead of waiting on ONLY the JS to load.

I don’t think it’s too hard for web authors to think “Oh, jquery.js needs to load before all the plugins, duh!. So, I’ll first load it, and then block() and then load the rest in parallel”. If that is too hard or forcing them unnecessarily, then I’m not sure other heavier approaches will be palatable.

Interesting thoughts on Obj-J approach. I’ll look closer at it. Again, LABjs can also be thought of as a general, simple dependency loading/management tool, though its primary intended use is just to replace script-tags in a better, more efficient way.

But that’s just it, it’s very simple, JS only, doesn’t work on any build-time steps, or require any heavy frameworks. It also is completely agnostic to what you are loading, so that you don’t have to modify or inspect your scripts to get special convention-based loading signals.

One of the nice things about the loader in Objective-J is that it does a look ahead phase and starts downloading any pending imports immediately, but always executes all import statements in the correct order. You get the best of both features, without needing any additional management on your own.

If you manage your own websites and/or rarely work with third parties creating web applications, I’m sure you will have no to little issues.

But the trend I see these days, is that “not so smart” developers compile frameworks like jquery into the same file. What’s that? “Best practise”??? wrong… It might work for initial deliveries of websites, but it all goes to hell in a year or so, when several third parties all delivered “compiled” libraries and you end up with the browser evaluating 3 jqueries, 5 prototypes, 3 versions of THEIR OWN framework (true story btw) and so on on a single page.

People that compile frameworks together with their own code should be shot!

Thank god some people DO get it and create libraries that modularises javascript.

Tbh. why aren’t browser vendors, w3c and ecmascript working on these kind of solutions… Or are they?

Maybe one is pulled from a CDN, others you host yourself, others are dynamically created on your server, etc?