Wishlish for Santa

tl;dr:

  1. Simplicity of the tech stack to run a full-stack “Hello world”. Emancipate from Java and Clojure.
  2. Tooling to support editing the “hello world” into something else. Emancipate from Emacs.
  3. Compatibility with modern deployment options, e.g. serverless. Emancipate from the server.
  4. Comprehensive examples for beginners to start from a working environment, especially for full-stack & serverless. Emancipate from the appalling documentation (some documentation is always necessary).

In the spirit of Christmas Mary Poppins, I have decided to make a list of nice things to have for beginners in ClojureScript. The kind of things that cause friction and put me down, honestly. It may be different for other beginners. It may be useful for anyone wondering “What do beginners struggle with?”, or how to help beginners to get up to speed with ClojureScript. Hoping this is useful for anyone.

The first problem is the dependencies from the tooling for Clojure and Java. Doing full-stack in Clojure & ClojureScript was nice because it allowed the use of the same language, reducing cognitive load when compared to Java & JavaScript (or anything & JavaScript). Today, Node.js allows for JavaScript in the backend, and using Clojure & ClojureScript comparatively increases the cognitive load by having not two languages but two tech stacks. Lein and the rest of the tooling for Clojure is wonderful, but it needs to be redundant for full-stack ClojureScript projects.

The second is the dependencies from the tooling for Emacs. IIRC: Try to install Cava, the recommended and possibly most comprehensive plugin for VSC, the most popular IDE, and if you happen to be using the vim keyboard configuration you are basically greeted with a “uh, oh, you should not have done that…” There are good tools for well supported languages, but the two most important IMHO are:

  1. Reformatting when saving, which should include parinfer IMHO.
  2. Linting while writing (or occasionally), highlighting found problems like unused dependencies and efficiency problems (accessing members through reflection was one of the potential performance problems IIRC).
  3. Code navigation and more advanced features are also nice to have, as long as they do not conflict with developer choices and other tools.

In fairness, these tools exist. What is missing is an easy unopinionated integration with ClojureScript and non-emacs IDEs (esp. VSC e.g. when using vim keyboard settings).

An easy way to address all of this would be easily runnable “hello world” projects. They should look like this:

  1. git clone <hello_world_url> && cd hello_world
  2. yarn install && yarn run

Before:

  • Requirements: git, yarn (which already includes node.js).
  • Nice to have: popular IDE with a non-conflicting plugin.

i.e.

  1. It should be a clone & run approach, not a RTFM with a few thousand setup & config steps.
  2. To make this possible, two things are required: a simple tech stack, and examples that use it.

Also nice to have: yarn build:production, exporting to JS, to deploy easily in serverless platforms, like Google App Engine, Amazon Lambda, Supabase, Vercel, Netlify, surge.sh, GitHub pages, etc. The final conversion to JS is a significant friction point, e.g. see online tools like CodePen, allowing to share code snippets in languages compiling to JavaScript easily, but not ClojureScript. Jamstack and static pages are probably a nice way to have something nice to attract beginners, with the equivalents of Gatsby and Eleventy, but until the serverless part is similarly seamless, other languages compiling to JavaScript will keep the upper hand.

In summary:

  1. Simplicity of the tech stack to run a full-stack “Hello world”. Emancipate from Java and Clojure.
  2. Tooling to support editing the “hello world” into something else. Emancipate from Emacs.
  3. Compatibility with modern deployment options, e.g. serverless. Emancipate from the server.
  4. Comprehensive examples for beginners to start from a working environment, especially for full-stack & serverless. Emancipate from the appalling documentation (some documentation is always necessary).

The syntax and semantics of the language were never a problem. Clojure for the Brave and True is more than enough to be able to read Clojure and ClojureScript code, and there is in general a healthy community for questions, reading code examples, open-source projects, etc. Rather than writing hundreds of pages about how wonderful the feedback loop is with Figwheel (so that beginners will be motivated to cross the chasm to the Clojure world), just throw it in for free in the welcome package git clone && yarn start .

I can imagine among the usual responses there will be something like: “that is not the Clojure way, here we favor configuration over convention”, which, fair enough, you do you. I simply wanted to mention that the advantage of Clojure & ClojureScript for homogeneous full-stack was a good moat, and made the moat keeping beginners at bay perhaps even necessary. “Linux is user-friendly and selective with its friends”, and so was Clojure, and that is perhaps good; selectivity favors quality over quantity. But with Node.js that moat was destroyed, and the quality-quantity balance broke. I think Clojure and ClojureScript are still much better languages than JavaScript, and other languages compiling to JavaScript, but there is strength in numbers, and without addressing these friction points for beginners, I think ClojureScript will gradually slide into irrelevance, which is sad, being probably the best front-end language we will ever see. A possibly fair but unexpected criticism of this post could be “thank you captain Obvious/Hindsight!”

In any case, as I said, I hope this helps.

PS: possibly all of this exists, but there is a “needle in a haystack” feeling to it.

3 Likes

it’s probably too early to get them this Christmas… but maybe the next one after that?

  • for points 1,3 and 4 - squintjs and cherryjs would the project to contribute to if you want to take out the JVM completely.
  • for points 2, I personally really like emacs but I feel like cider has gone too bloated and I’d love to be able to try out something a bit more heavyweight than GitHub - sanel/monroe: Clojure nREPL client for Emacs

Cool:

I wonder if Squint could use immutable data structures rather than warning about potential mutability. The static analysis to detect when it is necessary may be challenging, it would be:

  1. Unsafe data structures.
  2. Passed to unsafe functions.
  3. Used after that.

Feels like Rust.

@trylks totally, though js already has gc so it’s not that necessary.

However @borkdude’s compilers can potentially target GitHub - alshdavid/BorrowScript: TypeScript with a Borrow Checker. Multi-threaded, Tiny binaries. No GC. Easy to write. and https://www.assemblyscript.org for WASM targets

Conjure and Nrepl is a very smooth experience in Neovim (but Vim - like Emacs - has a steep learning curve)

I think Calva + VSCode is a very nice option for anyone who doesn’t want to fiddle with their editor constantly.

1 Like

Because Squint is close to the JS ecosystem you could use Immer with it to give you immutable data structures. Everything can run through Babel/Webpack or any other JS build tool because it’s just JS

1 Like

On my wish-list is Nrepl support for Squint and Cherry. I think that would take my JS projects to the next level

Working on it, will probably take a while as I’m also maintaining other projects, but nREPL for cherry / squint is certainly the plan.

3 Likes

It will be interesting to see howthe documentation and standard practices propagate through the Internet…

There is so much documentation written on “the old ways” of doing things, it may take decades for models like ChatGPT (hot now) to learn the new ways and answer according to that.

I mean safe wrt mutability, not memory allocation.

Or immutable

can you give an example of the warning? I’m not a big fan of compilers doing that as it treats programmers like infants.