Why Re-frame instead of Om Next

Build your SPA in ClojureScript!

Master Reagent and Re-frame with my ClojureScript Frontend Signature Course.

• 3 frontend modules
• 72 detailed lessons
• 19 hours of video

buy now

When I first announced that I was producing a course about Re-frame, I inevitably got lots of questions about why I chose Re-frame and not Om Next. It's a good question. These two ClojureScript frameworks both have their merits. There were some practical decisions, like Om Next being in Alpha for two years. But in the end, Re-frame is easier to work with, it is easier to learn, and it captures the difficult parts of making an application without overcomplicating it.

Re-frame is a front end framework created by Mike Thompson. It takes care of DOM rendering, application state management, and it has some building blocks useful for other effects like communicating with the backend. Om Next, created by David Nolen, is similar, except that it has a grander vision about client/server communication. It's ambition is to unify the model of data on the client and server to reduce the number of queries the client runs which will make applications faster, especially on mobile.

Like I said before, the two frameworks are very similar. However, I had to choose one. Making courses about both would have diluted my attention. I wound up teaching Re-frame and I am very happy with the choice. So why did I do it?

People have been asking me to teach Om Next for two years. As soon as I announced my original Om course Single Page Applications with ClojureScript and Om, Om Next was announced. People were already asking whether it would teach Om Next and when the Om Next version would be available. My answer at that time was simple: it won't teach Om Next and I won't update it. Om Next is different enough that it needs its own course. However, Om Next was released as Alpha at that time. I've been burned before making a course and having the material change out from under me. My answer to people asking when I would make an Om Next course was "not before it comes out of Alpha".

That was nearly two years ago. Om Next, when I started my Re-frame course, was still in Alpha. As I write this, it went into Beta1 two months ago. I know a lot of companies use it in production already. But there is so much out there for me to teach that doesn't have a label of volatility. I cannot afford to make a course that might not work in six months.

Meanwhile, I was very interested in Om Next and I wanted to learn it. I watched David Nolen's talks. I went through the tutorial a few times. I made a small application. I got on Slack. I read Tony Kay's excellent interactive tutorial. Even with all of that, and understanding the individual pieces, I can never say that I fully understood what was going on. I wrote a small application in it and it felt like threading a needle. There were so many things I had to get perfect or they wouldn't line up as neatly as promised. I felt like at any moment I might violate some implicit assumption about how my data should be shaped or what the query DSL could do.

I knew I would have to get a handle on this to be able to make it teachable, and I didn't feel like I could in a reasonable amount of time and effort. Teachability is a huge part of designing a framework. It is probably as important as capability. I would have to invent an onramp to get people started with Om Next. In short, I'd have to create a mental framework to use the actual framework with. In the end, this was my biggest beef with it. It has too many degrees of freedom.

Meanwhile, during my struggles with Om Next, I discovered Re-frame. Re-frame felt aggressive. The README was long and dense and opinionated, not to mention stylistically eccentric (it has been toned down since). There were all of these parts to it, and it came from someone I had never heard of, and plus it was built on Reagent, which I thought was neat but not as robust as Om. One day I decided to record a Clojure in One Hour lesson about it. I hadn't done anything more than read the README when I attempted my first project. It was fun and I got something working. Plus, I understood it and could see how to teach it.

Re-frame does not do all that Om Next does. Om Next has a concept of database entities, it will de-duplicate them and build indexes for you. It has a query language that specifies what data each component needs. And much more.

Re-frame embodies my #1 reason for using a framework: it is a process for turning ideas into code. It's a mental framework as much as a code framework. You get a handful of useful pieces so you can divide up the problem and fit them into the application. Those pieces easily map to the parts of you should be familiar with as a functional programmer. Each part is there for a reason and makes the system better.

I'm going to write this process up more fully (update: here it is), but here's a small example of what I'm talking about. Let's say we want to make a button that increments a count. We also want to display that count.

What are the UI elements?

UI elements go in Re-frame Components.

We need a button and a display of the count. Let's call the Components increment-button and count-display.

What UI events do we need to capture?

UI events should be captured as Re-frame Events.

The button can be clicked. Let's call the event :increment-count.

What application state do we need to store and modify?

Application state changes go in Event handlers.

We need to store the count in application state, and increment it whenever the :increment-count Event is handled.

What application state do we need to read to build our UI?

Read-only access to application state is done using Subscriptions.

Our count-display needs to read the current count, so we make a subscription for that and subscribe in the component.

We mount those components into the UI and it works.

Notice the mental framework: each question leads directly to a piece of code. Building applications is already complex enough. You want something to give you a place for the things you need. So here's the strong statement I'm going to make regarding Re-frame:

Re-frame gives you just the right amount of structure you want when building a frontend application. The structure it gives you is easy to learn.

Conclusions

Om Next has a lot of cool capabilities. You should at least watch the talks and give the Quick Start a shot. It might be just what you need, or you might like the freedom and potential it gives you. If that's you, go for it. I think it's a cool system with a great philosophy. If you're starting a new frontend and backend from scratch, do check out Fulcro, which does provide much more ready-made structure so you can take advantage of Om Next's capabilities.

However, I think Re-frame is a great choice for most people. It gives you 90% of what you need plus a place to put the last 10%. It's powerful, teachable, and it has a large and growing community. I'm still happy with my choice and I invite you to learn Re-frame with me. I've already got two courses about it. The first is called Building Re-frame Components which dives into the nitty-gritty of making custom UI components in Re-frame. The second is called Understanding Re-frame which gives you a deep understanding of the whole Re-frame stack, from React, to Reagent, and finally all of the parts of Re-frame.

More posts in this Re-frame Series

• State in Re-frame
• The Re-frame Building Blocks Guide
• Guide to Reagent
• React Lifecycle for Re-frame
• Database Structure in Re-frame
• Re-frame, a Visual Explanation
• Optimistic Update in Re-frame
• Timeout Effect in Re-frame
• Why Re-frame instead of Om Next ← you are here
• 6 things Reacters do that Re-framers avoid