HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
tonsky
rum
HTML2014–2023
tonsky / rum

rum

Simple, decomplected, isomorphic HTML UI library for Clojure and ClojureScript

Web DevelopmentLanguages & CompilersLibraries & SDKs
Explore on GitHubRead Hacker News discussions
13Distinct people
16Mentions
1Explicit recommenders
1.8KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Simple, decomplected, isomorphic HTML UI library for Clojure and ClojureScript

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

I love React as long as it has a thin skim of clojurescript over top. Rum is the underdog compared to reagent but is still my weapon of choice - https://github.com/tonsky/rum…

Nihilartikel used a recommendation phrase. One indexed comment matches. 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

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, 11:56:56 AM 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 year16 dated mentions

Observed mentions: 2014-12-28 10:07:17 UTC to 2023-05-26 22:28:03 UTC.

012342014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 submissions, 1 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2023

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC110
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC202
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC211
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC404
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC202

What Hacker News says

16 sources
alex-robbins·May 26, 2023
In the context of this article, it's worth pointing out that hiccup doesn't escape strings automatically. Rum does, and I've been using it as a drop-in replacement: user> (require '[rum.core :as rum] '[hiccup.core :as hiccup]) nil user> (rum/render-static-markup [:p "<script>alert('you have been pwned')</script>"]) "<p>&lt;script&gt;alert(&#x27;you have been pwned&#x27;)&lt;/script&gt;</p>" user> (hiccup/html [:p "<script>alert('you have been pwned')</script>"]) "<p><script>alert('you have been pwned')</script></p>" (Note that Rum is also a React wrapper, but you don't have to use that part of it; you can simply use it for static rendering of HTML.) https://github.com/tonsky/rum
In That people produce HTML with string templates is telling us something
Nihilartikel·Mar 11, 2023Recommendation phrase
I love React as long as it has a thin skim of clojurescript over top. Rum is the underdog compared to reagent but is still my weapon of choice - https://github.com/tonsky/rum Was disillusioned when I had to dive into a pure js project using React. The real benefit, I think, is that you get the well established Clojure idioms around isolating and managing mutable state. State is stored in a Atom, which is atomically mutated, and reactive components essentially 'subscribe' to updates upon that atom to re render. The mutations can be handled centrally by a message queue, but really, event sourcing like that is not always needed.
In Common Beginner Mistakes with React
Nihilartikel·Jan 9, 2021
I've had an in-browser animated meme editor in the freezer for a few years now: https://www.ultime.me/ The idea came when I wanted to make a simple animated meme, but found it exceedingly frustrating to caption a simple animated gif with nice text options (like outlines). Over time, it's grown to have full keyframe animation for all text and image/video clip attributes, so it is actually pretty capable short of using a desktop video editing/fx package. That said, the UX is bad and I should feel bad :) . I made the deliberate choice up front to focus on the underlying data model and internal APIs rather than polishing the UI - as such, it is very much an engineer interface. It would be more usable with some demo videos or call-to-action helpers for new users, but really the UX just needs reworked. Especially around animation/keyframing. On
Read the rest
the bright side, the clean data model and content addressable assets leave the path clear to add things like collaborative multi-user meme editing, git like meme-forking(and diffing?), and so forth. Started it about 3 years ago when I had a period of mostly free time to play. It's been idle for a long time due to starting a family and getting consulting momentum, but I'm intending to make the time this year to polish the UX to the point of general usability and experiment with promotion/monetization. Failing that, I'll probably just open source it and write a couple of blog posts about the internals. It is more or less a static web app, with no server side function short of some optional stats collection. It's written in Clojurescript/Clojure and uses https://github.com/tonsky/rum as a React wrapper and https://github.com/Kagami/ffmpeg.js/ to import most animation formats and export gifs/webm fully in browser (I don't want to pay real server costs to encode animation).
In Ask HN: Show me your half baked project
slifin·Jun 22, 2020
It's weird how in the JS community rewrites of react are common in the CLJS community using React as a runtime is more common: - https://reagent-project.github.io/ - https://github.com/day8/re-frame - https://github.com/tonsky/rum And my favourite - https://github.com/fulcrologic/fulcro Hosting your work on top of another ecosystem, such that you can still use the underlying ecosystem, gives you a lot of leverage out the gate
In Show HN: Noact – React-like Virtual DOM library in 70 lines of TypeScript
jwr·Apr 27, 2020
ClojureScript user here, with a big SaaS app using React, developed over the last 4 years or so, using the excellent Rum library, https://github.com/tonsky/rum. It seems to me that React Hooks, like so many things in the JavaScript world, solve a problem I do not have. To this day, despite being a heavy user of React, I don't even fully know what they do. I've read the "Motivation" section of the React Hooks Intro, and it seems that I have none of the problems they describe: I can (and do) easily add stateful logic via Rum mixins, and that logic is reusable across components. Also thanks to Rum mixins, complex logic is understandable and does not get all thrown into a single 'componentDidMount' function. As to "Classes confuse both people and machines", I find it hard to relate to this problem, because I don't really see any classes. I wo
Read the rest
rk with components that have a render function and mixins, and if you don't use any mixins, a component looks just like a function. This tends to be a recurring theme: every once in a while I read an article about JavaScript and React, and I can't even relate to the problems, because they do not exist in my world. Another good example is hints on how to optimize apps to avoid excessive re-rendering, something I get for free with ClojureScript and immutable data structures (you can always quickly tell if two data structures are equal and avoid rendering).
In A Critique of React Hooks
jwr·Apr 13, 2020
Reagent is good for starting if you are new to React, but quickly becomes limiting. I found Rum (https://github.com/tonsky/rum) to be a much more flexible choice. It doesn't force you into a single way of doing things, but rather offers a composable way of adding behavior to components using mixins. Especially for larger and more complex applications this proves to be a good tool. Another thing which I really like about Rum is "isomorphic rendering" (not a good name, but I didn't invent it) — pre-rendering the DOM on the server instead of shipping an empty page to the client and requiring the client to render everything using JavaScript.
In Luminus – A Clojure Web Framework
tvaughan·Apr 13, 2020
We just re-evaluated our choices and selected Fulcro. Below is a slightly edited version of how we came to this conclusion. As a business building an extremely ambitious product on a tight budget, we want to be able to: * Focus as much time and thought on building features that bring value to our customers, rather than, for example, building a bespoke protocol between the browser and back-end if a better alternative is available. * Share early iterations of our application with everyone in our organization easily. Capture feedback and push out new iterations quickly. * Be able to support new customers immediately. Our feature road-map will always be in constant flux, but at no point should our ability to make changes with confidence be compromised. In addition to feature development, tests and automation must be priorities. Ou
Read the rest
r development and production environments must match. * Be ready to onboard new team members. "Works on my laptop" is never acceptable. Enough of our application must be documented and automated so that anyone with a technical background "reasonably proficient" in our work can contribute without requiring hand-holding. Or course, we'd never turn down a request for help. Our requirements are: * Clojure, Clojurescript, and Datomic are immutable choices. We love these solutions for their simplicity and expressiveness. We believe these are the best choices available for achieving our long-term business goals. * Be measurable. Our work should be guided by data not guesswork. * Be testable. The entire application should have 100% test coverage as measured by its acceptance or integration tests (not unit tests). Changes should be made with confidence. * Be performant. As builders of both the front-end and back-end components, we should encourage cooperation between them, not purposefully isolate them. Our customers and the end-user experience should be our priorities, not artificial divisions between software components or technical teams. Each component of the application should cooperate to support progressive enhancement where every URL is a real URL that, when requested, returns a server-side rendered page view. Further actions by the user result in browser-side changes through API calls and minimal component updates. * Be pragmatic. We should be eager to innovate when the need arises. However, we should be humble enough to understand that sometimes, as software developers, we can become enamored with new toys that are entertaining, and possibly educational, but offer little business value. We should choose existing solutions to our problems that are acceptable enough over building our own solutions simply because we want to. For example, a standards-based protocol, like https://github.com/edn-query-language/eql, that allows clients to craft their own queries with little to no server-side updates is preferable to our current bespoke solution. * Be documented and supported. Our choices should have active, helpful, and inclusive development communities built around them. Our choices are: * Rum, https://github.com/tonsky/rum Rum is a solid piece of software, created and maintained by @tonsky, that provides a minimal wrapper around react for creating client-side components, and supports server-side rendering. Although rum does not provide a protocol between client and server, nor a client component state-management solution. * Reagent, https://github.com/reagent-project/reagent Together with Re-frame, https://github.com/Day8/re-frame, this is by far the most popular choice for building reactive client components in Clojurescript. These do not include the server-side solutions we need. * Hoplon, http://hoplon.io Hoplon was created in-house at AdZerk, and later spun-out as an open source project. Hoplon is a complete solution although it uses a less intuitive spreadsheet-like method for building applications with little obvious advantage, and would not be compatible with Datomic without considerable effort. * Luminus, https://luminusweb.com Luminus is a complete solution like Ruby-on-Rails, and is tightly coupled to SQL. Like Hoplon, Luminus would not be compatible with Datomic without considerable effort. * Pedestal, http://pedestal.io Pedestal is supported by Cognitect, the custodians of Clojure and the creators of Datomic. Except Pedestal is best suited for building server-side APIs, and applications that need to stream data in "near real-time" to large numbers of concurrently connected clients. * Fulcro, https://fulcro.fulcrologic.com/ Fulcro is based on Om.Next, provides both front-end and back-end components that work well together, includes tools for building and debugging both, supports server-side rendering, and is supported by a diverse community. Paid commercial support is provided by the core developer team at Fulcro Logic. * Datomic Cloud, https://www.datomic.com Datomic Cloud is a special version of the Datomic database that is tightly integrated with AWS. Datomic Cloud includes a set of Cloud Formation templates for running Datomic in AWS, and taking advantage of AWS specific features, such as auto-scaling groups and load-balancers for distributing traffic across a cluster of Datomic peers. Datomic Cloud also includes Ions, https://docs.datomic.com/cloud/ions/ions.html, to help run Clojure functions as AWS Lambdas. Cognitech claims Datomic Cloud is a suitable framework for building complete applications. Unfortunately Datomic Cloud alone is insufficient. Datomic Cloud lacks a framework for building and testing client-side applications, and a protocol for interacting with Ions.
In Luminus – A Clojure Web Framework
pgt·Dec 12, 2019
(Edit: it is worth noting that Hooks are based on Reagent's reactive atoms.) Compare the complexity of Hooks with the simplicity of state management in [Reagent](http://reagent-project.github.io/) or [Rum](https://github.com/tonsky/rum). Complete ClojureScript example using Reagent: (ns reagent-example.core (:require [reagent.core :as r]) (def !count (atom 0)) ;; ! prefix is convention for state (defn counter-component [] [:div [:p "You have clicked the button " @!count " times."] [:button {:on-click #(swap! !count inc)} "Increment"]]) (r/render [counter-component] (js/document.getElementById "app")) The same example using Rum: (ns rum-example.core (:require [rum.core :as rum]) (def !count (atom 0)) (rum/defc counter-component < rum/reactive [] [:div [:p "You have clicked the button "
Read the rest
(rum/react !count) " times."] [:button {:on-click #(swap! !count inc)} "Increment"]]) (rum/mount (counter-component) (js/document.getElementById "app"))
In Thinking in React Hooks
Nihilartikel·Aug 31, 2018
So, I've only used react indirectly via Clojurescript and https://github.com/tonsky/rum for a personal project... I don't spend much time in the front-end otherwise, but every time I read something about using React from JS as one would regularly it feels much, much more complicated. I.e. I just write functions that return hiccup-html lists, and @decorate a cursor into my immutable state structure for reactive updates, and that's pretty much all there is to it, apart from a few event handlers and decorations to do special DOM pre/post wrangling for odd cases. Could someone having experience with Rum or other Clojurescript React bindings, but a better understanding of React coming from more JS like languages chime in with their experience?
In React Fire: Modernizing React DOM
priornix·Jul 13, 2017
Depends whether you learn best by reading [1], answering some interactive questions/koans [2], or downloading and playing around with a ToDoMVC app example [3][4][5] or a mixture of the above. Feel free to join the #clojurian Slack channel [6] if you need help. As a beginner, I recommend you looking at the Reagent [7] or Rum [8] React library first, than you can look at something more complex and full-featured like Om [9] later (whose author is also a ClojureScript core contributor @swannodette). PS: You can also learn by implementing a Dashboard like this [10]. Disclaimer: I am the author of this library. [1] http://funcool.github.io/clojurescript-unraveled/ [2] http://clojurescriptkoans.com/ [3] http://todomvc.com/examples/reagent/ [4] https://github.com/reagent-project/reagent/tree/master/examp... [5] https://github.com/gadfly361/cljs-
Read the rest
todomvc [6] http://clojurians.net/ [7] https://reagent-project.github.io/ [8] https://github.com/tonsky/rum [9] https://github.com/omcljs/om [10] https://github.com/priornix/antizer
In ClojureScript Is Not An Island: Integrating Node Modules
xavi·Aug 1, 2015
ClojureScript with Enfocus (https://github.com/ckirkendall/enfocus/) in the front-end, and Clojure with Enlive (https://github.com/cgrand/enlive) in the backend. It's not a SPA. I started it a while ago, before React/Om. If it were now I would write it as a SPA and use some React wrapper, probably Rum (https://github.com/tonsky/rum). As for HTML/CSS, no framework at all. I'm interested in simple, minimalistic, innovative design, and I don't think frameworks help to achieve that.
In Show HN: Omnimemory – Simple multi-device flashcards

Showing the 15 most recent of 16 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.