Elm-UI
Practically, any UI layout can be decomposed into a hierarchical structure of rows and columns. That was what I reassured myself, from e.g. looking at VS Code's UI. But don't most CSS frameworks provide rows and columns? What sets Elm-UI apart, however, is that it's utterly intuitive, and robust, "like Lego", as the author put it. In typical CSS frameworks, rows and columns are, as far as how my experience goes, mainly used for overall page layout, e.g. organizing blocks of content into some structure, but they aren't highly ergonomic to compose custom UI components; otherwise, it wouldn't be a selling point for such frameworks to also provide pre-made components such as forms, inputs, tags, etc.
Elm-UI feels very different to me, say, from Bulma (which I think are among the great CSS frameworks today), because it is meant for the user to custom-build things, instead of mainly offering ready-to-use UI components for prototyping convenience, or for projects that don't require design originality.
To be precise, it is definitely possible to do good work in CSS, after all, Elm-UI compiles to flexbox-based CSS, and Tailwind is doing something similar in concept, just without the FP backing of the Elm language (and not to mention readability). And the same argument applies to Elm vs. JavaScript. That is, if Elm/Elm-UI did not exist, and given that I want to do this kind of work regardless, then I'd still have to learn to do it in JS/CSS. But that is not the world we live in. Some good people created Elm and Elm-UI, and I'm fortunate enough to be picking my tools. We have the cryptic vs. the intuitive. Plus, I want to custom-build things. What am I going to do?
(The fact that the majority of developers are taking the suck-it-up path is a different topic.)
A clarification might be needed here: JS/CSS doesn't have to be hard, in fact they are probably among the most approachable languages. What we're comparing here is the intuitiveness and ergonomics given the same application complexity and standard of quality. For example, this static site is built with CSS (SCSS) and a little bit of JS, but to build Arrow and its UI in JS and CSS, having to achieving the same correctness, would be a pathological decision, given the universe (me included).
In Arrow v1, I've got the data modeling right, but only with the most basic features: data inputting and displaying, plus some simple stats. My goal with Arrow is two-fold:
- Easy data entry (so that users can keep using it, for Arrow is only of value from long-term usage),
- Useful data views (summarization, aggregation, and visualization, all for offering useful guidance on time management)
Plus the obvious prerequisite, i.e. total data ownership. So far, I'm pretty happy with goal #1, for I have been dogfooding since the very first working prototype and I don't feel burdened at all to keep entering data into Arrow. It has become highly habitual, and I don't consider this a frequent thing in my life.
However, goal #2 is far from accomplished. A major hindrance was the unintuitive nature of CSS when it comes to design complex custom UI components. I'm also big on code elegance, so even if something is achievable, I might reject the implementation if the code is hacky or patchy (it's not just aesthetics, I believe such inelegance also leads to fragile, unpredictable software). Now with Elm-UI, I feel that this changes the outlook drastically.
Now initially, I postponed trying it out and instead worked with CSS frameworks, but I think it was a good call: I was new to Elm back then, so adding ELm-UI onto my plate could be overwhelming. Given the relative abundance of learning resources based on plain elm/html and CSS, I decided to go with the common learning path to get things going. Moreover, as I mentioned before, hands-on experience with well-made CSS frameworks is a necessary step toward making custom designs with Elm-UI.
My first exploration of Elm-UI started December 2020. I was initially worried that it might be too young to be "production-ready". Sure, I guess it has bugs, but from actual use, I feel confident that it is already complete and robust enough for my need with Arrow!
In January, I set out to try building some custom (yet common) UI components by just using rows and columns:
- Compound input field where tag-like entries already staged are displayed inline alongside the input
- Bidirection sortable table
- Overlay panel, toggled by a button in header (similar in concept to a window toggled by a taskbar button)
- Bar graph-like visualization in a vertical list to give an intuitive comparison of quantities
Although these are fairly basic components, it is a significant morale boost to see that with Elm-UI, their implementation can be truly intuitive and elegant. In particular, once you finish your first draft, subsequent tweaks and revisions can be done highly reliably, and they work everywhere in your UI (namely the functional nature). This shows that Elm-UI is not only ergonomic and productive, but satisfyingly robust.
February was vacation, so coding went into light mode. I dedicated the reduced hours to porting v1 UI functionality to v2. Although it's not 100% done, the experience was good, in that I got to know what it was like to do this work of translating elm/html into Elm-UI. Frankly it wasn't the most exciting part of the project, but it's quite manageable and I found ways to improve the design along the way.
When I realized that the end of the month was approaching, I could have rushed and pushed it to get all the features ported (so that I could start dogfooding on the v2 UI sooner). But I decided not to chase that goal. I chose to enjoy some relaxational fun instead. I figured it's probably better to take time and incorporate more improvements and refinements in the course of porting the remaining parts. So that's for March.