HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
reagent-project
reagent
Clojure2015–2024
reagent-project / reagent

reagent

A minimalistic ClojureScript interface to React.js

23Distinct people
23Mentions
0Explicit recommenders
4.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A minimalistic ClojureScript interface to React.js

GitHub

Where it is used

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

What people are saying

No recommendation phrase was found in the indexed comments.

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, 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 year23 dated mentions

Observed mentions: 2015-03-13 13:02:04 UTC to 2024-05-23 05:38:23 UTC.

012342015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 4 mentions; 2 submissions, 2 comments20152016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 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 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024

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
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC422
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC202
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC303
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 UTC202
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC303
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC404
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
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
A simple ClojureScript interface to React. Reagent provides a way to write efficient React components using (almost) nothing but plain ClojureScript functions. Detailed intro with live examples News Documentation, latest release Documentation, next release: API docs, Tutorials and FAQ Community discussion and support channels #reagent channel in Clojure Slack Commercial video material Learn Reagent Free, Learn Reagent Pro (Affiliate link, $30 discount) Learn Re-frame Free, Learn Re-frame Pro (Affiliate link, $30 discount) purelyfunctional.tv Lambda Island Videos Usage To use Reagent in an existing project you add this to your dependencies in project.clj: And provide React using npm (when using e.g. Shadow-cljs) npm i react@19.2.3 react-dom@19.2.3 If there is a more recent minor or patch version of React available, it should be safe to use it in your application. If you want to keep using React 18 or older versions, you can also use cljsjs packages to provide React. Reagent isn't tied to only React-dom but should work with other renderers also. Examples Reagent uses Hiccup-like markup instead of JSX. It looks like this: (defn some-component [] [:div [:h3 "I am a component!"] [:p.someclass "I have " [:strong "bold"] [:span {:style {:color "red"}} " and red"] " text."]]) Since version 0.8: The :class attribute also supports collections of classes, and nil values are removed: [:div {:class ["a-class" (when active? "active") "b-class"]}] You can use one component inside another: (defn calling-component [] [:div "Parent component" [some-component]]) And pass properties from one component to another: (defn child [name] [:p "Hi, I am " name]) (defn parent [] [child "Foo Bar"]) You mount the component into the DOM like this: (defn mount-it [] (rd/render [parent] (.-body js/document))) assuming we have imported Reagent like this: (ns example (:require [reagent.core :as r] [reagent.dom :as rd])) State is handled using Reagent's version of atom, like this: (defonce click-count (r/atom 0)) (defn state-ful-with-atom [] [:div {:on-click #(swap! click-count inc)} "I have been clicked " @click-count " times."]) Any component that dereferences a reagent.core/atom will be automatically re-rendered. If you want to do some setting up when the component is first created, the component function can return a new function that will be called to do the actual rendering: (defn timer-component [] (let [seconds-elapsed (r/atom 0)] (fn [] (js/setTimeout #(swap! seconds-elapsed inc) 1000) [:div "Seconds Elapsed: " @seconds-elapsed]))) This way you can avoid using React's lifecycle callbacks like getInitialState and componentWillMount most of the time. But you can still use them if you want to, either using reagent.core/create-class or by attaching meta-data to a component function: (defonce my-html (r/atom "")) (defn plain-component [] [:p "My html is " @my-html]) (def component-with-callback (with-meta plain-component {:component-did-mount (fn [this] (reset! my-html (.-innerHTML (rd/dom-node this))))})) See the examples directory for more examples. Performance React is pretty darn fast, and so is Reagent. It should even be faster than plain old javascript React a lot of the time, since ClojureScript allows us to skip a lot of unnecessary rendering (through judicious use of React's shouldComponentUpdate). The ClojureScript overhead is kept down, thanks to lots of caching. Code size is a little bigger than React.js, but still quite small. The todomvc example clocks in at roughly 79K gzipped, using advanced compilation. About The idea and some of the code for making components atom-like comes from pump. The reactive-atom idea (and some code) comes from reflex. The license is MIT.
Read the full README on GitHub

What Hacker News says

