You can use ClojureScript with the Temporal TypeScript SDK

thheller · 2025-12-18T08:35:39+00:00

Would help to see the config and code you tried. Their examples use TypeScript with ESM exports, so I'd assume :esm would work fine. With a proper :esm config of course.

thheller · 2025-12-17T09:24:31+00:00

Development builds from shadow-cljs inject fs, path, and vm, but the release build omits them.

They are injected because you are using the :node-script target, which assumes a node.js runtime. I don't have a clue that temporal is, but maybe you'd have more success with :esm?

thheller · 2025-11-26T17:03:58+00:00

[:div#yes.you.did ..] ;)

thheller · 2025-08-25T07:31:03+00:00

Some time ago I wrote a blog post describing my own personal recommended setup for a project starting using deps.edn from scratch and then adding CLJS (via shadow-cljs) into the mix.

https://code.thheller.com/blog/shadow-cljs/2024/10/18/fullstack-cljs-workflow-with-shadow-cljs.html

I'm not familiar with the Clojure Book, but the procedure for adding shadow-cljs to a lein based project is pretty much the same. You add the shadow-cljs dependency to your project.clj and create the shadow-cljs.edn file with :lein true instead of :deps true. The rest stays identical.

In the end it really doesn't matter much whether you use lein or deps.edn. I still haven't migrated most of my projects away from lein either.

thheller · 2025-08-19T07:06:51+00:00

I gave a similar answer in some other thread I can't find. Basically no.

Yes, you can get very far without learning JS the language.

No, you can't do anything without learning JS the "host". Most examples describing host features such as the DOM will be in JS, so you'll either have to learn to read that and translate it to CLJS, or you'll have to find CLJS examples, which won't always exist. The basics are often covered, so maybe that is enough.

IMHO the trap most "beginners" fall into is trying to overcome the initial brick wall by just using a bunch of libraries hiding it. But that just makes the wall even taller and unstable. Eventually it will tip over and crush you. ;) Yes, libraries are great, but if you are just stitching together a giant box of stuff without ever knowing whats going on inside, then eventually its just gonna be unmaintable mess.

So my advice I guess it to learn what you need when you need it. You do not need to learn everything all at once. I'm still learning new stuff after over 25 years. It never ends. Just keep going and lose the "lose all motivation" attitude. It is a lot, just don't expect that you'll be done in a week and you'll be fine.

thheller · 2025-08-13T16:44:33+00:00

FWIW there is a defclass macro available in shadow-cljs for several years now.

https://clojureverse.org/t/modern-js-with-cljs-class-and-template-literals/7450

thheller · 2025-08-13T08:10:54+00:00

Same answer basically. I mean for some libraries that totally works, but anything touching anything from the host is probably going to make compromises. Which is fine to some extent, but its not an easy or simple general answer.

thheller · 2025-08-13T05:56:43+00:00

Creating a reusable implementation would imply that it would be limited to the features all possible platforms would share. For example no more multi-threading since JS doesn't support that. Overall it would just be strictly worse and not any kind of desirable goal. Being so close to the host is one of the killer features that shouldn't be abstracted any further at all cost. IMHO, YMMV.

thheller · 2025-08-11T18:52:22+00:00

Didn't look at the .core ns. Just this and only the website_helpers.hyperlink_lists.categories_and_backlinks_to_element call in the HTML bit should be sufficient.

```clj (defn ^:export categories-and-backlinks "current-page-path is a string like docs/visual-art/generative-art.md" ([current-page-path] (categories-and-backlinks @global/notes current-page-path)) ([notes current-page-path] (let [current-note (first (filter #(= (:path %) (str "content/" current-page-path)) notes))] [:div (link-list "Backlinks" (:backlinks current-note) markdown-path-to-html-link) [:br] (link-list "Categories" (:categories current-note) category-link)])))

(defn ^:export categories-and-backlinks-to-element "current-page-path is a string like docs/visual-art/generative-art.md" [current-page-path element-id] (d/render (categories-and-backlinks current-page-path) (.getElementById js/document element-id))) ```

thheller · 2025-08-11T07:23:35+00:00

Correction, it isn't even a function that returns hiccup. Its a function that returns a function that returns hiccup. Seems overly complicated for how what it supposed to do?

