Fork me on GitHub

Hello, is it possible for a figwheel client to connect on another host than localhost?


I tried to configure :server-ip inside :figwheel map of project.clj without success, neither with :websocket-host in :cljsbuild>`:figwheel`


Are there any cljs-based projects designed explicitly for good interoperability with existing node js frameworks & react libraries? Basically something building upon thheller’s proof-of-concept to make it more mature and production ready. I really want to write cljs instead of jsx by default, but Fulcro & Re-frame are too opinionated (I think hooks are good), Rum doesn’t support newer isomorphic js developments like incremental static regeneration (, and in general it feels like isomorphic Clojure web projects with a JVM backend are just playing catch-up with isomorphic js, where most practical innovations happen first, especially from React itself & Next.


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 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: