The low-code/no-code frontend market is hot right now. We are getting an “open-source alternative to Retool” post on Hackernews almost every day. For context, Retool is the best-known drag&drop reactive UI builder. It allows to rapidly build a front end with limited amounts of JavaScript, interfacing to REST APIs, databases and all other kinds of cloud integrations.
Low-code UI builders are an attractive proposition for scientific software. For one, scientists who publish tools/software are typically one-man teams, usually have very limited time to devote to frontend development, and not much experience in the field. On the other hand, we don’t need the polish of finetuned UIs. What would be called a “prototype” or “internal tool” in other areas, is often perfectly acceptable scientific software for “the masses”.
Shiny for R, and Dash for Python, have become UI workhorses in the data science / science software areas. I love Shiny. It has a very low entry barrier; it is perfect for interactive visualization, but beyond that can be used, extended, bent and twisted to do almost everything you can imagine. Shiny is kind of a React for R, in that you bind input widgets to data that auto-reprocesses dependent code and generates the output. However, 1) it really doesn’t favor disentangling your business logic from the visualization/UI, and 2) when feedback loops and customization are involved, you reach a point where most of your code is trying to work around Shiny’s reactive logic.
Because I tend to reach this level quite quickly, I decided to try an alternative approach for this project: expose functionality as API, and build the frontend with a low-code framework. This should serve as a pilot to answer the following questions:
Can I build a science software frontend in low-code without running into limitations of the framework?
Which one should I use?
Is this better than using Shiny for this purpose?