the two-faced application library-framework
Janus is a library-framework designed to simplify web application flow through the application of FRP and reactive programming principles. It was conceived in order to facilitate applications that could be freely rendered server- and client-side from a single codebase -- the dedication to purely functional userland code and idempotent rendering/templating operations arose as a natural outcome of this goal. This is not a complete application framework -- it contains many of the relevant building blocks, but needs to be supplemented with, amongst other things, a DOM manipulation library like jQuery, and a web application server like Express or Flatiron.
Of note should be the Janus Standard Library, which contains useful default implementations of core Janus components, and the Janus Samples repository, which contains a growing library of illustrative Janus projects.
Janus is current undergoing significant refitting. Now that we're up to
0.2, the library is beginning to stabilize and many parts should be ready for general use. Authors are cautioned to avoid more-advanced
Model features such as shadowing and change-tracking, and these are due for overhaul in
0.3, as well as the Collection folds, as those will need considerable thinking in
0.4 to account for performance issues.
Janus is comprised of some core abstractions that are independently useful, but then leveraged to form increasingly opinionated but powerful layers for constructing web applications:
flatMapare all provided, and the final result may be directly observed via
caseto provide a point-free way to declaratively define various necessary values and their combination into a final result, without specifically referencing object instances. This is used, for instance, in the templating engine to allow
Modelproperties to be bound onto DOM objects declaratively and statelessly.
Varyingvalues onto a DOM tree:
Varying-wrapped values onto DOM state in various ways: class names, textual contents, style properties, and wholesale rendering of subviews are accomplished through mutators. Each mutator declaration represents precisely one binding.
DomView, which wraps and manages the lifecycle of templates and their associated DOM fragments, as well as their binding to a
Modelobject. The more-generic
Viewsheds any DOM-based assumptions, allowing for alternative view artifact types.
Varyings into useful object abstractions resembling traditional model objects. The primary difference is that while an object's properties may be trivially set imperatively with
#set(key, value), use of
#get(key)is highly discouraged -- instead,
#watch(key)is the standard practice, which returns a
Varying. Models also contain many useful mechanisms for declaring behaviour on particular properties, such as serialization strategies or validation conditions. Model is due for a major overhaul in version 0.3.
Varyingand functional approaches rather than imperative operations that are time-sensitive. For instance, given collection
a, we can derive collection
b = a.map((x) -> x + 1)as expected, but updates to collection
awill be result in recalculation and update of collection
b. Collection is due for a major overhaul in version 0.4.
Philosophically, Janus hews closer to an MVVM approach than an MVC one -- any behaviour that doesn't comfortably fit into model or template declaration is likely accomplishable by inserting an intermediate
ViewModel between the data Model and its template. Most controller-like behaviour are in practice very short, understandable snippets of imperative programming within
There remain three major blocs of work to be accomplished before a
1.x release can be considered:
0.3will be the great unbundling of
Struct, which is purely a collection of
Varyingobjects addressed by property keys.
Modelcurrently supports become either increasingly powerful subclasses, or extension behaviour that may be plugged in to
Model: shadow copying, attribute behaviour, property binding, validation, serialization, and change tracking.
Storeabstractions, which were updated in
0.2, will be audited for further finalization.
0.3will require minor code changes -- all the final features are superset and all concepts remain identical, but things will be cleaned up internally and possibly minorly moved about. As noted above, authors are cautioned to avoid shadow and change tracking features in the meantime.
0.4will be a refactoring of
fold-related operations are nearly unusable at the moment.
0.4should be almost entirely backward compatible.
0.5serves as a release candidate for all of the above changes, as well as an umbrella milestone for improvements, changes, or removals to the
1.0will follow, stabilizing the API for the first time.
Completely overhauled and rewrote the
Varying abstraction, as well as much of the templating, view, model, and collections systems that were too tightly-bound to
Varying to escape rewrite. Introduced
from as vital core abstractions. Also dramatically increased test coverage, streamlined and removed a bunch of fluff components, and other miscellenia.
Varyingbecame a true monad: it no longer automatically flattens its contents. It also no longer uses an event-based system for change propagation, as this resulted in intractable race condition problems as well as performance issues. Many improvements and changes aren't listed here.
casesystem is new, and an attempt to formalize and abstract the internal behaviour-handling models of Janus such that they can be easily augmented or replaced in userland where needed. It is a response to the problems with
fromsystem is a reconsideration of how databinding can be declared and executed. Its point-free programming model enables it to be freely leveraged to solve any number of problems unrelated to databinding.
Templateare ground-up reconsiderations of how to bundle template-like behaviour.
Modelare impacted insofar as their interfaces to the above are concerned.
janus-stdlib, which contains a slew of very useful default View implementations for the objects in the library.
0.2 is strictly not backwards compatible, as it represents a major formalization effort that can impact the behaviour of code that was loose but would function in
0.1. Please see the note in the introduction about the state of the library given
Initial release. All the basics are here, but given that the philosophy codified alongside the development, the exposed API is less than precise and often in conflict with the underlying machinations.
Janus is licensed under the WTFPL.