React 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.0Raynos
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 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:45:45 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
19 sourcesThat 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?To explain why this is nicer than react:
virtual-dom makes zero to non assumptions about your architecture. which I like. It's just dumbly a diffing algorithm and that's it.
Mercury[0] is a "framework" (A collection of opinionated modules) that builds on top of this to give a more complete app stack. And it's really fast[1].
Because it's so dead simple and takes so little assumption, it's really easy to mold to your needs. For example, we've chosen to use it for our Haskell virtual-dom implementation[2]. Also Elm has chosen to use this library for their `elm-html` library [3] and PureScript is using it too [4].
So it's also nicer (in my opinion) from a technical perspective. Not just a licensing perspective.
[0] - https://github.com/Raynos/mercury
[1] - http://elm-lang.org/blog/Blazing-Fast-Html.elm
[2] - https://github.com/ghcjs/g
Read the rest
What are your thoughts on, and how do you let your clients know (since you're a web agency?), that using anything built by Facebook comes with a huge business risk?
With the included PATENTS file, if Facebook decides a patent they filed is something you violate then they will sue you or ask for a royalty. If you try to fight it or even suggest it's not valid then your license for React and all other Facebook projects becomes voided. This gives incredible leverage and power to Facebook for anyone developing their core business with anything they've made/open sourced.
EDIT: https://github.com/Raynos/mercury was suggested as an alternative, I'm not sure how viable it is for different types of projects.
In A Primer for Building Single Page Applications with ReactWhy a company:
https://github.com/Raynos/mercury
All react best practices converge on what mercury has done out of the box since day one. React's advantage is it's community. There are more docs, examples and tutorials.
In React v0.13 releasedYou are speaking my language! I would love to see a prototype of this. I've been thinking about it since I saw React Native.
I wonder if there's even value in something like an asm.js-compiled layout system, which absolutely positions elements. One of the insights of React Native is that to build apps, we really only need a small subset of the web's layout algorithms. Only flexbox, really. So if we recognize this subset, and remove everything else, there main thread can focus on really smooth performance.
React Native even performs the flexbox layout on a 3rd thread, and tells the main thread where to absolutely position stuff.
Obviously we want to re-use as much of HTML as we can, but there might be some crazy ways to remove stuff from the main thread.
EDIT: It should be noted that Mercury, a React-inspired library (https://github.com/Ra
Read the rest
ynos/mercury), has examples of running in a web worker. It is pretty cool, but I think it needs to be fleshed out more.
And those singletons will bite you hard the moment you try to do server-side rendering because you will now have state shared across sessions.
The approach that raynos/mercury takes where state is fully decoupled from layout/rendering is the way to go. In mercury, all the render functions are composed together to make one large pure function. You give it the current state and it deterministically will always render the same layout. So much better than the react approach. Furthermore, the complete decoupling from the rendering functions and the reliance on using bijective lenses with shallow copying means you get time travel debugging for free (i.e. undo redo is available right out of the box)
https://github.com/Raynos/mercury
In First Impressions Using React NativeI would take it a step further and say that server-rendered JavaScript apps completely changes the game and will have ripple effects throughout the web industry.
Here's MercuryJS's example of server rendered app: https://github.com/Raynos/mercury/tree/master/examples/serve...
As you can see most of the code is the client-code. All the server code does is run a function and stringify the results.
What this means is that you no longer need a back-end team and a front-end team. Your front-end team is your team (not counting "API" teams). Sure, some companies have already been doing this but now you can do it with far less code. And you can do it faster. And with fewer developers (there's less work). Which means you can do it cheaper.
All of this means is, if you are writing your front-end and back-end in different languages, you are in a re
Read the rest
al competitive disadvantage.
So any language used for web development is going to see its usage slide if they can't find an answer for transpiling to JavaScript. And hopefully having an isomorphic answer the way JavaScript now has.
In React your component is a class. The `render` function is a pure function, but the component itself is a state machine. This is why I prefer Mercury[1]
[1]https://github.com/Raynos/mercury
In React Hot Loader: Tweak React Components in Real TimeShowing the 15 most recent of 19 sources. Enable JavaScript to search and browse every indexed mention.