Curious about the motivation for this. It’s basically where we were at right before JSX took over, e.g. mercury [1] and the old hyperscript.
Except it’s missing the ability to hydrate components on the client and re-render.
[1] https://github.com/Raynos/mercury
In Show HN: Boxwood – simple templating engine for JavaScript, in JavaScriptRaynos
mercury
JavaScript2014–2024
Raynos / mercury · Archived
mercury
A truly modular frontend framework
23Distinct people
39Mentions
2Explicit recommenders
2.8KGitHub stars
What to know before exploring
What it is
A truly modular frontend framework
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
I liked angular when I was using it, I felt I was able to get more done quicker than I could with Backbone, but both were slower than straight up, good ol' no framework JS. The…
pedalpete used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- matt-esch/virtual-dom · linked in 5 of the same discussions
- evancz/elm-html · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year39 dated mentions
Observed mentions: 2014-05-14 06:25:18 UTC to 2024-05-13 10:15:33 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 13 | 1 | 12 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 19 | 0 | 19 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
mercury
Deprecated: Not actively being worked on.
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.
Description
A truly modular frontend framework
To understand what I mean by truly modular just read the source
Examples
Hello world
'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);
Basic Examples
count
shared-state
bmi-counter
canvas
async-state
real-dom
Intermediate Examples
TodoMVC
markdown editor
number-input
serverside rendering
login form
geometry
2048 (wip)
github issues (wip)
hot reloading with browserify or webpack
Unidirectional examples
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
Backbone + Mercury
Immutable + Mercury
JSX + Mercury
Motivation
Mercury vs React
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)
Modules
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.
Documentation
See the documentation folder
FAQ
See the FAQ document
API
WIP. In lieu of documentation please see examples :(
Installation
npm install mercury
Development
If you want to develop on mercury you can clone the code
git clone git@github.com:Raynos/mercury
cd mercury
npm install
npm test
npm run tasks
npm test runs the tests
npm run jshint will run jshint on the code
npm run disc will open discify (if globally installed)
npm run build will build the html assets for gh-pages
npm run examples will start a HTTP server that shows examples
npm run dist will create a distributed version of mercury
npm run modules-docs will (re)generate docs of mercury modules
Inspirations
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 algorithm
om 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 to mercury that was literally a
re-implementation of elm in javascript
(graphics)
reflex for demonstrating the techniques used to
implement dynamic inputs.
Contributors
Raynos
Matt-Esch
neonstalwart
parshap
nrw
kumavis
MIT Licenced
Read the full README on GitHubWhat Hacker News says
39 sourcesI believe jorgebucaran (hyperapp author) was aware of mithril.js' existence and may possibly have been inspired by it, but I don't take credit for hyperscript itself (it was already a concept used by various other systems - the word "hyperscript" itself comes from the name of a project[0], and there were already other similar frameworks like mercury[1] at the time).
For mithril.js specifically, the hyperscript variation offers an extra feature that AFAIK not many other libs do: the ability to write emmett-like CSS expressions as the tag name (e.g. `m('input.required[type=password]')`). Totally understandable if you think that's too much sugar for your lib, but I've found it handy for usage with CSS frameworks like bootstrap. Mithril.js users also appreciate it and some interesting unexpected patterns came out of that (e.g. `const Foo = '.
Read the rest
some.tailwind.thing'; <Foo />`)
BTW, funny story: mithril.js partially took inspiration from an ancient library called dōmo[2] which - as it turns out - uses the tags-as-functions pattern.
[0] https://github.com/hyperhype/hyperscript
[1] https://github.com/Raynos/mercury
[2] https://jed.github.io/domo/
Mercury - https://github.com/Raynos/mercury
Hyperapp - https://github.com/jorgebucaran/hyperapp
Choo - https://github.com/choojs/choo
In Show HN: Noact – React-like Virtual DOM library in 70 lines of TypeScriptWhat makes this different from Mercury (https://github.com/Raynos/mercury) and a ton of other pre-React frameworks?
In Show HN: Thi.ng/hdom – S-expression based, pure ES6 UI/VDOM componentsThank you for sharing this. I have been doing a lot of digging for an upcoming greenfield rewrite of our client side, and mobx+react is now tied w/ me alongside mercury.js, which shares a similarity in using nested observers as the nervous system of the viewstate. Have you had a chance to look at mercury and the way it achieves unidirectionality?
The documentation for mercury is sadly very poor, but the ideas are sound once you "get it"
here is the repo https://github.com/Raynos/mercury/
here are the rough docs https://github.com/Raynos/mercury/tree/master/docs
how would you compare the prescribed method of state management of mobx+react to mercury's immutable observer state-tree that sends observed changes up to the app root, then signals re-render w/ a immutable state emission to a cascade of renders below it?
In Make state management simple again: Intro to MobXWe don't need smaller frameworks, we need more modular frameworks. If the framework is modular you can take what you need, and replace the parts you don't like.
I'm using mercury [0] in my current frontend project for this purpose. Most of the features of React, none of the commitment. Every single component is interchangeable; the core repository is simply an index.js requiring other modules, which can be depended on individually if you're not looking for a kitchen sink solution.
[0] https://github.com/Raynos/mercury
In Preact, a fast 3k React alternativeMercury, a modular front-end framework inspired by React and Elm
1 points · Open discussionReact 0.14 is 132KB minified [1].
I wouldn't exactly consider React "lightweight," especially compared to other frameworks like Mercury [2], Mithril [3], and Riot [4], which are a fraction of the size of React but still have their own virtual DOM implementations.
[1] https://fb.me/react-0.14.0.min.js
[2] https://github.com/Raynos/mercury
[3] http://mithril.js.org
[4] http://riotjs.com/
In Vue.js 1.0.0That too is solvable by eliminating local state and has an advantage of making animation time travel debugging possible.
So in my comment above I mentioned having a component export two functions. One function is a pure render function and one function creates a state instance. The state of the animation would be one of the things tracked in the state instance:
var Observable = require('observ');
var svg = require('virtual-dom/virtual-hyperscript/svg');
module.exports = state;
module.exports = render;
function state(initialPosition) {
return new Observable(initialPosition || [0,0]);
}
function render(positionState) {
var center = positionState();
return svg('circle', {
'fill': 'rgba(255, 0, 0, 0.1)',
'stroke': 'black',
'stroke-width': '2',
Read the rest
'cx': center[0],
'cy': center[1],
'r': 10
});
}
The parent component would export its state in the same way. Its own state would be composed by calling the state() function of its own subcomponents. Turtles all the way down.
At the top of the app, the saved state would be injected into the state of the top level component, which would decompose it into parts and inject it into the state functions of its subcomponents such as the one above.
This single composed state object tree makes it trivial to record diffs in state for playback or to serialize and save the state to localStorage or the network.
It's trivial to work with the approach above. As trivial as the local state approach of react. It's extremely consistent about where state lives. It doesn't sometimes live in a global place and sometimes live in some other place. Another developer joining the project doesn't have to hunt around for where state for a particular value is being maintained. It also makes it simple to do far more complex things with animation, like build a complex animation editing application where an animation might be controlled by knobs, buttons, sliders, dials, etc. With local state you'd have to wire up those controls directly to the internal state of a component, completely messing up separation of concerns. With the composed state object, you just write one function that maps the state of two sliders (x&y) to the state of the circle and have it listen to change events on the slider position. It's trivial to wire things up in both directions by having them listen to each other.
Time travel (undo/redo) is also trivial to implement:
https://github.com/Raynos/mercury/blob/master/time-travel.js
67 LOC with generous whitespace.
You could wire up the time-travel state to a slider as well to accomplish something like this:
https://www.youtube.com/watch?v=ri614C_Buwg
For the viewing state over time features in the froggato level editor you simply take the series of state over time, use it to instantiate state() multiple times and render them all in the same frame.
Show one circle:
scene -> circleRender(circleStateAtTimePosition(now));
Show one circle over time:
scene -> circleRender(circleStateAtTimePosition(now - 2));
-> circleRender(circleStateAtTimePosition(now - 1));
-> circleRender(circleStateAtTimePosition(now));
-> circleRender(circleStateAtTimePosition(now + 1));
-> circleRender(circleStateAtTimePosition(now + 2));
Local state simply makes everything much harder to reason about as you move beyond all but the most trivial apps.
Lastly, for long running ephemeral state animations, you gain the ability to "cancel" the animation. Imagine you have a "card" animating out from the right to show a panel, but you click on something else that would close that panel and open another one. It's much simpler to cancel that animation midway, close the first card and animate out the second card. The alternative is to add a bunch of methods to the card class to handle the cancellation logic. If you need that cancellation logic in other components you need a mixin, but it's all brittle because its tied to the key names on this.props as opposed to being able to make a animation controlling function used in an animation coordinator that merely needs to receive cursors (i.e. nothing is hard coded to key names)
You might say "but I have no reason to track ephemeral state in that way" and you would be correct, you don't need to. But there are no disadvantages of doing so relative to local state. Furthermore you gain predictability about where state lives and the ability to not worry about refactoring if one day decide that you want to now control a particular piece of ephemeral state.
matt esch's virtual-dom has very similar syntax as this for anyone looking for the same with JavaScript:
https://github.com/Matt-Esch/virtual-dom
Makes server-side and client side rendering a cinch. Here is an example of it in action in mercury:
https://github.com/Raynos/mercury/blob/master/examples/serve...
In Hiccup – A subset of Clojure used for generating HTMLStumbled upon this [1] in their Readme:
mercury is lean, it's an weekend's read at 2.5kloc. (virtual-dom is 1.1kloc, an evening's read.)
1: https://github.com/Raynos/mercury
In Deku: How we built our functional alternative to ReactI think that you are pointing at the wrong file, it looks like the library is actually around 4k lines. The point may still be valid, but it was not a trivial codebase to fork and they seem to have some architectural goals that they didn't think any of the current libraries were well suited to work with.
https://github.com/Raynos/mercury/blob/master/dist/mercury.j...
In Deku: How we built our functional alternative to React> So we looked for smaller alternatives, like virtual-dom and mercury. The documentation for virtual-dom was slim and we didn’t think the API for mercury was very user friendly.
Really? You found that it was better to write everything from scratch instead of modifying mercury for your use (thus making use of the very good virtual-dom library)? Do you know that the whole mercury source code[1] is only 126 lines of code?
Perhaps you should also know that your library usage examples, in the end, look just like mercury usage examples.
[1]: https://github.com/Raynos/mercury/blob/master/index.js
In Deku: How we built our functional alternative to Reactvirtual-dom is excellent.
Also check out mercury:
https://github.com/Raynos/mercury
Or better yet, fork mercury and modify the index.js file and package.json. It's a bunch of libraries masquarading as a framework (which is awesome because it means it's modular instead of monolithic)
In Deku: How we built our functional alternative to ReactI liked angular when I was using it, I felt I was able to get more done quicker than I could with Backbone, but both were slower than straight up, good ol' no framework JS.
The thing is, coding without a framework doesn't give you good coding habits, and the structure that lets other people quickly get up to speed with your code, so I figured a framework was a good idea to give me some structure.
When examining frameworks for my current employer, we were about to go with React and Flux, but as it felt much quicker to develop with, but I just wasn't a massive fan of the process flow of Flux.
In the end, we decided to go with Mercury.js https://github.com/Raynos/mercury, we created a few of our own rules around structure which has help us keep things modular and fairly simple. I highly recommend it.
In Ask HN: Has anyone else found Angular to be destroying their productivity?Showing the 15 most recent of 39 sources. Enable JavaScript to search and browse every indexed mention.