This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-07-08
Channels
- # aleph (10)
- # announcements (2)
- # babashka (1)
- # beginners (22)
- # biff (5)
- # calva (1)
- # clj-kondo (46)
- # clj-on-windows (7)
- # clojure (88)
- # clojure-denver (12)
- # clojure-europe (41)
- # clojure-losangeles (1)
- # clojure-norway (6)
- # clojurescript (5)
- # conjure (4)
- # fulcro (13)
- # humbleui (1)
- # hyperfiddle (70)
- # jobs (5)
- # juxt (1)
- # meander (12)
- # off-topic (42)
- # practicalli (6)
- # releases (2)
- # shadow-cljs (12)
- # tools-deps (1)
I have been thinking for a while about when Fulcro is a good choice, and when not. So far I have come to this: Yes: UI-driven, non-trivial, likely full-stack apps No: • Trivial apps (⇒ use e.g. Helix) • Backend-driven apps (BE decides the data 🌲 to be displayed) • Very simple data • Extremely dynamic UI (no fixed UI ↔️ query tree) • Very heavy integration with JS higher-order components (use JS!) WDYT?
I have no exact definition 😅
10 years ago I started trivial app with life expectancy of 6 months or at most one year. And all these years I am adding features. And the beast has now life expectancy at least 5 more years, because ERP migration is going a slower then expected :)
So since I’m probably the one that has tried it in the most scenarios, I guess I could describe my experiences, though since I’m the author there is of course some bias. • I wrote a 3d game board platform with Fulcro using three.js. I actually put a second reconciler in place for this. So, the standard DOM/application features were standard Fulcro, and all data was in the client db, but I had a separate reconciler that would take any data representing 3d objects and “sync them” to three.js when they changed. Of course that involved a bit of low-level js interop. The interaction also had to come from three, but I found it to be quite tractable and made the web-based UI and data loading/normalization in place. So, I would say that “extremely dynamic UI” is one of those things where the base libraries are still useful, but you do end up wanting “more” than is canned. That said, what app doesn’t need “more” of something that isn’t provided? • I agree that if you don’t want an SPA, other options have advantages. HTMLX is interesting for backend-driven stuff. • Trivial apps: I use Fulcro, but that’s because I know it very well. If you are learning and doing a trivial app, and the learning isn’t aimed specifically at Fulcro, then yeah, use what you know. • Very simple data: I sort of agree with this. “If your data does not benefit from normalization” is the way I would put it. E.g. If you’re doing a visualization and your data is large (and not editable in a divisible way) then normalization is merely overhead. It could still be quite complex data, but Fulcro isn’t adding anything to your abilities of comprehension and manipulation. It’s just a blob of crap your fancy visualization understands. Fulcro adds nothing of value at all here. Personally my advice on technology choice is to heavily consider the human factors first. Can you even use Clojure(script) and get buy-in from the company/peers? If you’re asking people to move from significantly different technology then people problems are your biggest problems.
The real places it shines is in it’s target niche: business web application development. • Lots of normalized data • Full stack problems already addressed • Can benefit from things like RAD for fast development of “supporting” screens (there are a LOT of these in a real business, and the less time you spend making them the better). E.g. the screens that let your staff support your users without a dev getting involved. I built it for building startups. Many of the decisions in design were made around the challenges that occur there: Maintaining simplicity, reducing the number of ad-hoc inventions around simple problems, minimal drag on developers as real users are brought on (e.g. RAD lets you off-load simple data fix and diagnostic tasks to support), best-in-class hot code reload behaviors for fast iteration on problems, good visibility into the inner workings of the live application, minimal repetition/boilerplate, testability (if you follow the pure rendering paradigm, most things are pure functions and very testable). internationalization, etc.
trivial apps in fulcro are just a few loc, not sure what you gain by not using it. 🤷
@U087E7EJW other than a learning curve
Fair, but you pay that price once.
Excellent, thamk you!
Hello friends! I have finally written https://blog.jakubholy.net/2023/when-not-to-use-fulcro/

Thank you for writing this up. As mentioned in the article, dynamic UI is where I am evaluating Fulcro (Bret Victor-esque apps with experimental UI). Lots of derived data. Can Fulcro Raw help here, with "more than is canned"?
I hope Tony can answer that 😅 though I am not sure there is enough detail for a good response
Hello friends! I have finally written https://blog.jakubholy.net/2023/when-not-to-use-fulcro/
