To test the suitability of low-code UI solutions as science software frontends, I conducted an experiment with five frameworks:
Openblocks, 23/78/3.2k watch/fork/stars: to the report
Budibase, 199/965/16.4k: to the report
ToolJet, 116/1.4k/15.2k: to the report
Illa, 23/60/1.2k: to the report
Appsmith, 239/2k/22.8k: to the report
I tried to build a CSV editor, and made a simple paginated API query. Here come the results!
TL;DR:
It’s between Openblocks and Appsmith.
Summary
Budibase
First the obvious outlier. Budibase is more of a complete application builder than a light frontend builder. For my purposes, it has the wrong focus. For example, custom JS is quite limited.
Illa
Illa was presented only two weeks ago. Unfortunately, to me, it shows. I ran into too many problems and bugs while doing things that aren’t terribly complicated. In the end, I couldn’t make a simple GET query work. I believe this will be a good contender once the first issues are properly ironed out.
Openblocks
The first one I tried. Like Illa, very new. However, I was truly impressed. I didn’t run into any significant issues. I got the hang of it very quickly, and it took me less than an hour to almost finish my “project”. The only thing I am missing to complete the required functionality is a runtime configurable table component; it has already been promised by the devs quite soon. The focus is clearly on customizability; JS library import worked out of the box, which is still missing in much more mature competitors. I must admit that I’m somewhat partial: after things went quite well with Openblocks, I kind of looked for faults and missing features in other frameworks.
The biggest selling point for OB is the modularity, which I haven’t found in any of the other products: I can make and reuse parametrized components. The drawback is that it is behind Appsmith in maturity, so things like Git integration are still a future promise, and account management is minimal. My biggest worry is the unclear future, since there isn’t a clear business model yet.
Appsmith
The last one I tried, and the most mature (except Budibase). Correspondingly, I’m least worried about longevity, and features like Git integration give it a “premium” feel to it compared to the more barebones Openblocks. The only one that actually managed to complete my CSV editor task - even though I couldn’t actually use the nice built-in editable table for its intended purpose, because of (surprise!) issues with runtime column reconfiguration. It seems that this is a running theme, and it’s clear to me that I am somewhat bending the intended use case here.
Advantages: it’s clear that many issues have already been solved here, and the flexibility to do complex things is clearly available. Drawbacks: Despite my newly gained “experience” with the other frameworks, it took me terribly long to get seemingly trivial things working. This can be a sign that Appsmith forces you to do things right - the data flow in my AppSmith implementation was strikingly elegant compared to the hodgepodge I did with OB two weeks earlier, and I have to rework that one. (Update 2.12.22: I rewrote the OB component - much more elegant, less queries, clear data flow. Still waiting for the better table component though.)
Tooljet
ToolJet has been around for a while and I’ve toyed around with it before. There is nothing truly bad about it, but for me it ends up in clear third place. In points that matter to me, it doesn’t improve over Appsmith; plus I ran into some issues that are probably “me problems” but I couldn’t resolve. Neither does it offer the fancy new modularity from OB.
OB vs Appsmith
In the end I have no clear choice yet. With OB getting configurable tables soon (and Git integration later), and Appsmith getting JS libraries soon, the two will be almost on par feature-wise. I haven’t decided which approach to custom Javascript I prefer, with OB offering custom states to fill but Appsmith having a more “polyvalent” JavaScript module-like block. The modularity of OB is a true selling point for me, but probably it will be mere months before Appsmith gets the same at this point.
What I learned
This was a fun experience, although I sank more time into it than anticipated. Being a Javascript klutz, my way of doing things was probably somewhat adventurous. But interestingly, the {{bindings}}
style of programming is not so different from Shiny and has similar advantages and drawbacks: things become complicated when data flows get too “circular” and everything triggers everything. Therefore, the most important thing will be to devise the flow smartly with a limited number of states. The advantage vs Shiny is that I get a clear boundary between the backend and the frontend at my API (for example, typing something in a table doesn’t automatically rerun everything).
In summary, this has sufficient value for me to pursue further. Scientific software would really benefit from a de facto standard for this. It would be interesting to see whether perhaps some of the old Visualizer components can be reused or adapted.
Which low-code UI framework? Part 6: Summary
Hey, this is Vincent from the ILLA team, and thank you very much for using our product. I know that our product is at early stages and there will be many bugs, I'm happy to see you could write down feedbacks here. We will get them fixed shortly! We also fixed a few bugs you mentioned in this article, our newest version was released yesterday. You can check it out again if you like.