shadow-cljs VS component

* 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.

* Lifecycle management: Mount, Integrant or Component (https://github.com/tolitius/mount https://github.com/weavejester/integrant and https://github.com/stuartsierra/component)

When you start to have multiple stateful components (the database, the HTTP server, your Redis connection, a page cache, etc.), then you'll want to use a library like component that manages their (inter-)dependencies and provides a consistent notion of lifecycle.

Today I released a new version of Reveal Pro — dev.vlaaad/reveal-pro {:mvn/version "1.3.308"} — that adds sticker integration for system libraries such as mount, component and integrant!

I agree with the main sentiment from the article. Although I do think they are discussing Inversion of control more-so than dependency injection.

One of my first languages was .net and I was never able to really understand DI in that context that well.

Actually using javascript and ducktyping made me understand what it actually was.

I remember a .net job interview where I had to write a micro-service and opted to construct the dependency graph in the main function initialising "all" the classes there. Instead of discussing the pro's and con's of that approach they berated me for not using a DI framework (No I did not land that job, but in hindsight it was the most expensive job interview I've ever had. The room was filled with 8 developers going over my code).

The main thing the article glosses over is state. something people with a functional background hide from. But if you look at something like the httpclient in .net. I think it took the .net world like 10 years to start using the httpclient properly. Scope and lifetime of those kind of objects are important. managing connection pools, retry state, throttling or the incoming http request. DI does make that kind of thing easieR (I'm not saying it makes it better)

Look at clojure's component(https://github.com/stuartsierra/component), I'm not a clojure expert by far. But it is kinda DI/IOC in a functional language.

In closing we can agree that it is underused in the right places and overused in the wrong ones.

https://github.com/stuartsierra/component#no-function-should-take-the-entire-system-as-an-argument

Yeah like I mentioned I'm not like super sold on the everything-should-be-an-actor paradigm, but I find value in DDD + a light implementation of Components (similar to stuartsierra/component).

https://github.com/stuartsierra/component for managing components lifecycles in projects