Re-frame doesn't really dictate whether you can use hooks. But they won't work with it very well if you manage some data with re-frame and some data with hooks. In any case, re-frame is built on top of Reagent, and the latter definitely allows you to use hooks just fine. As an alternative, there's https://github.com/lilactown/helix designed to be a thin layer between CLJS and React.

Can attest to using helix + re-frame with ease with @U4YGF4NGM

Though no SSR for now

Yeah, I’ve been using vanilla Reagent and it’s great. I was mostly curious about the SSR/ISR part.

In terms of the future of isomorphic web dev with Clojure, I wonder if it’s more likely that stuff like ISR gets added to JVM/JS hybrid projects like Rum, and the same with any other advances from the JS ecosystem, or if cljs just becomes more deeply integrated with the existing node/browser isomorphic ecosystem

the SSR story for ClojureScript is pretty bad rn because either you're rendering in the JVM, which is going to lack the bleeding edge features and support that things like next.js has, or you're doing CLJS on Node.js which IME is a second class experience compared to both writing your app in JS or using the JVM on the server

at my previous gig we did SSR via Node.js on the backend, and it was not a fun experience overall. the tooling might have gotten better since then tho

Oh, BTW - would it be possible to run next.js on GraalJS?

A big part of the benefit of NextJS is its integration with Vercel, so that probably wouldn’t work

my understanding is that a lot of the value that next.js outside of vercel brings is in the compiler toolchain and marrying the front end and back end

What were some of the problems you ran into using Node with CLJS?

but i could be wrong. i haven't use any of the meta frameworks built on React yet

Right, especially with Next’s new compiler. It wouldn’t be fun to have to compile twice

there's much less mind share on the CLJS side for deploying Node.js apps, so most of the time you're going to be writing interop in your app

there's been development here, e.g. with sitefox. at the time, we used macchiato which IIRC wraps express, and required me to get my hands dirty a number of times to dig into the internals

to get a lot of the benefits of doing SSR on Node.js, you need a data fetching framework that knows how to fetch data on the backend and front end

there's basically nothing like this in CLJS. I built one, but it was buggy and weird.

Can’t you just use fetch/node-fetch directly via js interop?

I’m thinking basically compile cljs straight to js with pretty much no optimizations, and let Next take care of the rest

with suspense this might become vastly easier, but at the time there was no suspense. so if your components fetched after mounting, you had no way of waiting for that result when rendering on the server unless you built a mechanism for it

maybe next can handle that part

But I wonder if Next would require a different compile target than either “browser” or “node” from shadow-cljs

Or does the default cljs compiler provide something like this?

i don't know - i would try shadow-cljs' ESM target, assuming next.js uses ES modules

the problem with using another compiler toolchain with cljs is that it becomes really hard to get a REPL into your app at dev time

Right, but the ISR stuff isn’t that important at dev time either

I could just dev in pure client rendered cljs and then do the conversions only when I need to deploy to prod

idk, typically you want to develop your app as close to what production is going to be as possible. maybe it's worth it though

I think in my case the interactive parts of the app are decoupled enough from the content I want to be prerendered by the server to not make a huge difference. I’ll at least play around a bit with the ESM target like you suggested

Curious what you end up with @U03BQMGDM9C!

Maybe have a look here. The plugins linked expose more control than Next. You might find a better foundation to work with here: https://vitejs.dev/guide/ssr.html