Clojure Web Development - Things I learned from talking to people

Over the last +2 years I had a chance to talk to a lot of fantastic, kind, and generous people from Clojure community mainly about webdev — everything recorded at ClojureScript Podcast -https://clojurescriptpodcast.com

Here are some things I learned :face_with_monocle:

Idiomatic code👩‍💻🧑‍💻
A lot of people think that programming languages are syntax that you just learn and use, yet a lot of people forget that languages apart from syntax give you certain boundaries and affordances that are idiomatic for a specific language. You can write Clojure in OO fashion and you can write Java in FP — both of them will feel unnatural and unidiomatic. Not saying that FP is better than OO, or OO is better than FP; they are just different.

Manage your app state :spider_web:
The state of your application is where most of the complexity :spaghetti: comes from; Clojure is very disciplined about how you manage your application state. More in the Out of the Tar Pit paper by Ben Moseley and Peter Marks - https://github.com/papers-we-love/papers-we-love/blob/master/design/out-of-the-tar-pit.pdf

Try to leverage as much infrastructure :bridge_at_night: as possible:
Clojure is hosted on the JVM — so you can access all the libraries and get amazing performance of the JVM on the backend.
In the same fashion ClojureScript is hosted on the JS platform, so you can leverage the same language (Clojure) in the browser and access NPM (thank you @thheller for shadow-cljs) on the frontend.

Use libraries :books: and not frameworks :abacus::
Libraries, just as frameworks, come and go and it should be easy to compose and swap them; no lock-in :lock:. If you end up in a framework situation it’s hard to move away from and your codebase become more rigid.

Don’t break things💔
If you publish a library don’t make any breaking changes. If you need to depreciate things by all means do but don’t assume that people will move at the same pace as you do; you can always move the depreciated code no a new namespace and make an alias.

I still have tons to learn about so many things, yet if you would have any questions feel free to ask. I’ll do my best to answer.

10 Likes

Thanks for sharing! Sometimes I feel that there is not as much to read with ClojureScript, though that might be because of the incognito persona of Google Closure itself. Anyway, thanks for the podcast. I am eager to subscribe.

Those things you mentioned above are each several of the moment of maturity that Clojure can help developers to reach. Indeed there is so much above the “I know the syntax. I know the core library.” Yes, this can be said about all languages. But things that this community has doubled down on include “don’t break things” and “libraries over frameworks”, and that has been wise.

1 Like

Thanks for your comment. Could you expand a bit more on:

I feel that there is not as much to read with ClojureScript, though that might be because of the incognito persona of Google Closure itself

Sorry for being vague. I was referring to the startling lack of documentation on Google Closure. I know of reading the actual code base (not easy with code produced by Google since they love verbosity and OO), and their own examples page (assumably incomplete), and one book that was written years ago. ClojureScript has projects galore, but not a lot of quick read things. I think this is due to two obfuscating factors: Clojurescript shadows Clojure, so you don’t always get the one you are looking for when you search for stuff (the distinction is important in the web world, were dependencies and interop are so vital). And then, Clojurescript (at least, in my usage) is almonst always written with something like Reagent, which coopts DOM manipulation and is highly prevalent without actually being Clojurescript itself. Adding an almost-everywhere dependency at step one of “welcome” is bound to dissuade some newbies, making intro stuff one step less clear.