23 sources
Here is where I'd start for the path of least resistance while still using the most modern libraries: - Dependency management: https://clojure.org/guides/deps_and_cli - Clojure->JS compiler: https://github.com/thheller/shadow-cljs - React integration: https://github.com/reagent-project/reagent - Global state management (optional): https://github.com/day8/re-frame You might also want a CSS framework. There are some options to write CSS in ClojureScript, but I prefer TailwindCSS which isn't a Clojure-specific thing and it works fine out-of-the-box with `.cljs` files. You can swap out Reagent for Helix, which is a lower-level and faster wrapper for React. That said, Reagent does work with React 18 just fine and there's tons of docs for it, so jumping to Helix first is a premature optimization IMO, especially if you're new to Clojure.
In Try Clojure
> But Reagent supports functional components as well, with hooks and all. I addressed this already: while reagent is able to emit function components, there is a performance penalty to this.[1] > I also very much like Hiccup, and so do many of us, because code is data and data is code, and Helix has decided not to support that. Hiccup is convenient to write, but it is a constant run-time cost and a significant storage cost given that you have to store long series of constructors to cljs.core.PersistentVector in your bundle, have the JS runtime actually construct the vector, then pass it through a Hiccup interpreter to finally produce DOM nodes and throw away the persistent vector, only to repeat this entire process again on re-render.[2] > Helix has decided not to support that. That is simply not true. From the Helix documentation: "If yo
Read the rest
u want to use libraries like sablono, hicada or even hx hiccup parser, you can easily add that by creating a custom macro"[2]. These are all Hiccup interpreters you can readily use. IME there is very little difference between using the $ macro in Helix and writing Hiccup. I do not really miss Hiccup when I use Helix, and you still have data as code, the data is in a macro but that macro itself returns data...as code! ;) While this is from an unrelated project, there are benchmarks[3] done against Reagent that demonstrate the sheer overhead it has. In practice it is not a big problem if you rarely trigger a re-render, but otherwise it is a non-trivial cost, and if you want to use modern React features (like Suspense), there is a lot of r/as-element mingling going on, converting cases, etc. that simply make Reagent feel more tedious to use than Helix. Also, the newer UIx2, which largely borrows from Helix, is "3.2x faster than Reagent" according to one of the contributors.[4] I think it'd be worthwhile to benchmark all of these libraries against each other and record the data in one place. Maybe I'll get around to doing it this weekend :) --- [1] https://github.com/reagent-project/reagent/blob/master/doc/R... [2] https://github.com/lilactown/helix/blob/master/docs/faq.md#w... [3] https://github.com/roman01la/uix#benchmarks [4] https://github.com/pitch-io/uix/pull/12
In Introducing react.dev
> which still hasn't caught up to modern trends (static types, asynchronism, etc...) Ignoring the fact that your modern trends aren't modern. I don't think any of these statements really are true for Lisp as a family of languages: For example Racket has typed Racket. https://docs.racket-lang.org/ts-guide/ For asynchronicity Clojure has clojure.async https://github.com/clojure/core.async > and with a very poor tooling (lack of IDE's) Lisps have fantastic support in Emacs and VSCode and are in general simple enough languages that often the heavyweight of an IDE is not needed. But if you want IDEs there are: Dr. Racket - https://docs.racket-lang.org/drracket/index.html Cursive - https://cursive-ide.com/ Emacs/Cider - https://docs.cider.mx/cider/index.html > and library ecosystem (building websites, parallelism, GUI, etc...) Websites - Reagen
Read the rest
t, a ClojureScript wrapper for React https://github.com/reagent-project/reagent GUIs - Clojure has the entirety of Java to steal GUIs from - Ex: https://github.com/cljfx/cljfx Just because the Lisp family is old and has a simple syntax does not mean it's an antiquated language or that there are not new developments going on there.
In The Clojure Mindshare (2019)
If you're that pessimistic about your front-end code becoming obsolete, I'd strongly suggest looking into ClojureScript with https://github.com/reagent-project/reagent and (if you need SPA levels of coordinated state) https://github.com/day8/re-frame The up-front costs are certainly higher in terms of the learning curve for the average dev, but it sure beats rewriting the whole thing every few years. reagent dates back to 2013 and has been mostly unscathed by the JS ecosystem churn. I'm under the impression that some (JS-based) React devs catch on to reagent pretty quickly, so the up-front costs might not even be that high. Fantastic article, by the way!
In Django for Startup Founders: A better software architecture for SaaS startups
I keep seeing this line of reasoning that ClojureScript/Reagent somehow slipped behind React because of "hooks" and "form" (form is a new complaint actually, haven't heard before), but I'm failing to understand what hooks could give us in Reagent-land that we don't already have? With that said, you can still use React hooks via Reagent if you want to, it's described over here: https://github.com/reagent-project/reagent/blob/master/doc/R...
In Clojure from a Schemer's Perspective
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
This is getting better but unfortunately your best bet is still to read some examples of good open source projects. If you or anyone interested in some good starting places for good Clojure see: - https://github.com/gothinkster/clojurescript-reframe-realworld-example-app for a great webapp example - All of https://github.com/ztellman work but specifically: - https://github.com/ztellman/manifold for more advanced Clojure - https://github.com/reagent-project/reagent for interop with JS and advanced Clojurescript usage
In Clojure at Netflix (2013) [slides]

Showing the 15 most recent of 23 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.