clerk

mkvlr 2025-11-24T01:20:41.422659Z

a https://github.com/nextjournal/clerk/pull/778 to render notebooks to html strings. This is inspired by @dnolen’s talk from the conj. Could be an interesting direction for clerk’s viewers leading to a much smaller bundle when combined with a morphing lib and custom elements for stuff like vega, plotly, code listings etc. Not sure yet if it would mean losing some of the interactivity (e.g. expanding seqs) when rendering to a static html without a clojure server.

borkdude 2025-11-24T11:16:36.938689Z

you could also just send the hiccup to the client and do the morphing based on the hiccup. (e.g. using https://github.com/borkdude/reagami or replicant)

borkdude 2025-11-24T11:18:06.576799Z

but if you're mostly interested in "smaller bundle" even preact can work without losing most of the React features

borkdude 2025-11-24T11:19:49.189859Z

I think for clerk at this point it would be interesting to have things render faster in static bundles rather than a smaller JS bundle. E.g. the book (https://github.clerk.garden/nextjournal/book-of-clerk/commit/a343752adb110e80a7cb33e375517eb3597e9db1/) takes pretty long to load, which is a bit annoying when you first load it. I think this is not due to the JS size but due to how index.edn is processed at runtime.

borkdude 2025-11-24T11:23:27.264659Z

If you just want to render literal HTML strings to the DOM only once you don't need a morphing lib, you can just set innerHTML

mkvlr 2025-11-24T12:15:42.177769Z

the nice thing about using html strings is that there’s no need to wait on any js for rendering

borkdude 2025-11-24T12:16:37.467719Z

ah do you mean, you render the whole notebook to an HTML document and just render that?

mkvlr 2025-11-24T12:16:55.584559Z

yes, or use morphing for updates

mkvlr 2025-11-24T12:17:16.119219Z

have you seen david yang’s talk from the conj?

borkdude 2025-11-24T12:17:17.327869Z

when you use a morphing library you still need JS for rendering. no different from hiccup in principle

mkvlr 2025-11-24T12:17:38.048369Z

yeah like 200 lines

borkdude 2025-11-24T12:17:41.716389Z

yes, I was in the audience (EDIT: I was not in that talk, confused this with David's talk). I'm fairly familiar with the concepts

borkdude 2025-11-24T12:19:00.623979Z

but anyway, I think @dnolen is right, you should probably think if this is the right use case for clerk. It's not that obvious

mkvlr 2025-11-24T12:20:03.443659Z

I saw a lot more client-side interactivity in the app that david showed compared to clerk

borkdude 2025-11-24T12:36:03.825549Z

the interactivity is special-cased by producing the right HTML on the server and streaming this to the client. I'm not sure if such a model works well for clerk notebooks. Maybe by moving "viewer functions" to the server more. But then you would indeed lose interactivity in statically rendered notebooks.

borkdude 2025-11-24T12:51:21.494269Z

Wait, I assumed with David Yang you meant David Nolen. I thought that was a typo since Nolen also mentioned DOM morphing in his talk. But I do see there is a David Yang talk now. 😂 haha sorry, so much DOM morphing this year :) David Nolen also showed an interactive demo of scrolling through a large table view

😂 1
borkdude 2025-11-24T13:36:11.421849Z

Now watching the talk during lunch

borkdude 2025-11-24T14:07:41.711409Z

Watched it. Great talk, sounds similar to what lots of folks are doing with D*. 12 years ago a developer who started his career in '92 told me that about every 10 years the shift happens from thin clients to fat clients. That sounds about right.

mkvlr 2025-11-25T00:45:01.219679Z

thinking if there’s ways to get the interactivity back in static notebooks

mkvlr 2025-11-25T00:46:58.401429Z

> Great talk, sounds similar to what lots of folks are doing with D* what’s D*?

mkvlr 2025-11-25T00:48:13.729109Z

I’m really surprised that the morphing works so well that you can scroll a virtualized table

mkvlr 2025-11-25T00:49:40.985589Z

I think the main feature I want in clerk is the ability to render notebooks on the server to html

borkdude 2025-11-25T00:49:43.503769Z

D* is DataStar

mkvlr 2025-11-25T00:49:49.095339Z

ah

mkvlr 2025-11-25T00:50:21.022289Z

right now the react-based server side rendering is overly complex, slow and doesn’t work for a lot of use cases

mkvlr 2025-11-25T00:53:09.198969Z

I also certainly feel the complexity of having state on the server and on the client

dnolen 2025-11-24T02:27:40.940059Z

@mkvlr yeah I do wonder myself whether it makes sense for projects like clerk where the interactivity is pretty sophisticated. In our case I think we weren't gaining that much from aggrid + React so it felt like a good match.

mkvlr 2025-11-24T02:35:27.235049Z

think for clerk it it should work well, most things don’t have that much interactivity either, but I’ll try it out more and guess I’ll realize soon enough what I bump into. The flamegraph comparisions when scrolling you showed in your talk were pretty amazing.