Why we are moving away from Om (and how we decided on our new front-end tech stack)

Peter Lubell-Doughtie

December 17, 2018

We recently evaluated the future of our front-end stack. The changes we decided on did not come easy, but we figured it out and wrote this article to walk you through the factors influencing our decision — and explore the directions we could have gone. Our hope is you can benefit from the research we did in case you are choosing or switching the front-end framework for your web application.

Don’t use stagnant libraries

In 2014, we split the original codebase of our data management and collection platform into a backend API, which is the open source OnaData, and a presentation layer web application written in Clojure and ClojureScript, codenamed Zebra. We wrote the front-end of Zebra in Om, a ClojureScript interface to React. At the time, Om had a great community and was actively developed, so we judged it to be the most well supported and conceptually sound React wrapper.

The downside of choosing Om was its steep learning curve, especially if the Om-newbie is also a React-newbie (which we were). But in return for climbing that learning curve, we benefited from well written and maintainable code. We thought — and we still think — this is a worthwhile trade-off. Of course, four years later the situation has changed dramatically. The version of Om we used is no longer being updated and in fact it’s stuck on a much older version of React, version 0.13.3.

When we chose Om, we felt it was essential to use a library in active development and we think it’s even more important today with the rapid change occurring in front-end frameworks. Thus we have to change up our front-end framework. An added benefit of migrating is it provides us an avenue to transition what is now server-side functionality to the client-side. We want to commit more fully to a single-page-application (SPA) and can only do so if we are building on top of a solid foundation that we expect to have a bright future.

Review frameworks that will still be familiar

There are many active front-end frameworks, but we only looked at a select few based on our preferences and experiences. Because of our pre-existing React code, and our team’s knowledge of React, at this time we don’t think that the benefits of non-React frameworks outweigh the switching costs, and have chosen to stick with a React-based framework. This eliminated Vue.JS and Angular. The remaining options we considered are: OmNext, Reagent / re-frame, or leaving ClojureScript and using React / Redux in JavaScript. We listed out each framework’s pros and cons, thinking about our team’s experience and needs:

OmNext

Pros

Different from, but still closest to the current code
Team deeply familiar with the predecessor, Om

Cons

OmNext has been in Alpha or Beta for a long time and, based on github commits, it is not actively developed
Learning curve for OmNext is steep and it deviates significantly from Om

Reagent / re-frame

Pros

Active community and code-base
Can easily use React components
Known for being easy to learn

Cons

Lack of familiarity, we’ve only explored the library in prototypes and testing
We can’t use the re-frame state-management system with Gisida, an open source library we maintain and want to integrate with

React / Redux

Pros

Team is familiar with running production applications in React
Very large React community

Cons

Harder to use CLJC code / We can’t use JavaScript code in Clojure
We don’t benefit from the team’s knowledge of ClojureScript
Would need to rewrite tooling to accommodate deeper integration with JavaScript

Make a decision that will fit into your roadmap

We selected Reagent / re-frame. Here’s our thought process:

Since the main reason we’re switching from the Om framework is deprecation, we felt it was important the new library have an active community, a team committed to it, and active code development. We do not see this with OmNext so it was ruled out.

It was also clear we wanted to continue taking advantage of our ClojureScript experience, the benefits of using a LISP, and the amazing Clojure community. Reagent has a growing and active community and we are able to formulate a plan to use Reagent / re-frame with our existing JavaScript libraries written using React / Redux.

Specifically, it’s important we have a plan to integrate Gisida, our map presentation library. The main challenge with integration is because Gisida is written using React/Redux, the React piece is tightly-coupled with Redux for state management, and the Redux and re-frame state managers do not appear to be compatible. However, we can isolate a part of our front-end code for map visualizations and have that use Gisida.

We know that our specific analysis is unique to Ona. Our background in Clojure and our existing React / Redux libraries are unique and impose specific constraints on our options. However, we hope you can learn from our approach to choosing a library.