The end result was so modular that we had a standalone web page for loading a controller.
If you want to get started using Halo, please visit the README. The remainder of this article will cover what it is good/bad at.
As already mentioned, Halo is great at modularity. Every model, view, and controller is self-contained with a global mediator, Sauron to talk through if they need to.
The convention of the framework is to keep interactivity at the HTML/Builder level. This leads to a flat and understandable view infrastructure since everything acts as jQuery plugin.
There are concrete channels/methods that controllers/models interact over. However, they are on an extensible system to create custom side-channels as necessary. For example,
Sauron.voice('dom/insert') is used for the requiredom jquery plugin.
The framework is pretty loose in terms of input/output expected for models/controllers. It allows for infinite parameters and any of them could be callbacks which allows for quick hacks if you really need to.
Models need some work. They are currently extremely loose in that there is no framework around schema/creation/maintennance. It was initially conceived that APIs should do the heavy lifting, however, there should be some level of support on the client-side as well.
State could use a boost; there is currently no template for a state model(s). As a result, state persistance/URL maintenance has a higher barrier to entry. However, there is a great foundation here; we can create a
state model (internally stored object) with its own set of logic. Then, we can use a slick URL format (e.g. URLON) for persistance.
This has the benefit of removing brittle links/routes from your HTML and keeping state at the application level rather than template level.
Controllers/models are not standardized to a specific parameter length. This is a counterpoint to the
infinite parameters point mentioned above. It is a coinflip if there should be enforcement; the benefit being less guesswork about each controller's input.
Currently, you can only have one controller of its type at a time. Interestingly, this has never given me a trouble; there is never the exact same set of business logic in two places. If there is, it is probably improperly placed view logic and/or something is organizationally incorrect.
However, I still find this as an open wound. It has been partially addressed with the factory pattern but is still an [open issue][multi-controller-issue].
It's still unclear how far I will be taking Halo. There are always more practical tools to build for the public. However, Halo itself is unique from a lot of other frameworks.