I personally do see quite a gap where something like Next / Remix could be. Part of the problem is that the JVM is not a good fit for server (pre)rendering as npm libraries wont work there. I would like to see an answer to those in the ecosystem. They would probably have to build on top of Node/Deno/Bun for the server rendering.

Closure Library being dead doesn't matter at all to CLJS in general. Only maybe matters if you make heavy use of it directly, which most people do not do. cljs.core itself doesn't use much and could easily be replaced.

JS keeps churning out useless nonsense and breakage for no reason whatsoever. Glad we are not doing that.

for backend I'd always use JVM Clojure. CLJS via node/bun/deno whatever is not even a consideration for me personally, so no argument on that front.

I personally think nextjs and frameworks like it are nonsense as well, and will be replaced by the next next new thing inevitably. That doesn't mean we couldn't benefit from a proper framework for CLJ/CLJS, but it would look nothing like those.

I’m all open for new ideas on that front and am not very happy with Nextjs and the like either. But there (at least currently) is a need for server-side rendered websites/applications and the lack of npm libraries for rendering that content on the JVM is a problem. I’d still use the JVM for the backend but Next etc. can prepare content on a server before delivery for SEO and performance boosts. The node server often gets used only as “frontend server” rather than “backend server”. For nothing more than the rendering . If we can create something alike or (hopefully) better on JVM side i’d be very happy.

I generally like that backend development is much simpler and doesn't need to worry about "updating" the DOM. just spit out some html string, e.g. via hiccup. I like simplicity in that way. IMHO there is no need to bring all the extra complexity of frontend to the backend, just to spit out some html string again. and the now commonly called "island architecture" CLJ+CLJS is almost perfect in many ways, it could use some "sugar" to remove some boilerplate but otherwise its great

I still have some reading to do on island architecture and its state. It does look very promising and I generally like the idea. My doubts come - there too - with SEO support - and maybe how well libraries can be made for it (I got some catching up to do on that front). Context: Projects we have very often are such that take their data from some CMS, display information from it and then enhance some functionality on the website. Island architecture sounds like a perfect fit in general but the CMS data has to be there in the string that is delivered from the server already making it the servers “job” to get that data. Not that it cannot be done, but some complexity even then has to be pushed to the server - unless we ignore the need for SEO.

https://code.thheller.com/blog/shadow-cljs/2023/07/13/the-lost-arts-of-cljs-frontend.html

https://code.thheller.com/blog/shadow-cljs/2023/07/16/applying-the-art-of-cljs-frontend.html

easy way to pass data from the server to the client and for the client to "enhance" the existing html

I've been doing this for a really long time now and things like next.js always look like 10 steps in the wrong direction to me

of course I'm old and used to my ways of doing things, so maybe I'm just not getting it 😛

Hey thanks! looks like you had a lot of thoughts and investigation on that topic. Gotta catch up there and read through in my time!

I’m young (relatively) and next.js always looked like 10 steps in the wrong direction to me too but I felt… a bit stuck with the like

one thing missing for sure in CLJ/CLJS is people writing about it. there is plenty of that on the JS world which makes it look more "alive", when its mostly just noise though

IMO r/Clojure and related places misinterpreted the Closure library’s announcement very hard. Read carefully into the announcement and you will see not much will actually change. > We are committed to retaining the core functionality [of GCL] ... This includes Closure dependency management This is the ONLY part that matters for ClojureScript IMO. The fact that GCL itself is being frozen isnt really any bad news considering GCL is a mature library and a lot of it is easily replaced with the standard library of modern JS anyway.

The real concern for CLJS itself — GCC support for goog modules — is not going away and doesnt seem to be changing any time soon, and as thomas heller pointed out, cljs.core doesnt really depend on GCL, so you should only be concerned if you use goog.ui or something 😛

RE: SSR, #uix does it just fine with JVM-backed rendering; so unless you need something specific on the node side there you can have your cake and eat it https://github.com/elken/uix-ssr-demo

hmm… last time I tried JVM SSR in Helix and Uix I ran into lots of subtle hydration mismatches (e.g. generate IDs for form elements that are stable across server and client renders) that I would not recommend using it over the official React Server APIs at all

you essentially have to reimplement React in the JVM if you want JVM SSR so I have always stuck with Node.js — its unfortunate Macchiato is sparsely documented, but it isnt any harder to go down this route than using Express + React

I tried it with uix but it chokes on any use of an UI library from npm - as the JVM cannot use npm packages. Meaning using SSR on the JVM using uix or helix will cut you out of the use of any libraries from the JS-verse.

Granted it is easy to overreact to GCL going down given Google's history of being cavalier about dropping support. Thanks, overall I was secretly hopping for that sort of answers 😛 @U05224H0W Interesting blog posts, I really like how simple it is. Sure at some point it might be lacking but you did a great job of showing that incremental progression to React without rewriting the whole thing.

I agree with everything thheller said, with one additional point being that web browsers seem to be extremely backwards compatible. The only thing that comes to mind that won't work anymore are the <marquee> and <blink> tags.

Which were staple in back in geocities days for "site under construction" pages.

@U6JS7B99S SSR with Reagent is one of the things I have tried to make simple with https://github.com/chr15m/sitefox. In some of my apps I have Reagent components that are rendered both on the backend (statically to the browser) and also "hydrated" on the front-end. As Thomas said, people in the CLJS world maybe don't write about what they are doing enough, and I've been guilty of that too. Hope to improve in the new year and describe the architecture I am shipping with "full stack" cljs. Example: here's a function which renders a simple Reagent component into the "#app" element of some HTML template string:

(fn view:hello-world [_req res]
  (->> [:div "Hello world!"]
       (render-into html-string "#app")
       (.send res))))

Well, this is a reactive framework that can sit atop any UI, and here sits atop plain HTML/CSS/SVG, manipulating the DOM itself: https://github.com/kennytilton/web-mx Now what do I do for 🎄? More Flutter/MX videos? I just found out my climbing buddy says they are good background noise for doing the laundry. 🧺 I never aimed so high!