But in a few short years that distinction became less clear as the industry collectively pivoted to larger and larger client-centric web applications built upon ever more complex dependency graphs and the tooling to make it work (sorta). Whether you wrote JavaScript, TypeScript, or ClojureScript, or used framework X or Y, these decisions amounted to choosing the color of the deck chair. When I started my current job last year, the company product required megabytes of bundled JavaScript and took seconds to achieve an interactive state.

A year and a rewrite later, our application can present 100X more data instantly yet we deliver only ~30K brotli of client code. Implementing UI features is faster as we don't need to wade through component APIs unaligned to our narrower use cases. We don't need to manage state in two different locations. We haven't spent any time designing and building a client API that's constantly evolving (polite for breaking) to fit business needs. We're certainly not fiddling with Node dependencies or babysitting the build tooling. There's still an incredible amount of work to be done, but a good chunk of incidental complexity and busy work vanished.

I don't believe that our experience is an isolated one. The growing popularity of HTMX, DataStar (we use this), and related approaches that look more like 2006 than 2026, show that developers who have retained their keen senses in an AI-pilled age are turning away from the current excesses and are out in the wilderness foraging for something simpler. Perhaps somewhere in that wilderness lie the ruins of a civilized age.

Start with a convivial use case I think one mark of a great tool is its suitability for convivial usecases rather than industrial ones. Years before I was paid to write ClojureScript, I just used it for fun on my blog. The gzipped bundle sizes of my ClojureScript examples were either smaller or comparable to minified and gzipped jQuery. These days that's positively slim, but I wanted to narrow the gap relative to handwritten, dependency-less JavaScript.

One idea I had floating around for a long time was a ClojureScript compiler mode that swapped in the simpler copy-on-write data structures from the original 2011 release rather than the sophisticated persistent datastructure implementations we faithfully ported from Clojure Java source files.

Last summer while pondering HTMX, DOM morphing, and DataStar, I started jotting down implementation notes in my decade old ClojureScript org file and tweaking the ClojureScript compiler late into the night.

Unraveling the knots It's only a half-joke that Clojure is a bunch of data structures with a programming language attached. In the early days, Clojure made a number of clever optimizations around these core data structures, and these optimizations were often strongly connected. That is, they don't play well with tree-shaking. For example, if you use cljs.core/PersistentVector, well then you need cljs.core/TransientVector and cljs.core/ChunkedSeq and cljs.core/ChunkedCons and, and ...

So writing an innocuous [] actually pulls in quite a few things. For server code this isn't very interesing, but on the client these interconnections get in the way of shaving off a few more kilobytes. ClojureScript had a lower bound of about 18 kilobytes brotli. Could we get that down to 12K? 8K? Less?

The other knot to untie in the code base was printing, because REPL stands for Read-Eval-Print-Loop. Because printing knows about every single data type including internal structures in some cases, (println "Hello world!") all by itself will pull in the entire standard library because, again, Clojure is a bunch of data structures with a programming language attached.

Ouch.

Art of the Metaobject Protocol I like to think that Clojure took a page from the Art of the Metaobject Protocol. Rather than design a Lisp on concrete datatypes as is traditionally done, Clojure erected a language on a rich set of interfaces. Later, ClojureScript was the first dialect of the Clojure programming language to be written on top of Clojure protocols. The beauty of this polymorphic library design meant that :lite-mode was largely a copy-and-paste affair, no significant changes to the standard library required. Most of the effort was in updating the 2011 implementations to match the broader expectations 15 years later. A few new protocols had been added and quite a few behavioral expectations from Clojure were captured in a number of tests.

Under :lite-mode, ClojureScript simply emits constructor calls to the old data structures. Google Closure advanced compilation will see that none of the more complex implementations are used and remove them.

For the case of printing, the answer was even simpler. Just elide the printing machinery. Recursive printing of ClojureScript datastructures is just dead weight for many simpler programs. Every data structure implements toString. If the user supplies the :elide-to-string compiler flag we simply drop those implementations.

What follows is the comparison table I maintained by hand in the org mode file during development. I haven't changed anything here at all and in some cases I don't even know what I was thinking anymore. expression is the ClojureScript expression. size is the actual size of the advanced compiled output. brotli is after compression. release is the baseline (the output of the main branch after brotli).

"surprising!" and "WHAT" comments indicate cases where Google Closure Compiler could see through the data structure implementation (easier with 2011 code) and optimize almost everything away.

The broad takeaway is that the main branch was already stunning. You really can fearlessly use the ClojureScript standard library and not worry about getting a bloated output. :lite-mode gets rid of the 18K wall, but the more you use the standard library the returns gradually diminish.

But this isn't a problem. ClojureScript provides great support for interacting with JavaScript objects and arrays. For more discerning users :lite-mode + :elide-to-string guarantees that the code size won't unexpectedly explode. Part of the changes included adding a bunch of tests that verify the size of programs under the new compiler flags avoid introducing unintended tree-shaking issues to the standard library. Even if many people never use these flags, everyone benefits from the analysis that was required to achieve these results. I'd like to a draw analogy with NetBSD. Most people are not going to run NetBSD on an Amiga, but as a result NetBSD is a simple and light system everywhere.

