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 nearing API stabilization. Some minor calls are still shifting around, but at this point the big conceptual changes are over with and new versions should necessitate only minor find-and-replace operations. Please see the below roadmap for further details. Authors are still cautioned to avoid using Collection folds until the completion of
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.
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. The primary data structures are
Structsaugmented with sematic behaviours to resemble traditional model objects. As with collections, while a model 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 contain many useful mechanisms for declaring behaviour on particular properties, such as serialization strategies or validation conditions.
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.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.
Focused on two major areas: unbundling and formalizing models as data structures and enumeration/traversal of data structures; and resource lifecycle management. Also improved request/store handling, updated dependencies, and improved test coverage overall.
Model, and moved
Structgets all core functionality around key/value storage, basic (de)serialization, and shadowing.
Struct; it retains attribute definition, issue tracking, attribute binding, request resolution, and more-advanced (de)serialization features.
Struct, now more of a data structure, derives from the new
Enumerabletrait along with
List. Enumerability covers the following basic features:
enumerateand live enumeration via
enumeration, which provide all keys (string keys in the case of
Structand integer indices in the case of
List) as either an
List, respectively. Live enumerations then provide
flatMapPairs, which provide
(k, v)arguments to a mapping function.
Varying[Boolean]signalling as such. Modification tracking is now just diff tracking against an object's shadow parent.
Traversalprovides a principled way to recursively walk a data structure tree and map the result onto a like-structured result or into a reducible
List. Default serialization and default diff tracking are implemented in terms of
Traversal, such that their behaviour can easily be overridden piecemeal deep into a structure.
refCount, enabling resources or processing to be spun up and down as necessary.
managed, in the case that a
Varyingreturn value depends on intermediate calculated
managed, the intermediate resources are automatically generated when the
Varyingis actually active, and destroyed when it is not.
Basegets a similar
managed, but instead of managing intermediate resources is concerned with being able to share read-only computed resources like
Enumerations. Methods like
.enumerate()can depend on
Base.managedto vend one shared resource that is spun up or down as needed and destroyed.
Varyinggot a huge internal refactor to cut down significantly on memory and processing usage, and eliminate classes of race condition bugs that became a big problem with the addition of
Storeget upgraded with better handling, new and more consistent APIs, and full test coverage.
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.
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.