when.js: Removing window.when

[Brian Cavalier]

We're strongly considering removing window.when for when 2.0.  Cujo is highly modular, and we believe the modules are the future, and that globals are not a sustainable pattern for Javascript applications.

If you're using window.when, we need to hear from you ASAP so that we can discuss your situation and see what your alternatives are.

If we don't hear of any blockers, we'll remove it in when 2.0.

[thanpolas]

Hi Brian,

this would plainly cut support for browser javascript applications.

Unless they have an AMD stack, possibly along with a build process.

Personally, that would freeze me in the 1.x version.

[unscriptable]

Hey Thanasis,

> this would plainly cut support for browser javascript applications.

> Unless they have an AMD stack, possibly along with a build process.

It would only cut support for people building apps that don't use one of the de facto standard module formats: AMD or CJSM/1.1.  

It's hard to imagine there are many people who are building reasonably-sized browser apps without AMD or CJSM.  Dependency management is hell without modules.

> Personally, that would freeze me in the 1.x version.

How are you managing dependencies in your app?  Is it a manual process or do you have a custom-made dependency management "stack"?

-- John

[Brian Cavalier]

Thanks for responding, Thanasis.  A couple more quick questions:

Are you using only window.when, or are you using other when.js globals, from other modules, such as window.when_sequence, or window.when_delay, etc.?

If you are only using window.when, then would it be an option for you to use a define() shim, such as: window.define = function(factory) { delete window.define; window.when = factory(); };  You could add something like that into your build process.  Please let us know if that might work for your situation.

Thanks!

On Monday, March 4, 2013 10:18:30 AM UTC-5, thanpolas wrote:

[thanpolas]

I'll start from the bottom up...

I'd need to study it a bit in depth to figure out the best strategy for me to integrate when.js in such a scenario.

But this discussion is not about me or how / if i'll cope. It's about the library's future. 

In that respect:

1. Is there an actual problem that exists today, that forces you to make that decision?

2. What will be the benefit/s that the library will get from such a decision?

I don't want to touch the namespace subject, as i have strong feelings about it and plan on writing a blog post just iterating on why namespaces are good for you and the community.

My suggestion is that not only you should not drop support for window.when, but augment it with all the helper functions that are now polluting the global namespace.

So window.when_sequence should be window.when.when_sequence (or even better: window.when.sequence). 

That would be a change with significant impact to the zen of the library and does not banish vanilla js authors from using the library.

[thanpolas]

John, 

however hard it is to imagine people building apps without AMD or CJSM it happens.

who are building reasonably-sized browser apps

exactly. So you are knowledgeably now targeting only the large-scape apps? I'm sure you don't.

Personally i am authoring using the Google Closure Library which has it's own way of managing dependencies. 

A way that i very recently hacked and exposed as a stand alone API, introducing a radically new way of managing dependencies on your project.

Dependency management is hell without modules.

Yes, agree. But unfortunately (or fortunately?) we are not in a position to tell what other devs should do. 

[thanpolas]

Closing the loop on my arguments here, i have completed the relevant article about Development Using Namespaces.

It's one last plea to reconsider :)