I've used retool and react-admin via a REST interface for this sort of thing.

this was the primary feature of the defunct Caribou project (what I worked on at my first ever Clojure job ages ago...)

ah, interesting! https://github.com/caribou

it's very old, and not under active development

yeah, might still be interesting to peruse and see the approach taken, as compared to the aforementioned frameworks

the general idea was defining the content of the site via database, then using DB CRUD to control what's displayed

use case was the end user has content admins who could be trained to use the admin UI, with the power to create new assets paths and layouts via DB upload without dev work

yeah, that sounds quite similar to what Django was originally envisioned to do, actually

the original sponsors ended up switching to squarespace

yeah, django was definitely an inspiration

I have no clue how many deployments kept the auto admin interface, though, versus rolling their own

@U0183EZCD0D one example of an idea from that project that could be imported elsewhere: using a db data model for paths, and then consuming that in the back end to create a router

I think I remember @U0NCTKEV8 saying something like that a few times.

Similar quote

Because the Java invocation syntax in Clojure is clean and simple, it's
idiomatic to use Java directly, rather than to hide Java behind Lispy wrappers.

another one

Clojure embraces Java and its libraries. Idiomatic Clojure code calls Java
libraries directly and doesn't try to wrap everything under the sun to look
like Lisp. This surprises many new Clojure developers but is very pragmatic.
Where Java isn't broken, Clojure doesn't fix it.

personal experience: it's like a framework, it works perfectly until you leave the original author's happy path, then you need to fork it because they misunderstood or incompletely covered the underlying API

doing interop in the first place is less work than maintaining a fork of a thin wrapper

also the wrapper adds layers / complexity

Wonderful, thanks :)

it totally depends. wrappers can give idiomatic access while leaving the Java world open for extension

right - ring for example

@U051SS2EU Exactly right. Even just minor things like spending 30 minutes wondering why a property that's clearly in the libs docs isn't being applied until you reason the wrapper is shit and only passes along the 3 keys that the original author cared about. /tableflip.

but I haven't seen this for thin wrappers

Ring is not a thing wrapper - it's a unique abstraction :)

@U09LZR36F What wrapper is this about?

@U04V15CAJ just some react component that's pretty thin when used from Helix anyway.

ok. what I had in mind, e.g. babashka.process: https://github.com/babashka/process it's a convenient way of creating processes from Clojure while still having access to the raw underlying java stuff

That's not thin. It's a little bit of an abstraction. Like a cracker, but not quite a biscuit.

I like wrapper libraries. I have written many which I would characterize as thin but add a modicum of value. There are many situations where Java libraries have unwieldy class structure and wrapping eases the pain.

I really don't like when engineers create context-free edicts for all to follow. We don't need that much religion.

This is a good point and puts the quotes into context. Obviously if your wrapper provides some tangible benefits outside of just hiding Java interop, then it adds value. The point of the quotes are rather: Java interop by itself is both idiomatic and ergonomic and doesn’t require wrapper per se.

I agree, I have moved away from clj-time, but more importantly java-time , for example, and prefer java.time access via interop.

This is a very informative discussion! It particularly reminded me of a recent case where I recommended not returning AWS data *Response Java objects from functions, but rather converting them to Clojure maps. Does the maxim discussed here suggest that that was wrong? In other words, does the interop argument extend to directly working with Java data structures (in object hierarchies), rather than wrapping them in a thin Clojure data translation layer? How about when all the operations and data involved are limited to a single namespace?

the watershed line is if the wrapper is an external dependecy

bringing in an external dependency that doesn't justify itself is bad, and wrapping is no justification

for internal stuff the question is a lot less clear cut

Ah, didn’t know of it! Thank you for pointing me in a direction :)