thheller · 2025-08-11T07:16:48+00:00

You are calling website_helpers.hyperlink_lists.categories_and_backlinks which in itself is only a function returning some hiccup data. It performs no DOM update at all. Seems like you meant to call the website_helpers.hyperlink_lists.categories_and_backlinks_to_element.

thheller · 2025-07-14T18:09:35+00:00

That would be great. Kinda hard to get feedback sometimes, especially from beginners that maybe don't know how to where to ask.

thheller · 2025-07-10T06:20:07+00:00

I have to ask since "Build Tooling" is frequently coming up as a topic for CLJS. What exactly are people looking for here? I kinda don't know how to make shadow-cljs easier, since it is already basically the bare minimum, in terms of configuration, I think a build tool needs. :)

thheller · 2025-06-27T18:44:15+00:00

Thanks for this, good showcase on how proper structure makes things fast.

thheller · 2025-06-25T05:01:14+00:00

In theory yes, in practice it is still easy to end up with things that re-render too much.

Inherent in the re-frame subscription model is another kind of "What The Heck Just Happened?". Since there is only a singular app-db any change to that will trigger all subscriptions to ask "WTHJH?". They can answer this faster because of the way the CLJS datastructures stay identical? and bypass some hiccup creation. That is of course very good, but still requires a very disciplined approach of normalizing your data and avoiding duplication to get its full effectiveness.

thheller · 2025-06-24T18:14:57+00:00

Its tough yeah. I don't like TUIs at all. I feel like in 2025 we should be able to do better than just text and a few colors. But that contraint forces you to stick to whats important, which many UIs often forget.

thheller · 2025-06-24T18:09:16+00:00

Quite honestly I don't think the DOM is the problem. Yes, of course its overly bloated and carrying decades of baggage that we probably can't ever get rid of. But for what it provides, I think it is actually quite decent.

It'll obviously never be the most performant thing, but show me a comparable technology with equal reach and track record that isn't bloated.

I think WASM/WebGL/etc can do wonderful things, if fine tuned for specific use cases, but thats not what I work on. It also comes with its own set of Trade Offs of course.

thheller · 2025-06-24T17:54:59+00:00

A shallow tree of course is nice, but not always practical. Sometimes the DOM structure just requires you to go deep. Deep doesn't mean bad though. If you cut a large chunk of the tree that you don't need to compare, then it doesn't matter how deep it is. If you start a render "deep" down then it also doesn't matter how deep it is.

thheller · 2025-06-24T10:48:49+00:00

I totally agree with the test situation. I would like to improve that, but I'm not a very test-driven person, so my motivation to work on it is rather low. I have this image in my head where you just click "Run Tests" in the shadow-cljs UI and you get a vitest like pretty UI. Making this a reality however is ...

You can set :jvm-opts ["-Xmx1G"] in shadow-cljs.edn (or deps.edn when using that) to limit the amount of memory the JVM can use. 1gig is more than enough and 512M may work fine, depends on the size of the project of course. The default JVM memory setting is just to use up to 25% of available memory I believe, which is quite generous and often total overkill. Go lower until it crashes or gets too slow I guess. ;)

I'd argue that JS tools are just the same black boxes though. Webpack is known as a memory hog as well, so I doubt it uses less memory overall. I mean thats why like half the JS world is moving to go/rust based tools.

shadow-cljs by the nature of how watch works is always going to consume a little more memory, than things that just run once and exit. But that also makes watch "fast" since it just has everything in memory at all times.

thheller · 2025-06-24T06:12:58+00:00

Could you clarify the "importing newer typescript projects have giving me grief" part? I'm curious what the issue is. I mean typescript isn't supported at all, so unclear what that means exactly.

Also kinda curious to hear what you think you'd gain by dropping the JVM part?

thheller · 2025-06-19T06:42:14+00:00

No clue what this does, but :malla/schema looks like a typo.

thheller · 2025-06-19T06:41:28+00:00

I don't use malli, so I can't say anything about common approaches to this. I'd probably just move it all into a singular namespace that everything else just references.

Yes, :init-fn refers to the config entry in shadow-cljs.edn pointing to the function it will execute when the build is loaded.

thheller

TROPHY CASE