I don’t know about other approaches, but htmx is really nice to work with. I’m building a server-side rendered app with it at the moment. What does rum bring to the table in combination with htmx?

Rendering.... presumably you are using hiccup instead? And did you look at a wrapper such as ctmx or do you just use directly? Haven't found many examples so far.

Ha, wow, I always figured Rum was for SPAs. 🙈 But yes, you are right that I’m using hiccup for rendering.

So I guess my question should have been: Why rum instead of hiccup for rendering?

It looks as if I might be able to share components and use them in SPA and SSR apps.... and I thought rum was faster than hiccup... but my bigger query related to whether there was some community momentum towards htmx or similar.... and how people were using it... wrappers / routing / etc.

I went a bit off topic, I just had to ask. 😉 In my app I have very little htmx wrapper code. I only have a single piece of middleware that detects whether a request was made by htmx or not. In case it was, I just return the rendered html snippet; in case it isn’t I return a full html page. I detect that using the HX-Request header I believe it is called. I think htmx is sufficiently lightweight to not need much wrapping, if any at all.

That is really good to hear.

Thanks!

I feel like I need to add that my app is still in its infancy, so I might just not have seen the pieces of htmx that would warrant a wrapper.

I've bet the farm on this now...

i've been using unpoly for my current project (2 years). server side rendering has issues too, but the less front end code, and less re-implementing basic HTML widgets, the better. I like using traditional templates so my web designer doesn't have to learn how to do clojure, and can just focus on html/css (this is also a problem with SPAs). currently my largest pages are ~300kb HTML, and updates to those pages are typically 300bytes or so.

htmx shouldn't limit you from using more sophisticated view layers, i hope.

Thanks @U0LAJQLQ1 - are there any considerations for the use of unpoly with clojure?

no, i think it's similar to htmx, it's probably bit more opinionated. these are very light weight frameworks, they expect your server to be traditional, and you can do a little more work to upgrade traditional page responses with partial ones, and this task is going to be specific to your resource. I created components that use http headers to talk to my routes that do partial updates (partials are a pain in the ass with traditional templates, and i may mix in rum/hiccup in the future). these types of frameworks do make your server resources care more about http headers, in general. so, main consideration would be to make your front end be able to communicate the partial ID (i use headers for this), and then that header maps to a resource lookup, this lookup will be able to do a partial DB request & render partial HTML, however these are hierarchical in the worst case. worst case: your partial update changes a parent view, or a sibling view, or a global view. so worst case you are doing the react magic DOM diff on your backend. unless you find some glaring issues with htmx, i wouldn't consider unpoly. but you should look into it just to compare and contrast.

i didn't start doing partial updates until a few months ago, and just sent whole pages until then... it's convenient to be able to delay this, or optimise specific pages, or parts of pages, over others.

That is really helpful thank you. Lots to consider.

We hand rolled a solution to this about 3 or 4 years ago. Using reagent in the front end with fe/be shared views. We wrote a simple lisp machine server side renderer to support reagent component types (as native hiccup doesn’t support them), and use transit to communicate the view data between fe/be via inline data attributes — and then occaisional requests for components id’d in a way similar to @U0LAJQLQ1. We avoided using reframe because it wasn’t obvious how to make the singleton state atom work with ssr and the idea of having components… without for example rewriting reframe explicitly in cljc. The advantage was to get server side rendering on the initial render, and then have the front end take over. We abstract across reagent atoms by wrapping the data in a delay on the server side. The disadvantage is the complexity tax; and the need to do isomorphic routing… you can use reitit for this. In the end we also had some design changes that changed the information hierarchy such that we didn’t really benefit as much as we were hoping to… so I don’t think it was worth it in the end. At the time there weren’t really any solutions to this that I was aware of… except maybe fulcro; but iirc fulcro was being rewritten into fulcro 3 at the time. Anyway it’s not rocket science, but wrapping it up into a nice framework is hard…. I wouldn’t particularly recommend it… and would be interested in anything you find.

Really interesting thank you. I’m currently using Fulcro but I can see that I might be better with a la carte client side scripting rather than an SPA.

Hmm, worked just fine for me on JDK 11.0.16 on Ubuntu with clj -Sdeps '{:deps {com.clojure-goes-fast/clj-memory-meter {:mvn/version "0.2.1"}}}' -J-Djdk.attach.allowAttachSelf.

What is the stacktrace of that exception? And which JDK exactly are you using?

How do I get the stack trace? Right now I'm using ibm jdk 11.0.17 but I also tried with oracle openjkd 17.0.2

Maybe I am using it incorrectly? I'm trying to call mm/measure from inside a Cursive repl.

Also got this error message "(mm/measure [1]) NoSuchFieldException jvm java.lang.Class.getDeclaredFieldImpl (Class.java:-2)"

I think this is the stack trace

(try (mm/measure [1]) (catch Exception e (pst e)))
NoSuchFieldException jvm
	java.lang.Class.getDeclaredFieldImpl (Class.java:-2)
	java.lang.Class.getDeclaredFieldInternal (Class.java:930)
	java.lang.Class.getDeclaredField (Class.java:905)
	clj-memory-meter.core/get-self-pid (core.clj:100)
	clj-memory-meter.core/get-self-pid (core.clj:97)
	clj-memory-meter.core/fn--69 (core.clj:123)
	clj-memory-meter.core/fn--69 (core.clj:123)
	clojure.lang.Delay.deref (Delay.java:37)
	clojure.core/deref (core.clj:2228)
	clojure.core/deref (core.clj:2214)
	clj-memory-meter.core/meter-builder (core.clj:128)
	clj-memory-meter.core/meter-builder (core.clj:128)

I tried on JDK 11 from CLI and on JDK 18 from Cursive - both worked just fine, both OpenJDK. Do you get the exact same exception on both JDK versions? Are you 100% sure that Cursive uses the JDK version that you have specified?

I'm pretty sure it's using that JDK version.

When you start a Cursive REPL, it outputs the exact Java binary it uses as the very first line, at least on my end.

Ah, and which Clojure version do you use?

JDK17 stack trace

(try (mm/measure [1]) (catch Exception e (pst e)))
InaccessibleObjectException Unable to make field private final sun.management.VMManagement sun.management.RuntimeImpl.jvm accessible: module java.management does not "opens sun.management" to unnamed module @7f4f095d
	java.lang.reflect.AccessibleObject.checkCanSetAccessible (AccessibleObject.java:354)
	java.lang.reflect.AccessibleObject.checkCanSetAccessible (AccessibleObject.java:297)
	java.lang.reflect.Field.checkCanSetAccessible (Field.java:178)
	java.lang.reflect.Field.setAccessible (Field.java:172)
	clj-memory-meter.core/get-self-pid (core.clj:100)
	clj-memory-meter.core/get-self-pid (core.clj:97)
	clj-memory-meter.core/fn--69 (core.clj:123)
	clj-memory-meter.core/fn--69 (core.clj:123)
	clojure.lang.Delay.deref (Delay.java:37)
	clojure.core/deref (core.clj:2228)
	clojure.core/deref (core.clj:2214)
	clj-memory-meter.core/meter-builder (core.clj:128)

clojure 1.8.0

Try the latest one or at least 1.10.

updating to clojure 1.11.1 fixed it

thanks!

Why was version 1.8.0 causing it to not work?

For 1.10+ they have a different code path to get the current PID. Created https://github.com/clojure-goes-fast/clj-memory-meter/issues/9