Instead tonic
and https://tonic.technology/ are actively being worked on.
mercury
has some interesting ideas but they are not very practical at scale.
tonic
is a lightweigth component system on top of web components that leverages
the browsers HTML parser for the heavy lifting instead of virtual-dom
.
It comes with a set of components
which help with building
apps more quickly by having some re-usable components out of the box.
A truly modular frontend framework
To understand what I mean by truly modular just read the source
'use strict';
var document = require('global/document');
var hg = require('mercury');
var h = require('mercury').h;
function App() {
return hg.state({
value: hg.value(0),
channels: {
clicks: incrementCounter
}
});
}
function incrementCounter(state) {
state.value.set(state.value() + 1);
}
App.render = function render(state) {
return h('div.counter', [
'The state ', h('code', 'clickCount'),
' has value: ' + state.value + '.', h('input.button', {
type: 'button',
value: 'Click me!',
'ev-click': hg.send(state.channels.clicks)
})
]);
};
hg.app(document.body, App(), App.render);
- TodoMVC
- markdown editor
- number-input
- serverside rendering
- login form
- geometry
- 2048 (wip)
- github issues (wip)
- hot reloading with browserify or webpack
The following examples demonstrate how you can mix & match mercury with other frameworks. This is possible because mercury is fundamentally modular.
Disclaimer: The following are neither "good" nor "bad" ideas. Your milage may vary on using these ideas
mercury
is similar to react, however it's larger in scope,
it is better compared against om
or
quiescent
- mercury leverages
virtual-dom
which uses an immutable vdom structure - mercury comes with
observ-struct
which uses immutable data for your state atom - mercury is truly modular, you can trivially swap out subsets of it for other modules
- mercury source code itself is maintainable, the modules it uses are all small, well tested and well documented. You should not be afraid to use mercury in production as it's easy to maintain & fix.
- mercury encourages zero dom manipulation in your application code. As far as your application is concerned elements do not exist. This means you don't need to reference DOM elements when rendering or when handling events
- mercury is compact, it's 11kb min.gzip.js, that's smaller than backbone.
- mercury strongly encourages FRP techniques and discourages local mutable state.
- mercury is highly performant, it's faster than React / Om / ember+htmlbars in multiple benchmarks
TodoMVC benchmark
animation benchmark TodoMVC benchmark source - mercury comes with FP features like time-travel / easy undo out of the box.
- mercury is lean, it's an weekend's read at 2.5kloc. (virtual-dom is 1.1kloc, an evening's read.) compared to react which is almost 20kloc (a month's read)
mercury
is a small glue layer that composes a set of modules
that solves a subset of the frontend problem.
If mercury
is not ideal for your needs, you should check out
the individual modules and see if you can re-use something.
Alternatively if the default set of modules in mercury
doesn't
work for you, you can just require other modules. It's possible
to for example, swap out vtree
with
react
or swap out observ-struct
with backbone
See the modules README for more information.
See the documentation folder
See the FAQ document
WIP. In lieu of documentation please see examples :(
npm install mercury
If you want to develop on mercury
you can clone the code
git clone [email protected]:Raynos/mercury
cd mercury
npm install
npm test
npm test
runs the testsnpm run jshint
will run jshint on the codenpm run disc
will open discify (if globally installed)npm run build
will build the html assets for gh-pagesnpm run examples
will start a HTTP server that shows examplesnpm run dist
will create a distributed version of mercurynpm run modules-docs
will (re)generate docs of mercury modules
A lot of the philosophy and design of mercury
is inspired by
the following:
react
for documenting and explaining the concept of a virtual DOM and its diffing algorithmom
for explaining the concept and benefits of immutable state and time travel.elm
for explaining the concept of FRP and having a reference implementation of FRP in JavaScript. I wrote a pre-cursor tomercury
that was literally a re-implementation ofelm
in javascript (graphics
)reflex
for demonstrating the techniques used to implement dynamic inputs.
- Raynos
- Matt-Esch
- neonstalwart
- parshap
- nrw
- kumavis