We need a lighter web, and ClojureScript is not a bad tool to bring along the way.

This is in direct contrast to how UNIX systems were historically organized where a user is offered a well curated set of tools for a wide variety of tasks. Determining the precise boundaries of "a useful set of tools" requires a great deal of restraint and a proclivity for "N-O".

Some operating system distributions decide that programming language X should be a part of the distribution because someone decided that some aspect of the system required X to work. This inexorably leads to the situation where a great many people convince themselves that isolation via a virtual machine is neccesary for Getting Things Done.

More technology will never solve what ails us.

In contrast, NetBSD depends only on its own implementation of the Bourne shell. It also picks a good set of tools for serving websites without ceremony, living up to its name. This instance serves this website with the following three lines in /etc/rc.conf:

http=YES
  httpd_wwdir="/var/www/prod"
  httpd_flags="..."
  

Ok, but how do we get anything up there?

Emacs ships bundled with one of the greatest pieces software ever written, org-mode. org-mode is a powerful writing tool that makes good on the potential for computers to offer something substantial over the greatest invention in all of human history - pen and paper. Publishing is integral part of writing, thus org-mode includes a generalized publishing mechanism, ox-publish.

The only thing missing out of the box for my purposes is HTML generation for code snippets. This can be accomplished with htmlize, just 77K of elisp without any further dependencies as the gods intended.

But how to use this stuff?

Rather than forcing org-mode users to go searching for food on the web like animals, Emacs shares the UNIX philosophy that the system itself should provide high quality comprehensive documentation. For UNIX that's man, for Emacs, M-x info. The first few org-mode pages on publishing in Emacs offer a snippet which I modified that provides everything a user needs to immediately generate a static site:

(setq org-publish-project-alist
  `(("posts"
  :base-directory       "posts"
  :base-extension       "org"
  :publishing-function  org-html-publish-to-html
  :publishing-directory "_site/posts")))
  

I can immediately focus on what I'm going to write rather being drawn to fiddling around with knobs that don't have much to do with writing. Later, I can figure out how to add custom CSS, site structure, a post index, entry customization, yet none of those concerns are placed before me at the beginning.

As a user I'm given a seed and I can tend to it. As I make progress, I look up and become more curious how others have tended to their plots.

Exploring these tools is like walking through a beautiful community garden.

For more information about the httpd server built into NetBSD and this is a really good article on using Emacs to write a blog.

What happens if we apply this thinking to software engineering?

In the States at least, we continue to be enamoured with scale and metrics because quality is a convivial concept. A craftsperson, unlike a factory worker, has their local reputation to uphold. A craftperson will of course make practical judgements about labor, materials and time, one needs to put food on the table after all. But in the end, the work cannot only be about quantifiable things. We live on Earth and we are surrounded by Beauty far beyond the scope our abilities to recreate. We have an Ideal, why we restrict ourselves to useful but crude results?

I am reminded of my recent travels in Japan and how it differed from my experience dining out in New York. Most Japanese restaurants have very few seats and often only one cook and one server. If the place is small enough, no server, the cook will serve you. Places fill up quickly. But neighborhood restaurants in Japan are like flowers. The next one will be different, but no less delightful, and you will never get to try them all. This convivial approach to running a business scales in a way that is difficult I think for a great many people in mainstream software to understand.

Take for example that this blog runs on NetBSD 9.2, an operating system released 5 years ago. NetBSD can fit onto a single CD-ROM. It can serve websites off a Nintento Wii which offers only 128mb of RAM. By choosing to be runnable on a large number of "obsolete" systems, by setting limits, NetBSD in fact guarantees that it runs incredibly well on newer systems, just not the latest systems. If we collectively believed that computers should be good for 10 or 20 years this wouldn't be a problem and we wouldn't filling ewaste landfills in Africa at volumes that make most post-apocalyptic films watch like fairy tales.

This not a claim that NetBSD is the answer. The point is that convivial computing focuses on systems that don't require generative assistance because the system is too damn simple - your favorite search engine and a couple of simple prompts in your favorite chatbot will take you the whole way. After that hopefully you write a blog post documenting your exploration so that the next person can save us all some fresh water. And then maybe we get a community and that garden starts to flourish.

Speaking of Software Sausage Factories, convivial computing is not Resonant Computing. The idea that corporate generative chatbots would allow individuals or communities to achieve more agency is like believing nuclear warheads are the right answer to a minor case of ant infestation or the demolition of a small abandoned house. Furthermore, in an ideal world where children didn't fail, one could imagine the vast majority of people using such tools responsibly but don't hold your breath. Adding more technology has never been and never will be an answer to what truly ails us.

Convivial computing is an intentionally vague concept. There are far more technologies that align with the values described above then I will ever have time to explore, and there are communities with similar values that inspired me to more actively write about technology again.

Expect contradictions, expect mistakes.

Hello.