Live data from Hacker News

A deep dive into ClojureScript reagent

timothypratley.blogspot.com

11–20 of 20 posts

Re: A deep dive into ClojureScript reagent

#11
post #2

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.

Yogthos (Dimitri) is the best, he's always helping people out on Reddit and Slack and his books and blogs are pretty helpful as well.

He's actually fairly representative of the clojure community in that respect, which is just another reason it's a pleasure to develop in.

Re: A deep dive into ClojureScript reagent

#13

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 became much less productive when I first switched to cljs but after a few projects I could prototype things fairly quickly.

Of course even today I miss out on react components on npm (having to first port them to cljsjs) which is a source of slowdown for me personally.

Re: A deep dive into ClojureScript reagent

#14

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 ?

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.

Re: A deep dive into ClojureScript reagent

#15
post #6

As a very nice complement to reagent, I'd also like to mention re-frame: A Reagent Framework For Writing SPAs, in Clojurescript. https://github.com/Day8/re-frame

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.

Re: A deep dive into ClojureScript reagent

#16
post #6

As a very nice complement to reagent, I'd also like to mention re-frame: A Reagent Framework For Writing SPAs, in Clojurescript. https://github.com/Day8/re-frame

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…

What backend are you using with om/next? How are you making those api calls?

Re: A deep dive into ClojureScript reagent

#17
post #5

I'm the author of the klipse[1] plugin. Timothy impressed me with the quality of his klipse interactive snippets in this mind-blowing article. 1: https://github.com/viebel/klipse

Never heard of klipse, amazing thing.

Saw the presentation in ClojuTre in Tampere last year. It's a great idea, but a tad slow when injected a lot onto the page.

Re: A deep dive into ClojureScript reagent

#18

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 ?

here is my experience:

- 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.

- you get figwheel! [0] [1]

[0] https://github.com/bhauman/lein-figwheel/ [1] https://www.youtube.com/watch?v=j-kj2qwJa_E

Re: A deep dive into ClojureScript reagent

#19

Earlier quoted context omitted.

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…

What backend are you using with om/next? How are you making those api calls?

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.

Post reply on HN