Future of FuturesJS

[Tauren Mills]

Sorry, I had a little fun with the subject... :)

Now that I'm using the latest jQuery, which includes Deferred support, I'm finding that it is hard to justify including FuturesJS anymore. And there are already several other implementations in the CommonJS world, I'm not sure how much traction FuturesJS will be able to get anymore. 

Of course it will still be useful to non-jquery users or those who want a more robust solution than jquery provides. But I for one don't want to have different promise objects to deal with. If I do an XHR command in jquery, I'm working with their promises, which are incompatible with FuturesJS. Since I can't drop jquery, I'm more apt to drop FutureJS.

Unfortunately, there are a few things in FuturesJS that are missing in jQuery Deferreds, which I'm really missing. So I'd like to make a suggestion/proposal that could turn FuturesJS into a very valuable project. I suggest you make it more jquery specific, or create a different project that is exclusively for jquery. 

This would involve rewriting it to rely on jQuery Deferred objects instead of the FuturesJS custom deferred/promises. A lot of the codebase could be removed since it wouldn't need to implement any of the features that jQuery already provides. In this way it would become a jQuery specific library, but I don't see this as a bad thing, and it could significantly increase the appeal with the hordes of jquery users out there. One drawback is that it wouldn't be as easy to support SSJS, but if it was split to a separate jquery-only project that wouldn't matter.

So FuturesJS (or maybe FuturesJQ?) would become a jquery "enhancer". I don't really want to call it a plugin because it would be enhancing the actual jquery object, not just adding a new namespace to the jquery object. These enhancements would add support for missing features in jquery.

For instance, there is no easy way to do sequences with jQuery deferreds. To make sure that one command finishes before the next one begins, I'm having to nest $.when()/$.then() calls in success handlers. This defeats the beauty of using promises. Maybe there's a better way, but I haven't found it yet.

Also, the $.when() function doesn't guarantee that all methods are run. If any method fails, others may not have run.  I think it would be nice to have a "finally" method, so that after all methods have either been resolve()ed or reject()ed, a function is run.

This SO question has some ideas that could provide useful:

http://stackoverflow.com/questions/5009194/how-to-use-jquery-deferred-with-custom-events

Anyway, I haven't really looked into how much work this would involve, and I'm just shooting from the hip at the moment. I got frustrated with jQuery's implementation after being spoiled by FuturesJS and saw a niche that would be nice to fill.

Thanks for listening, I'd like to hear any feedback.

Tauren

-- By the way, I'm now heavily invested in Backbone, Underscore, jQuery, and jQuery.tmpl for my single-page javascript apps. It's an awesome combination that I highly recommend. Now if I could just find the time to start working with Node on the server side. I might switch to a different templating solution that works both server and client side. I'm wavering back and forth on wether to give Coffeescript a try.

[Kevin Turner]

I'm glad to hear someone else is thinking about this; FuturesJS looked very promising to me, but with Deferreds landing in jQuery, I held off on adopting FuturesJS in any serious way.  

But if jQuery's Deferreds need enhancing, perhaps the thing to do is to submit patches to jQuery?  Especially if the enhancements can be made in a backwards-compatible fashion.  I haven't really looked in to their development process, but they seem to have fairly frequent releases, at least.

[AJ ONeal]

I haven't had time to respond to this properly, but in short:

I don't plan to create a jQuery version, but I do want to make it easy for jQuery users.

Why Not jQuerify?

I could probably create a wrapper pretty easily, but Futures has gained some adoption in the Node.JS community, which won't use jQuery deferreds in most cases.

Futures will continue to be a cross-platform library.

If you're only using futures for Ajax, then I can see why moving to just using jQuery deferreds would be advantageous.

I'm using AHR (abstract-http-request https://github.com/coolaj86/abstract-http-request) for Ajax on both Node.JS and in the browser.

It's due for a 2.0 rewrite within the next two weeks so if you take a look at it and have suggestions, they'll be appreciated.

It will have FormData support (both on Node.JS and Browser).

How to make it easy for jQuery users?

Will you send me some sample code with the .when/.then problem? I would like to ease your pain.

AJ ONeal

--
Please use prefixes: [Pony] Feature requests, [TestCase] Test cases, [Bug] if you're lazy. If you have contract work or position for FuturesJS devs, prefix [Bounty] or [Job].
-----
To post to this group, send email to futures-j...@googlegroups.com
To unsubscribe from this group, send email to
futures-javascr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/futures-javascript?hl=en

[Tauren Mills]

Hi AJ,

Thanks for your reply. 

Why Not jQuerify?

I could probably create a wrapper pretty easily, but Futures has gained some adoption in the Node.JS community, which won't use jQuery deferreds in most cases.

Futures will continue to be a cross-platform library.

If you're only using futures for Ajax, then I can see why moving to just using jQuery deferreds would be advantageous.

Actually, this is the response I was expecting to get from you. But I still wanted to throw out the suggestion. I'm glad to hear its gaining some traction in the Node.JS community.

As you may have missed in my long message, I did suggest an alternative approach of starting a separate project that enhances jquery, instead of scrapping FuturesJS completely. My thinking is that if you enhance jquery's offering with a jquery specific version, you might get lots of users. When those users move to Node or some other SSJS, they will be more apt to use FuturesJS since they would be compatible and familiar with it.

I'm using AHR (abstract-http-request https://github.com/coolaj86/abstract-http-request) for Ajax on both Node.JS and in the browser.

It's due for a 2.0 rewrite within the next two weeks so if you take a look at it and have suggestions, they'll be appreciated.

It will have FormData support (both on Node.JS and Browser).

Currently, I'm stuck using Java on the server and am not able to use Node, so my usage is all really just in the browser for now. I have a deep desire to start using Node, so I'll keep this project in mind when I do. 

  

How to make it easy for jQuery users?

1. Make deferreds compatible with each other. Make FuturesJS deferreds be compatible with the deferreds created by jQuery $.ajax() calls.

2. Enhance jQuery to add additional features and convenience methods that jquery is missing but FuturesJS provides

 

Will you send me some sample code with the .when/.then problem? I would like to ease your pain.

Perhaps the following code will help illustrate the pain with jquery deferreds. I'm probably just not using them optimally yet and am certain that the code could be improved by removing some of the nested $.when() calls and just chaining thens together: $.when().then().then().then(). Still, it seems like similar types of things can be implemented more elegantly when using FuturesJS 

$.when(loadA()).then(

function() {

// Success - loaded A

// do something before next when()

someGlobal.value = someCalc();

$.when(loadB()).then(

function() {

// Success - loaded B

$.when(loadC(),loadD).then(

function() {

// Success - loaded C and D

dfd.resolve();

},

function() {

// Failure - couldn't load C or D

// However, this just means C or D hasn't

// been created yet (got 404s), which is a

//  valid state. We should still resolve this. 

dfd.resolve();

}

)

},

function() {

// Failure - couldn't load B

// Reject since B is required

dfd.reject();

}

);

},

function() {

// Failure - couldn't load A

// Reject since A is required

dfd.reject();

}

);

Thanks,
Tauren