another interesting IoC framework. Wire.JS

[Antranig Basman]

Thanks, Alexey, this is indeed a helpful explanation motivating IoC. Actually I met Brian at the jsconf 
presentation where he delivered these slides and found him a very pleasant and highly switched-on chap :)
Unlike require.js, wire.js is indeed a "true IoC framework" in the sense I described in my earlier message 
on this thread - it is capable of recursive dependency resolution, and the bindings of names onto 
implementations are encoded in declarative structures rather than in code. It is aimed at many of the same 
goals as our framework - a "wiring specification" meets many of the goals of the declarative specification 
which we provide in our "defaults blocks".

wire.js is ahead of our framework in providing facilities in some areas, and behind in some other areas. A 
lot of its idiom is determined by aiming for the maximum possible naturalness and idiom in interacting with 
the node.js/Commons module loading specification, which we've decided for some time (and especially more 
recently with our GPII work) isn't a broad enough base for us to build on for Fluid's aims.

In particular, wire.js has these advantages:

i) An official and regular set of lifecycle points for components (5-stage model described at 
https://github.com/cujojs/wire/wiki/Component-lifecycles ) - this is something we have had on the cards for 
a while but so far only have "events" covering phases of early initialisation (preInit, postInit, etc.). The 
required extension for us is JIRAed at http://issues.fluidproject.org/browse/FLUID-4257

ii) A natural ability to name and load an implementation from a (node) module using syntax like 		create: {
			module: 'hello-wired',
since our scheme for code loading in Fluid only has a sketch implementation (the "fluid.require" system 
which directly invokes platform require) we currently operate a simple scheme which assumes that all 
necessary code has already been loaded.

iii) Good support for asychronously completing activities through the use of "promises" described on 
https://github.com/cujojs/wire/wiki/Factories - this allows CommonsJS compliant "promises" to be used to 
govern a wiring sequence. We plan to support such facilities in the future through an extension of our 
"event boiling syntax", our existing implementation described here: 
http://wiki.fluidproject.org/display/docs/Event+injection+and+boiling

iv) Good support for orchestrating DOM insertion (including templating) and querying activities in amongst 
component initialisation. Currently our renderer in Fluid, although offering very good decoupling between 
markup and components, is very inflexible in its timing and behaves badly in scenarios where rendering 
components are nested. It is also tightly integrated into our component grade structure via 
"rendererComponent" and so hard to replace.

Fluid supplies a mature "events" system to deal with points i) and iii) but currently offers no framework 
support to guide the operation of component lifecycle points and incorporating asynchronous activities into 
the wiring (configuration) sequence - the user at the moment is on their own.


There are the following areas where the dynamism provided by wire.js isn't enough for our needs:

a) Whilst module dependency specification has been shifted out into configuration material, it is not easy 
to allow for "polymorphism" in implementation. wire.js has no equivalent to our demands blocks system, which 
allow an integrator or other developer to selectively override parts of a configuration used by a 3rd party, 
whilst retaining others. wire.js provides for this use case via its "aop" and "facets" system which are 
based on function handles containing code, rather than operating on configuration directly. wire.js does 
provide the "prototype" system ( https://github.com/cujojs/wire/wiki/Factories ) which can be seen as 
similar to our "grades" system, allowing new names to be created for new implementations - however, there is 
no facility for existing implementations to be modified based on context of use.

b) The absence of stable global names in wire.js (inherited from the modules system) makes it even harder to 
deal with point a) - an implementation may be imported from a module, but cannot be reliably identified or 
contrasted with or combined with other implementations in other modules.

c) The particular models for asynchrony (promises) and DOM binding (special syntax for referring to 
elements) are not sufficiently "open". In practice there are multiple models for asynchronous processes 
(indeed, there are multiple Promises libraries even within JS, ignoring other models such as Actors/Monads 
etc. ) and it is impractical to expect all users to commit to exactly one model as "primary" and use 
adaptors to express every other model in these terms (even if this is possible, in practice it often isn't). 
Similarly, DOM binding lacks our model for indirection using the "DOM binder" which allows integrators or 
other developers to find a well-defined place for all DOM binding information where it may be overridden or 
reconfigured.


A big foundational difference can be seen on the wire.js page on contexts - 
https://github.com/cujojs/wire/wiki/Contexts - In Fluid IoC, *every* component automatically becomes usable 
as a context, rather than there being a separate concept of "context objects". Whilst wire.js contexts do 
form a hierarchy, each individual context is "flat". In this example - 
https://github.com/cujojs/wire/wiki/connect-things - the references "component1.doSomethingBefore" etc. can 
be seen as somewhat analogous to a Fluid IoC value reference "{component1}.doSomethingBefore" - but the 
referential power of the 1st path component in wire.js is weaker  - it must refer to a component explicitly 
configured with that name in this or a parent context.


There are various other points of difference that could be viewed at length, but hopefully this is enough to 
give a reasonable idea of the major points of similarity and difference in implementation and philosophy. 
Certainly it is comforting to know that there is at least some other work on "strong IoC" in the JavaScript 
community, which should help familiarise the community with these concepts.

Cheers,
Antranig

On 29/06/2012 10:04, Novak, Alexey wrote:
> It has a very well explained concept and why would you consider IoC (I find it by far one of the best
> explanations)
> If you step through all slides there will be a link to github.
>
>
> http://briancavalier.com/presentations/wirejs-2011-jsconf/#0