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
- Different from, but still closest to the current code
- Team deeply familiar with the predecessor, Om
- 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
- Active community and code-base
- Can easily use React components
- Known for being easy to learn
- 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
- Team is familiar with running production applications in React
- Very large React community
- We don’t benefit from the team’s knowledge of ClojureScript
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.
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.