Clojurians Log v2

Currently I'm exploring UI development with hiccup, htmx, and alpine. So far I'm really liking it. My next test is going to be using SSE or web sockets with it.

Sean, what's that "Clojure-with-SSE" option that was recently announced? I missed that announcement.

I might have been thinking of https://github.com/gersak/ty-pocketledger which uses Datastar on the frontend and SSE to stream data. I did a search here for SSE and quite a few things came up recently that use SSE without being specifically libraries based around SSE. So I guess I've just been seeing SSE mentioned a lot lately -- including ECA using it I think.

My favorite lately is replicant. You should at least check it out if you haven’t already ☺️

I can offer a technically naive perspective. Had notions of reworking our device configuration software as a web-app for a while. Having not written anything webby in quite a number of years (jquery/javascript the good parts era), a colleague and I worked our way through POCs in react, angular, svelte, clojurescript/reframe/uix and found our way to clojurescript/replicant and are very happy to have done so. Have no real insight into trade-offs between reframe and replicant -- subjectively I've enjoyed both, but replicant feels simpler, in the best sense of the word. It does a lot of clever things under the hood I don't really understand, but doesn't box you in and provides a flow that's easy to reason about and all the levers you need to do weird (and perhaps ill-advised) things the authors weren't planning for.

Replicant sounds great. I like the idea of working with primitives and avoiding js frameworks with lots of churn. My main concerns (without having yet done sufficient research) is that it won't allow me to use any of the pre-made component libraries that exist for React. I don't want to spend much time with the minutiae of design for things people have already designed quite well and made available for me to use. The other thing is that it's pretty new and I worry about whether it has enough maintainers to have momentum should key maintainers become unavailable.

My feeling -- now that I also maintain a 150K line React.js app -- is that a lot of those React component libraries are either unnecessary or overly complex, and you can get the benefits with simpler, more "web standard" component approaches...?

Generally speaking, there's no real impediment to JS/vanilla React interop regardless of which approach you take in terms of front end framework with CLJS. I've been messing around with https://github.com/pitch-io/uix and while I'm not entirely sold on it since it feels too easy to fall into anti-patterns common in the wider JS ecosystem and the macro based DSL feels like a step backwards, it might be worth a look for you since it is a pretty thin layer on top of React and quite performant compared to re-frame with Hiccup. Some of the projects I've seen that use it mix it liberally with re-frame so it's not like picking one approach locks you out of all the others.

@edward.hughes1911 do you mean performance problems are common with re-frame?

https://github.com/Day8/re-frame/blob/master/docs/Performance-Problems.md?utm_source=copilot.com

Not particularly a problem, in as much as the most egregious issues are things that are easily avoidable as Sean referenced. It's just that the callstack with re-frame/reagent is about 2.5x slower than UIx by comparison. I'm not sure how reflective these comparisons are with vanilla React in the wild though, since I get the feeling it's incredibly easy to bloat your frontend in JS or TS to the point where the performance delta is negligible.

Also I would probably be remiss in not mentioning https://github.com/hyperfiddle/electric, though I wouldn't have the first clue as to how you would handle JS interop with that.

Perhaps a question for the #clojurescript channel? There are a lot of options -- including some mostly server-side things, HTMX backed by Clojure, and there was a recent announcement of a Clojure-with-SSE option... In the #clojurescript world there are dozens of libraries, some built on React, some not.

Any particular options you were considering? I'd say you have to first decide if you want ClojureScript or not. Is your app going to have a backend ? If so, is your UI/UX needs to be very powerful resembling a full desktop application with panels, animations, drag and drop, custom right click, and so on. Or is it more you just want a dynamic website with auto-refresh, carousel, selective page refresh, etc. Do you value using an existing component library, one from the JS world? Or need compatibility with some existing JS thing? Etc.

My mistake, I thought this channel was for all things Clojure, not just the main language. Happy to move if it'd be more suitable there. Yes, I am looking for options in ClojureScript. I currently have a reitit backend, but it's not a strict requirement. I have lots of experience with Fulcro, but I'd like to try another option for my next project. It will be a complete data-centric webapp. I do value being able to leverage js components and libraries. From some brief discussions I've had, re-frame and uix are on the short list, but Replicant looks interesting too, and I don't want to completely rule out anything else just yet. Not sure how Polylith fits into the equation, but that seems like something to check out too. One thing that is fairly important is the size of the community and/or a dependable backer so that I can have confidence that I'm building on something that will have longevity.

Happy to talk about #polylith 😸 esp. since my external test runner now supports ClojureScript testing with both Shadow-cljs and Olical's cljs-test-runner! I think if you're building "multiple apps" from a single codebase with shared components, Polylith could be very compelling: one app could be the main backend (API) and one app could be the ClojureScript frontend, for example.

Is Polylith primarily useful for mono-repo codebases like that? Would it make sense to use it exclusively for the frontend app(s)?

At work, we build about two dozen artifacts from our Polylith monorepo. If you're building a frontend and a backend, and you plan to share components between the front and back, that would qualify in my opinion, but it might not be to everyone's taste. It's about code organization so it is orthogonal to any libraries or frameworks you choose to use.

Thanks for clarifying that for me. I'll rule out Polylith for this particular purpose, but it does sound interesting. I'll keep it in mind as the project grows.