I used Reagent for a fairly significant frontend project last year. It was a real joy to work with. The maintainer, yogthos, is very responsive to feedback and is doing a great job shepherding the project. I'm looking forward to the opportunity to use it again soon. Simplicity at its finest.
I have used reframe to great success, as well as vanilla reagent. I've currently switched to om-next for a variety of reasons.
I have my concerns about om-next, but overall since I'm writing a complex side-project, it's worth it. If I had to ship something tomorrow, I'd go with reagent still, but for longer projects where you can spend more time and get over some learning curve and alpha/beta type bugs, om-next is a good fit for large projects. I found reframe to be generally the best way of working with reagent, but not as good when I had lots of chained events and complex queries. I spent a lot of time optimizing around some ways that reagent/reframe does things where as in om-next, I could tweak things more to my needs. Om-next also offers some additional features many people don't need, but fit my use-cases well (ex: server-story, pulling only what you need, normalizing client app db data).
To summarize, reframe is a nice framework and really great for small projects or projects that need to ship today. It works and is the best approach I've seen on top of reagent (and react). Om-next is good for people that can afford to take some risks and have complex requirements but still want a proper framework on top of react. Om-next will make you do a lot more work up-front and has a lot more ceremony, but there is a reason it exists. Generally, I have found om-next powerful once you are able to grasp the way it wants you to do things. For people who want something like reframe like om-next, there is the "untangled" framework. Anyway, I wouldn't recommend om-next or reframe/reagent over the other, rather I'd suggest either and match your requirements accordingly.
I started a prototype project first to try it out and used Datomic. With Datomic, most things are entierly automatic.
In the second, I'm using a bit of Datomic mainly to save UI-related and small bits of user state. Mainly I use Cassandra, Redis, Kafka, and Elasticsearch. I should add in this project, I'm also using untangled.
I communicate a lot over websockets as well, so between that and Cassandra I have to do a lot of mapping and transformations on my own, however once you get it setup the rest is mostly magic. Most of my reads and writes over the socket are happening with consumers and producers to Kafka so mapping om-next data here is just standard Clojure, nothing fancy.
When I do query Cassandra directly, the queries in particular by nature need to be somewhat restrictive which it turns out play nicely with om-next since mostly for reads I just need to worry about the "select" columns. Redis I just use for LRU caching and to buffer some video-like blocks of data before the user tries to access them. Elasticsearch is just used for searches and some type of filtering, but gets populated through Cassandra data anyway so again no problem with om-next.
I'd say the most annoying thing here was as I hinted, getting it all setup. Things are clearly built for Datomic, but there are integration points all over the place and just using standard functions in Clojure to manipulate vectors and maps is easy. If you're not experienced with datalog or datomic pull syntax, things might be a bit harder at the start for some people.
Regarding API calls, I should add since I am using untangled, I use the default websocket lib which is just sente. I have rigged things up with aleph and yada, but also played around with standard compojure api and other offerings. Long-term I'd like to stick with yada, but I've encountered some documented bugs that are annoying so I've put my focus elsewhere in the short-term when needed.
if I may ask a dumb question : do experienced javascript programmers become more or less productive when they switch to Clojurescript or ELM or other js transpiling languages ?
I think it depends on what your expectations are as well as what you are willing to put into learning them. Both Clojurescript and Elm have their place.
Elm is very nice but definitely has a learning curve. You can try Elm in a low impact way by making a small component with it and using it alongside either React or Angular ( or in other scenarios as well ). It can also work as a state management solution for parts of your front end app. On the other hand building an entire SPA in Elm is a monumental task and requires significant investment. As the Elm experts say Elm is not really a good solution for quick one offs or prototyping. It may require you to reinvent the wheel for many widgets for which you could find relatively high quality open source options in React or Angular. Also, Elms JS interop is a bit tedious at times but works relatively well.
Clojurescript has been around longer then Elm and for most has less of a learning curve, but for some the JVM tooling may be a turn off. Nonetheless it is fun to use and there are several Clojurescript UI libraries (Rum, Reagent, Om, Hoplon/Javelin) all of which are used in production at various places.
I would say for an experienced javascript developer there is something to gain by delving into either Elm or Clojurescript and though both are very different the strong functional emphasis of both imparts habits of code organization and thinking that you might not develop as easily by staying in pure Javascript territory.
I suspect that in the short term the answer would be no, because of the initial learning curve. In the long run I think that it depends on the kind of project they are working on. Something like clojurescript would be a bit of heavyweight solution for really simple javascript enhancements. I suspect that productivity improvements of learning a transpiled language are similar to the improvements of learning a new javascript framework like React or Angular. They offer a learning curve in exchange eventually for a simplified programming model.
- creating a project from scratch is easy: lein new reagent-frontend my-project. it creates a project from reagent-frontend template. you can build your app with lein cljsbuild auto or build a production build with lein release.
- build time significantly drops, even with advanced optimizations, comparing to webpack.
- both component and app state management becomes a lot easier thanks to reagent atoms.
- not much of a big deal but hiccup templates make inline styling easier.
Much more productive after the initial learning curve as some said. It's pretty easy to call standard js from Clojurescript which makes things play well.
I find having the syntax, tools, and power of Clojure to be a much better experience than using vanilla js. There are so many things that just work, and having immutable data structures as the default is a plus, and a huge win. Further, I find that it makes things a lot easier to use with the backend, especially if it is also Clojure.
As far as working with the backend, I often am able to rename a clj file to cljs and it just works. I can also share the same exact code literally and insert the occasional reader conditional and cljc file. This is a huge win as well given both Clojure and Clojurescript encourage data-first approaches. Most of my code tends to be just maps, sets, lists, and vectors, with the occasional custom data structure. Sending this back and forth between client and server is infinitely easier and nicer than vanilla js. Adding things like EDN, transit, and libs that are built for dual use in Clojure and Clojurescript save a ton of time here as well.
Regarding tools, I find if you just use decent emacs plugins or an IDE like IntelliJ with the Cursive plugin, the syntax checking and dev experience is great. I tend to do a lot in the REPL which I feel is a productivity win for me over just working in chrome dev tools alone or some other js tools. Figwheel for example is another great one I use for doing hot code reloads/side-by-side changes.
For more specific and complex cases, I get even more benefit using reactjs from Clojurescript. There are multiple good frameworks in cljs that simplify the react experience and in some cases, even makes it run a bit faster (unless you replicated more or less the same immutable experience from js).
As for bad things, here's a few worth noting:
- Initial project setup can be a lot more of a pain, especially with lein. Boot can be an improvement but isn't as widely supported and doesn't always makes things easier. The larger point is there is a lot of ceremony getting new projects setup for non-trivial things. For trivial things, lein templates and various git repos make it quick.
- Some situations using vanilla js arrays can lead to better performance. It just depends because the opposite can be true. In both Clojure and Clojurescript I use transients where possible for a slight boost in some use-cases.
- Debugging can be a bit of a pain at times if you really have something deep. Since most things are data though, I don't really care that much as I normally solve problems using the REPL and/or dumping app state. In reagent and other frameworks, you tend to have a single atom i.e. source of truth which makes it easier than most typical approaches in js.
- Every once in awhile I hit something weird in Google Closure or a weird bug with Clojurescript itself. These tend to get fixed though and it's not hard to reach the actual devs.
- Clojurescript tends to make me hate using non-Clojurescript libraries. Interfacing is not difficult, rather the quality bar and extra dependencies that many npm projects pull in just make me insane. It's more of a personal and elitist thing that happens to a lot of people I know who use Cljs, but not really a problem, just pointing it out.
As a whole, I feel like Clojurescript makes Javascript not suck so bad. I know a lot of people love js, and I've been using it since the beginning. It sucks and is a horrible language, but we're stuck with it. Fortunately Clojurescript and Elm are at least ways of making the experience less bad. The biggest criticism is any time you get into transpiling or further from an original language, there are always a few places where things leak or become more confusing, but I'd say given js in general, it's worth it for a solid set of libraries that just work and the dev experience that goes with it.
