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.
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)
but if you're mostly interested in "smaller bundle" even preact can work without losing most of the React features
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.
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
the nice thing about using html strings is that there’s no need to wait on any js for rendering
ah do you mean, you render the whole notebook to an HTML document and just render that?
yes, or use morphing for updates
have you seen david yang’s talk from the conj?
when you use a morphing library you still need JS for rendering. no different from hiccup in principle
yeah like 200 lines
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
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
I saw a lot more client-side interactivity in the app that david showed compared to clerk
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.
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
Now watching the talk during lunch
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.
thinking if there’s ways to get the interactivity back in static notebooks
> Great talk, sounds similar to what lots of folks are doing with D* what’s D*?
I’m really surprised that the morphing works so well that you can scroll a virtualized table
I think the main feature I want in clerk is the ability to render notebooks on the server to html
D* is DataStar
ah
right now the react-based server side rendering is overly complex, slow and doesn’t work for a lot of use cases
I also certainly feel the complexity of having state on the server and on the client
@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.
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.