What does HackerNews think of reagent?
A minimalistic ClojureScript interface to React.js
No affiliation, happy user for years.
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 - Reagent, 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.
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!
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. Our 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.
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 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 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 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 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 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. - 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 lein new figwheel
Like the sibling comment pointed out, Reagent uses Hiccup-style data structures to represent HTML. Om can be configured to do the same, but doesn't out of the box last time I checked. Either way, the Hiccup syntax looks like this:
[:div [:h1 "Hello world"]]
Add either Reagent or Om to your project.clj, and off you go.
[1]: https://github.com/bhauman/lein-figwheel
The least bad stack I've ever used is Reagent ( https://github.com/reagent-project/reagent ) - a Clojurescript library for React. Perhaps that's just _adding_ layers of hackery, but I found it made sense.
[1] https://github.com/omcljs/om [2] https://github.com/reagent-project/reagent