ECMAScript5 dependencies

1 view
Skip to first unread message

Tauren Mills

unread,
Sep 16, 2010, 4:34:58 AM9/16/10
to FuturesJS
Its been a while since I tested my app on a platform other than
Chrome, but just did so tonight. I quickly realized that futuresjs is
reliant on ECMAScript 5 methods Object.keys and Array.isArray. I can
easily add these methods, but I'm just wondering if it makes sense for
the library to rely on their existence. Shouldn't it be built to run
on a wider range of browsers?

There are good reasons to include support for older browsers, but
there is also a good case for not duplicating code that a client
probably already has in other JS files anyway. I don't really want to
include all of underscore.js, so I'll probably just add these methods
to another one of my JS files.

I'm going to go off topic here...

This has me thinking that there should be some way to perform "feature
detection" and load additional code only when necessary. The idea
would be to have "feature plugins" in separate files that would be
loaded only if that feature wasn't implemented in the current
environment. Maybe this already exists in CommonJS or something
similar.

Perhaps something like this:

requireFeature(Array, "isArray", "feature.array.js");
requireFeature(Object, "key", "feature.object.js");
requireFeature(Date "parse", "feature.date.js");

function requireFeature(obj, method, file) {
if (!obj[method]) {
// use some method to load Javascript file
// such as $.getScript(file);
}
}

Obviously, there would be more to it than this. And I'm sure something
similar has already been done before in CommonJS, Google Closure, etc.
Nor should this be part of FutureJS itself.

Maybe isArray and key() aren't that great of examples, as the amount
of code is so lightweight. But take date parsing for instance. The
jQuery Datepicker plugin, the DateJS library, and the FullCalendar
plugin all have code to parse dates. They all do it differently, but
the resulting output it basically the same. Wouldn't it be nice if
these were features that could be externalized and included only if
you didn't already have the feature?

Of course this would create additional requests instead of adding
possibly unnecessary minified code to a single big JS file. Not sure
which would be worse...

AJ ONeal

unread,
Sep 17, 2010, 3:16:01 AM9/17/10
to futures-j...@googlegroups.com
ES5 in Futures

Futures uses and will use ES5.
I'm also using Futures server side with NodeJS (and that is influencing how I'd like to reshape the API)
Even IE9 is now supporting standard JS as I understand it.

For light-weight ES5 in the browser I recommend:
With the comments removed and minified it's very small.

Note: you'll have to remove the very last line -- require('JSON') -- unless you use some client-side CommonJS require function.

There are good reasons to include support for older browsers, but
there is also a good case for not duplicating code that a client
probably already has in other JS files anyway.

3k of a client's download is well worth not having the headache of duplicating this all of the time:

function loop(val, key, obj) {
 // do_stuff
}
for (x in obj) {
    if (obj.hasOwnProperty(x)) {
        loop(obj[x], x, obj);
    }
}
 

This has me thinking that there should be some way to perform "feature
detection" and load additional code only when necessary. The idea
would be to have "feature plugins" in separate files that would be
loaded only if that feature wasn't implemented in the current
environment. Maybe this already exists in CommonJS or something
similar.

Google has it in their compiler toolset. Uses server-side client detection and sends a pre-optimized version of the code for that browser.
I don't know of any NodeJS or CommonJS modules that do the same and I wouldn't recommend that you try on your own.
 
Of course this would create additional requests instead of adding
possibly unnecessary minified code to a single big JS file. Not sure
which would be worse...


Yeah, I think that the latency of another request is greater than the cost of an extra 10kb.

When even Google is loading full background images for blogspot, iGoogle, etc, I don't see the cost of a few kb of JS as a big loss.

However, in the mobile space I agree that it is something to consider.

Thanks for the feedback Tauren.

I've got some interesting stuff coming up soon with CopyCat (some of it exists and is very functional, just not well packaged yet) and then I'll be back to working on Triforce, bringing in some concepts I found in NodeJS - specifically nStore.
Reply all
Reply to author
Forward
0 new messages