[meta] — Application Framework

[meta]

[meta] A stack. A framework. A conversation.

1. Declarative Applications
2. Generative Applications
3. Application Framework (current)
4. Data & Interop Libraries
5. Host Libraries

Previously we looked at application templates in our Declarative Application layer as well as configurations within our Generative Application layer.

This provides a way to build dynamic configuration based applications using ClojureScript. This presents a new problem.

How do we make templates and configurations reusable?

Introducing the Application Framework layer, [meta] framework.

A major use case for [meta] is the ability to “forget” about everything except the Application Logic. This means that your project depends on [meta] as a single dependency which gets you up and running, then add additional dependencies for anything required by the Application Logic.

[meta] Framework + Application Logic = Your Application

To adhere to this goal, [meta] framework wraps all of the underlying libraries and abstracts the usual bits of logic which would be required by any application using these technologies. This allows us to create templates which refer to either:

1. [meta] namespaces
2. underlying namespaces

Although, using underlying namespaces is not recommended as these may change!

Currently, [meta] provides a collection of ready to use namespaces within the framework. These extend common libraries available within the JavaScript/ClojureScript ecosystem, bringing external integrations right into the framework.

The framework itself is divided into tiers:

1. Core
2. Components
3. Integrations

All components and integrations depend on the core. Core is a well-known list of variables which can be used by any of the Components or Integrations. Each variable in Core is dynamic which allows for different runtime bindings to be used. The value of this is apparent when you want to start swapping between integrations within different parts of your application.

This can be used to connect to multiple types of backends, change authentication providers or it can be used to swap routing components within the application.

Separating application concepts such as routing from their implementation, allows the exchange of Integrations within Components.

Components represent concepts within the [meta] framework, they generally relate to the list of variables within core.

(binding [meta.core/*router* (meta.routing/router :history5)] ...)

Binding components within the application allows you to make global changes at a single code site or localize changes within different portions.

Components may also contain their own abstract state.

Integrations are directly implemented on top of 3rd party libraries and abstract any initialization or configurations which may be required to use the libraries.

Using Closure Compiler features such as Advanced Compilation removes any unused Integrations from the final compiled JavaScript.

You can try [meta] and checkout the README over at GitHub.

degree9/meta