lambda island hiccup is Clj only, but that should be ok right?

I don’t want to swim too far upstream. If it’s too complicated I might re-write my components. But I really want to use the HTML + CSS composition afforded by https://github.com/lambdaisland/ornament, which might not work with rum (at least the named components parts) Does rum support [:<>] anonymous hiccup collection style?

I believe it does.

I just gave it a try in the repl and (rum/render-html [:<> [:div "it worked!"] [:div "didn't it?"]]) renders "<div>it worked!</div><div>didn&#x27;t it?</div>".

yes it does support that! using hiccup instead of rum is also fine. the rum code in Biff is just there as a convenience. mainly you'll probably want to write a hiccup version of wrap-render-rum and put it in your middleware stack. the instructions in the v0.7.11 release notes include a section on making it easier to modify your middleware stack FYI

you also may need to write your own versions of base-html etc. on the bright side I don't think there's anywhere in the biff library code where those are called. they're just provided so you can use them in your app code if you want. so you just need to make sure that all your app code calls your hiccup versions. I'd be down to write those functions in a hiccup-compatible way too--in fact they might already be compatible; maybe writing some wrap-render-hiccup middleware is all you need to do. though I might be using :.foo which is an abbreviation for :div.foo in rum; not sure if lambda island hiccup supports that

this is the first time I've seen that lib. pretty interesting. I like the way it does unsafe-html better than the way rum does it.

> write a hiccup version of wrap-render-rum and put it in your middleware stack. > write your own versions of base-html Ok, thanks . Ill try that today.

I always felt like the html/css divide broke design composition. Ornament goes a long way towards smoothing over the gulf. The Girouette project (optional include) is like JIT Tailwind tokens, but driven by instaparse custom grammars. But it also gives you inline Garden CSS as data syntax for more bespoke or complex styles. Tailwind tokens are convenient, but can add complexity and limitation. Great for quick bootstrap, but seem to add complexity for open-ended, iterative, dynamic styling? Probably better to have the values seperate from the tokens in the long run? Shadow-css is doing that I think, haven’t tried it yet.

I'm a big tailwind fan myself. I honestly can't think of any limitations I've run into with it, especially with JIT. Could you elaborate on what limitations you have/are worried you might run into with it? I used girouette for a little while a couple years ago. I liked that it was plain clojure, so no need to run a separate process for CSS compilation. However the tailwind standalone binary mitigates that, and I do really appreciate being in the mainstream for once ha ha. girouette would be more attractive to me if it was an exact drop-in replacement for tailwind.

Yeah, I started using it before Tailwind was JIT, so it its probably overkill now, unless you want to design your own bespoke grammar… And not worth being out of the mainstream (benefits of copy/paste). I haven’t really used modern Tailwind complier stuff yet though, so I’m open to it. In ornament, Girouette is not necessary, just a convenience for using tailwind token syntax (or custom). Ornament is about separating style declaration code from component logic code . But not removing the styling totally from the templating language or even the file. Separation of concerns, but still have close co-location. Can avoid littering a component with n style tokens, which can be many, and obscure the other logics. You are still in clojure data land, so it all can compose as needed. I guess Tailwind can do a lot of encapsulation itself with JIT, and forge new meta-tokens as needed. But it might be easier to reason about one compiler and language, instead of 2. And i trust clojure more for re-using whataver styles have been defined already (with custom inline modifications). Ornamant just compiles static css though, and is not really meant for dynamic runtime style updates like in some js/cljs approches. But that seems to fit Biff’s model.

Nice, makes sense. Sounds like an interesting approach for sure.