shadow-cljs VS mobx-jsx

* Single-Page App: shadow-cljs for the build concerns (https://github.com/thheller/shadow-cljs), Reagent with Re-frame for complex/large app (https://reagent-project.github.io and https://github.com/day8/re-frame). Even if we now prefer using HTMX (https://htmx.org) and server-side rendering (Hiccup way of manipulating HTML is just amazing, https://github.com/weavejester/hiccup).

Now, add shadow-cljs.

Work with latest shadow-cljs (& closure compiler) #890

You can already develop with ClojureScript on the back-end. A popular ClojureScript compiler, Shadow-CLJS (https://github.com/thheller/shadow-cljs) has a target for Node among many others.

Hi, I'm looking at Clojurescript again after not having paid attention to it after several years. Are you saying that shadow-cljs does something to deal with the, "I have no idea if this library I want to use works with the Google Closure compiler," problem? If so, what? I'd really like to know.

I don't know, the community in general tend to use macros that are well written. I keep seeing core.async being used (`go`) in Clojure projects, and also various macros for writing HTTP servers (compojure being a popular one which main code interface is a macro `defroutes`).

ClojureScript projects also routinely add support for making asynchronous code look synchronous (like `async/await` in vanilla JavaScript) via macros. shadow-cljs's `js-await` being one of the well-written ones: https://github.com/thheller/shadow-cljs/blob/49fb078b834e64f...

Usage:

    (defn my-async-fn [foo]

Unclear what "rendering a webpage" entails exactly.

If you want to do frontend development, you can give shadow-cljs a try, the quickstart is pretty quick: https://github.com/thheller/shadow-cljs#quick-start

If you want to just render server-side HTML, something like compojure (HTTP routing) and hiccup (Clojure data -> HTML) is pretty easy and quick to get started with (https://gist.github.com/zehnpaard/2071c3f55ed319aa8528d54d90...).

If you want to generate HTML files to serve with nginx/whatever, you can just use hiccup and `(spit)` the resulting HTML to files on disk.

Sure, you can use JSX without a framework! Be it MobX JSX, dom-chef or jsx-dom, it should feel right at home.

mobx-jsx is using MobX as the reactivity system together with Solid's DOM renderer.

I've just skimmed the article but I'm definitely going to give it a proper read.

We've built an architecture somewhat like this where we're using MobX objects in the frontend (a graph of the db objects effectively) that's patched by subscriptions to tables via hasura. So we effectively have all the data on hand locally all the time and use the reactivity on top of that.

We actually played around with sqlite in wasm because I really really miss having a real relational db in the frontend. We decided that there was just a few too many unknowns to proceed further with the idea. Initially we were using indexdb as a frontend cache but dropped that since without adding more layers to it it doesn't provide much value.

(Also played around with using Solid's direct mobx -> jsx library without having react inbetween https://github.com/ryansolid/mobx-jsx but, again, too much unproven tech to build on).

The work you're doing here is super exciting. The developer experience of what we currently have is pretty nice and I can definitely see your model working out well in the future.

I've been keeping an eye on your work for a long time now. We're a mobx shop so I was hoping to see you explore the ideas you had around that a little more (https://github.com/ryansolid/mobx-jsx).

I like and know where I'm at with React, but bringing a beginner through it recently definitely made me re-appreciate how nuanced it is. Also, you have to do a bit of voodoo to get good performance, and when you do the intention of the code vanishes pretty quickly.

For someone using React on top and mobx stores in the background (50k LOC), how big of a task would you say it is to move to something like Solid?