seancorfield 2021-01-01T01:02:26.063200Z

I've decided to finally come back to ClojureScript (last time I looked at it was 2014) and after some suggestions from folks in other channels here, I got started on Tuesday with figwheel-main and re-frame (I'd previously used an early version of Reagent and I think re-frame came out after I'd given up on ClojureScript?). It's all going pretty smoothly, in terms of learning (the docs are great; I started with figwheel's template with Reagent, then added re-frame and converted the code to use that... took me about an hour to figure out how to run auto-testing in one browser tab with the app in another tab, and to work between VS Code and the REPL to experiment and learn). I noticed there's a re-frame-test project that talks about running tests on both JVM and cljs ... which was when I first noticed that re-frame is almost all .cljc files (aside from the interop ns). So that made me curious... is it actually feasible to write JVM-based Clojure apps using re-frame on the server? interop.clj has lots of caveats, including a note about tests doing extra work because of the naive way make-reaction is written). So, is it practical to write server-side code with re-frame? If anyone has done that, I'd be curious to know how you get at the "results" since the view rendering stuff is an infinite loop and it just side-effects stuff into the DOM.

phronmophobic 2021-01-01T09:29:12.092400Z

I assume "JVM-based Clojure apps" refers to web apps, but re-frame can technically be used to build desktop and terminal apps,

seancorfield 2021-01-01T17:52:07.092700Z

Nice! Thanks @smith.adriane


@seancorfield You might also be interested in the official re-frame template which uses shadow-clj and supports Calva (unless you are 100% committed to figwheel) Regarding re-frame-test , a local Australian company was very keen on the idea, and did much of that work, and we thought it seemed like a good idea, so we made changes to accommodate it (like moving to .`cljc`), but we never used it ourselves. Because of politics, the local company was soon after forced to use Angular or something, so they never really went on with it. So, I'm left slightly unsure of its status. At one point, it was certainly sufficient that they were no longer asking us for changes. Anyway, I'll be interested to hear how you go with it.

seancorfield 2021-01-01T02:16:30.071800Z

Based on my experiences with Figwheel this week and Shadow-cljs a while back (when I was hacking on Chlorine for Atom), I think I'd rather stick with Figwheel, and I don't use Calva -- I use Clover for VS Code.

seancorfield 2021-01-01T02:17:37.073Z

I'll probably create a basic app from the re-frame-template and merge the relevant bits into/over a basic reagent/figwheel app when I'm ready to actually build something "real"...


@ re-frame-10x doesn't yet work with Reagent 1.0.0 We'll make that happen in the next few weeks.

seancorfield 2021-01-01T02:19:28.074400Z

@mikethompson That re-frame-template looks like it requires Leiningen? (at least it only seems to contain project.clj)




Uses Lein

seancorfield 2021-01-01T02:20:38.075800Z

I haven't used lein for years (except when helping beginners with problems here on Slack) πŸ™‚


You calling me a Dinosaur?


I think you are



seancorfield 2021-01-01T02:22:27.077100Z

Only if it takes one to know one πŸ¦–

seancorfield 2021-01-01T02:24:00.078800Z

When I was looking at Shadow earlier in the week, it also looks very node-focused and I don't want to install node and all that nonsense on my laptop for cljs stuff πŸ™‚ Someone said it can be used as a library but the docs seems a bit thin on that, which is another reason for me to stick with Figwheel at this point πŸ™‚

seancorfield 2021-01-01T02:26:10.081200Z

(I do have node etc on my desktop from back when I was using Shadow-cljs to hack on Chlorine... but I really don't like JS/node...)


If you want to use React components (javascript ones), then Shadow-clj used to be the best choice by far. Having said that, I know that Bruce Hauman did a lot with figwheel about 6 months ago, so perhaps it got back to parity

seancorfield 2021-01-01T02:27:44.083200Z

I'm trying to completely avoid JS but we'll see how that goes. Others on my team are heavily into JS/React so they may well start recommending React components to solve problems that I may have building something with re-frame.

seancorfield 2021-01-01T02:28:33.084700Z

(I did see some sort of "npm bundles" option for figwheel's template so...)

clyfe 2021-01-01T02:29:05.085200Z

I find figwheel pretty great, and it stays close to cljs cli, basically one writes "figwheel.main" instead "cljs.main", some extra opts aside

clyfe 2021-01-01T02:30:00.087100Z

some issues on logging and reporting errors, but I think that's more on cljs than fig




Yeah, I'm a little out of the loop

seancorfield 2021-01-01T02:30:34.088100Z

Re: server-side re-frame -- interesting history and good to know that it may be "unknown" in status at this point. I may have a play and see what I think.


I would be interested to know if the re-frame model’s viability on the backend: it would be nice to transpose the same philosophy for backends with a central global variable and event dispatchers. The killer feature of re-frame would always be 10x for me. It just makes the state tangible.

phronmophobic 2021-01-01T09:29:12.092400Z

I assume "JVM-based Clojure apps" refers to web apps, but re-frame can technically be used to build desktop and terminal apps,

seancorfield 2021-01-01T17:52:07.092700Z

Nice! Thanks @smith.adriane

clyfe 2021-01-01T19:04:35.093100Z

I made some slides on my little project:

emccue 2021-01-01T19:39:52.094Z

@neo2551 It would be viable but only for a kind of backend that is fairly rare - complex state maintained per connection

emccue 2021-01-01T19:40:59.095400Z

essentially if the state of the frontend was persisted on the backend

emccue 2021-01-01T19:41:17.096Z

pheonix live-view type stuff

emccue 2021-01-01T19:41:34.096600Z

but at that point it is kinda just an actor system

seancorfield 2021-01-01T19:41:36.096700Z

I spent several hours last night playing with re-frame on the JVM and I can see it being very useful in some situations but maybe making most server-side stuff unnecessarily weird/complicated πŸ™‚

phronmophobic 2021-01-01T19:42:47.098200Z

what kind of things were you doing with re-frame on the JVM?

seancorfield 2021-01-01T19:43:09.098900Z

(partly because re-frame seems to suit a continuous process that updates an external "system" but it doesn't feel as good a fit for discrete request/response stuff like a web app)

seancorfield 2021-01-01T19:45:28.101700Z

@smith.adriane Nothing specific really -- just kind of exploring what sort of app model is possible with that architecture. It seems hard to wrangle an "end" state onto something spawned via rf/dispatch and most stuff I actually build on the server is discrete. That said, we do have some continuous processes running at work that might be very suitable for a re-frame style workflow...

emccue 2021-01-01T19:46:39.102600Z

that being said, i've been thrust back into re-frame for work after focusing mostly on elm since 2016-17

emccue 2021-01-01T19:47:11.103400Z

so i am trying to figure out "what is going on" at the same time as figuring out how to feel about the whole thing


I like the separation of events definition and dispatch


It forces to have some kind of queue.

clyfe 2021-01-01T19:55:10.105900Z

I could be heading there with Tape Framework. "Isomorphic" (don't like the word but that's what frontend folks call it). All the pieces seem to support both browser and server (reagent, re-frame, reitit). The trick is some conventions: - all event dispatches originating in the UI are via router - keep app-db very lightweight (as in each event sets it anew). - maybe special treatment for (:session @app-db) Something along those lines. But I don't know if it's a real value add If you squint at a and it looks like Rails.