tl;dr: you can generate very small (less than 1k) JS artifacts from ClojureScript with some tradeoffs. I worked out a list of rules to follow and made the cljs-ultralight library to help with this.
Most of the web apps I build are rich front-end UIs with a lot of interactivity. Quite often they are generating audio in real time and performing other complicated multimedia activites. This is where ClojureScript and shadow-cljs really shine. All of the leverage of a powerful LISP with its many developer-friendly affordances (editor integration, hot-loading, interop, repl) brought to bear, allowing me to quickly iterate and build with fewer bugs.
On many projects I find myself also needing a small amount of JavaScript on a mostly static page. An example would be a static content page that has a form with a submit button that needs to be disabled until particular fields are filled. It seems a bit excessive to send a 100s of kilobyte JS file with the full power of Clojure's immutable datastructures and other language features just to change an attribute on one button.
In the past I resorted a tiny bit of vanilla JS to solve this problem. I have now discovered I can use ClojureScript carefully to get most of what is nice about the Clojure developer experience and still get a very small JS artifact.
Here's an example from the Jsfxr Pro accounts page. What this code does is check whether the user has changed a checkbox on the accounts page, and shows the "save" (submit) button if there are any changes.
(ns sfxrpro.ui.account)
(defn start {:dev/after-load true} []
(let [input (.querySelector js/document "input#update-email")
submit-button (.querySelector js/document "button[type='submit']")
initial-value (-> input .-checked)]
(aset submit-button "style" "display" "none")
(aset input "onchange"
(fn [ev]
(let [checked (-> ev .-target .-checked)]
(aset submit-button "style" "display"
(if (coercive-= checked initial-value)
"none"
"block")))))))
(defn main! []
(start))
This code compiled to around 500 bytes. It has since been updated to do a bunch of different more complicated stuff and today it compiles to 900 bytes. I'll talk about some of the special weirdness and language tradeoffs in a second, but first here is the shadow-cljs config I used.
{:builds {:app {:target :browser
:output-dir "public/js"
:asset-path "/js"
:modules {:main {:init-fn sfxrpro.ui/main!}}
:devtools {:watch-dir "public"}
:release {:output-dir "build/public/js"}}
:ui {:target :browser
:output-dir "public/js"
:asset-path "/js"
:modules {:account {:init-fn sfxrpro.ui.account/main!}}
:devtools {:watch-dir "public"}
:release {:output-dir "build/public/js"}}}
The first build target :app is for the main feature-rich app which does all the complicated stuff. I am fine with this being a larger artifact as it does a lot of things for the user including realtime generation of audio samples.
The second target :ui creates a file called account.js which is just 900 bytes. It gets loaded on the accounts page which is statically rendered. The reason for two completely separate build targets is otherwise the compiler will smoosh all of the code together and bloat your artifact size. It is easiest just to keep both codebases completely separate.
When compiling I found it useful to have a terminal open watching the file size of account.js so I could see real time when the size ballooned out and figure out which code was making that happen.
So what tricks do we have to use in the code to get the artifact size down? Here is a brief list of rules to follow to stay small. If you break any of these rules your artifact size will balloon.
- Do not use any native Clojure data types. Don't use
vecorhash-maporlistfor example. Instead you have to use native JavaScript data structures at all times like#js {:question 42}and#js [1 2 3]. That also means you will have to useagetandasetinstead ofgetandassoc. It means we are dropping immutablity and other data type features. - Do not use Clojure's
=operator. I know that sounds mad but what you can use instead is ClojureScript'scoercive-=. This function does a native-style surface level JavaScript comparison. This means you have to give up the value based equality comparison you can use on deeply nested datastructures in Clojure. - Do not use certain built-ins like
partial. Other clever built-ins likejuxtare probably going to be bad for file size too. As far as I can tell it's anything that uses immutable Clojure types under the hood. For the specific case ofpartialyou can use#(...)instead to do what you need. - Use
js/console.loginstead ofprint. - Use
(.map some-js-array some-func)instead of(map some-func some-js-array)
Generally as far as possible you should stick with native JavaScript calls and data types.
If all of this sounds onerous remember that the idea here is to only do this in situations where you have a small codebase giving the user some small amount of interactivity on a web page. So that's the tradeoff. You still get LISP syntax, editor integration, hot-loading, repl, and lots of other nice Cloure stuff, but you have to forgo immutable datastructures and language features like partial.
I have created a small library called cljs-ultralight to help with the UI side of things. It uses browser calls and returns JS data types. You can use it to perform common UI operations like attaching event handlers and selecting elements, without incurring too much overhead.
The library applied-science.js-interop also works with these techniques. Require it like this: [applied-science.js-interop :as j] and you can use j/assoc! and j/get and friends. Note if you use j/get-in or other functions that take a list argument, you should instead pass a JavaScript array which works well.
Also note that @borkdude has a couple of very interesting projects under way in this space. Check out squint and cherry for more details.
