
The Re-Frame Guide: Front-End Architecture in Clojure - kimi
https://purelyfunctional.tv/guide/re-frame-building-blocks/
======
preek
At Collecture.io, we love re-frame about as much as we love Clojure and
Emacs^^

Thanks to re-frame we have exactly the same logical FRP abstraction and Code
in our Android, iOS and Web Application.

It's a great framework to work with - can only recommend it. That is, if your
application has a minimum in complexity. Because otherwise Reagent with a
global atom will work just fine and be a lot less complicated. So don't
introduce it when working on your first CLJS code base. Similarly you probably
don't need Redux to your React in your first JS SPA.

~~~
zkim
Are you using any Clojure in your mobile apps, or mainly on your web
properties?

------
yomly
Would love to know people's experiences of using Reframe in production.

Is the additional structure it imposes on the app worth the complexity it adds
in learning the framework?

~~~
yogthos
My team switched to re-frame after about 6 months development, and our only
regret is that we didn't do it sooner. It took about a week to switch over,
and caused minimal friction. The complexity it introduces is minimal, but it
makes things more predictable when it comes to rendering, and it goes a long
way to help with organization.

The big advantage of using re-frame in my opinion is that it provides really
clean MVC semantics for Reagent. All the changes to the model go through
controllers created with reg-event-db, and then the view observes the model
via reg-sub subscriptions. With this approach, you can easily tell how the
events update the model and interact with each other because they're all in
one place.

You can see a real world app using re-frame here
[https://github.com/yogthos/memory-hole](https://github.com/yogthos/memory-
hole) and I don't think it's any more complex than it would've been using
plain Reagent.

~~~
prodtorok
How much Clojure was the team exposed to before the switch?

~~~
yogthos
My team has been using Clojure for about 6 years now, but we only started
introducing ClojureScript last year. Figwheel and Reagent workflow was what
sold us on it.

~~~
likeclockwork
I notice that you recommend figwheel a lot, I wanted to ask you: Have you ever
tried the boot tooling (boot-cljs, boot-cljs-repl, and boot-reload) and if so
do you have any opinion on it vs leiningen+figwheel?

So far I've personally found boot a lot easier to work with than leiningen and
the cljs repl is easier to get going and integrated with CIDER.

~~~
yogthos
I have very little experience using boot. The main benefit of Figwheel is that
it allows you to retain the state while hot loading code. I find this makes a
really big difference when working on complex UIs. I can get the application
in a particular state, and then tweak the UI in that context.

There's a [https://github.com/boot-clj/boot-
figreload](https://github.com/boot-clj/boot-figreload) plugin that adapts
Figwheel for boot, but I haven't used it myself.

~~~
likeclockwork
Ah, I was just wondering if you had experience there.

boot-reload[0] replicates everything figwheel does in terms of hot reloading
the cljs. I started using boot because I wanted better tooling for cljs, which
I think it provides. I wanted to ask if you had any experience with it because
I know you have a lot of experience with cljs and was wondering if you had any
insight into potential hidden costs.

I agree that hot reloading is a huge upgrade over the old workflow, it saves
so much time.

0: [https://github.com/adzerk-oss/boot-reload](https://github.com/adzerk-
oss/boot-reload)

~~~
yogthos
Ah I see, and yeah I haven't really used boot since I already got comfortable
with lein by the time it came out. It sounds like they both work pretty well
nowadays though.

------
akhilcacharya
The best re-frame guide I've seen so far.

------
napsterbr
I've been using elm in production and it's been a great experience. I've never
heard of re-frame (and never used cljs); could someone with knowledge on both
give me a quick comparison between elm and re-frame?

~~~
hellofunk
One notable difference between Elm and Clojurescript in general is that Elm
has very limited interaction with the whole front end ecosystem, where as in
Clojurescript you can do anything that the JavaScript guys could do. Elm's
ports don't really do much in that area. Clojurescript respects developers to
access all the power that browsers can offer you, if you want it.

Another big difference is that Clojurescript can be passed through advanced
optimizations, but Elm does not support those. But in Clojurescript, most
projects are already setup for optimization out of the box. This is the same
optimization that Google uses for all of its services such as Gmail,
Google.com, etc. And it is industry-leading.

The final notable difference is that most work in Clojurescript uses figwheel,
which greatly accelerates front end development with it's automatic reloading
of what you work on as you save it, as well as other information it provides.
Elm has attempted something similar, but it's quite limited and doesn't
support a lot of the complex stuff you might want to do in Elm, and Elm's
documentation says only to use it for basic tasks.

There is also the re-frisk tool for re-frame which gives you super easy visual
inspection of your entire application state in a graphical tree, quite useful.

All that said, Elm as a language is very attractive. But as an advanced
development platform, it doesn't go nearly far enough. Perhaps one day it
will.

