How it feels to learn ClojureScript in 2016

flyboarder
degree9
Published in
7 min readDec 11, 2016
ClojureScript Logo

The following is inspired by the article How it feels to learn JavaScript in 2016. Many of the following sections are taken from that post and related to ClojureScript.

I need to create a page that displays the latest activity from the users, so I just need to get the data from the REST endpoint and display it in some sort of filterable table, and update it if anything changes in the server. I was thinking maybe using jQuery to fetch and display the data?

-Oh my god no, no one uses jQuery anymore. You should try learning React, it’s 2016.

What? That’s not entirely true, jQuery has been around for a while and it probably will be. It’s even on the W3Schools Website. It may not get as much production use these days, it does still have decent learning value.

Oh, OK. What’s React?

-It’s a super cool library made by some guys at Facebook, it really brings control and performance to your application, by allowing you to handle any view changes very easily.

It’s 2016 and the Internet has evolved a little bit, why are we jumping straight to another JavaScript library? There are other flavours of JavaScript these days. More importantly there are other flavours of Lisp, ones that can efficiently compile to JavaScript. Im talking about ClojureScript.

ClojureScript is a compiler for Clojure that targets JavaScript. It emits JavaScript code which is compatible with the advanced compilation mode of the Google Closure optimizing compiler.

But anyway let us continue…

That sounds neat. Can I use React to display data from the server?

-Yeah, but first you need to add React and React DOM as a library in your webpage.

Wait, why two libraries?

Well these days that is fairly common, most projects are well organized into little bits of functionality so app’s can be as small as possible. With ClojureScript we get advanced compilation which does things like whitespace/comment removal, function and variable renaming/shortening, dead code removal and global inlining.

-So one is the actual library and the second one is for manipulating the DOM, which now you can describe in JSX.

JSX? What is JSX?

-JSX is just a JavaScript syntax extension that looks pretty much like XML. It’s kind of another way to describe the DOM, think of it as a better HTML.

Why are we adding another language to our application? Syntax is bad. This might be difficult to accept but syntax limits what you are able to express in a language. Think of writing English, our basic syntax is Paragraphs and Sentences. This gives us a lot of freedom as to how we can express ideas, as the order of words has minor significance. In other languages such as German, the order of words is much more important which is why you will run into issues where you cannot directly translate between the two.

When building applications in Clojure and ClojureScript you have the ability to work in the same language (with minor differences) on both the client and the server. This is one of many ways you get to improve how you build applications by not just using JavaScript.

What’s wrong with HTML?

-It’s 2016. No one codes HTML directly anymore.

Also not true. If you are using React, chances are you are doing something like this. Fragment Injection. Sometimes things don’t change for the better.

If you build applications this way, I would like you to forget all that you know and watch the MIT Video Lectures on Structure and Interpretation of Computer Programs.

Ok now that we have that sorted out let us continue…

Right. Anyway, if I add these two libraries then I can use React?

-Not quite. You need to add Babel, and then you are able to use React.

Another library? What’s Babel?

-Oh, Babel is a transpiler that allows you to target specific versions of JavaScript, while you code in any version of JavaScript. You don’t HAVE to include Babel to use ReactJS, but unless you do, you are stuck with using ES5, and let’s be real, it’s 2016, you should be coding in ES2016+ like the rest of the cool kids do.

Here is something the JavaScript guys got right! Babel. But this post is about ClojureScript, well as it turns out the Google Closure Compiler allows you to specify which version of JavaScript you want to output, ECMAScript6 already included.

-Well, you include those three libraries but bundle them up with a module manager to load only one file.

I see. And what’s a module manager?

-The definition depends on the environment, but in the web we usually mean anything that supports AMD or CommonJS modules.

Riiight. And AMD and CommonJS are…?

-Definitions. There are ways to describe how multiple JavaScript libraries and classes should interact. You know, exports and requires? You can write multiple JavaScript files defining the AMD or CommonJS API and you can use something like Browserify to bundle them up.

I’m gonna mention ClojureScript here again. Using a Clojure build tool like Boot or Leiningen. Will manage all of this for us, as well as compile our application, interaction directly with the GCL is not required.

OK, that makes sense… I think. What is Browserify?

-It’s a tool that allows you to bundle CommonJS described dependencies to files that can be run in the browser. It was created because most people publish those dependencies in the npm registry.

In future versions of ClojureScript, the compiler will be able to compile AMD and CommonJS modules.

npm registry?

-It’s a very big public repository where smart people put code and dependencies as modules.

ClojureScript can take advantage and utilize pure Clojure libraries, Reader Conditionals allow code reuse directly within the file which is specific to each language or usable by both. Because of this they share the same package repository Clojars.

Angular would be there, alongside VueJS or RxJS and other cool 2016 libraries. Want to learn about those?

Let’s stick with React, I’m already learning too many things now. So, if I need to use React I fetch it from this npm and then use this Browserify thing?

This is my favourite thing about ClojureScript, you have access to all of JavaScript, thanks to the CLJSJS team, you include them like any other ClojureScript package.

That seems overly complicated to just grab a bunch of dependencies and tie them together.

-It is, that’s why you use a task manager like Grunt or Gulp or Broccoli to automate running Browserify. Heck, you can even use Mimosa.

Grunt? Gulp? Broccoli? Mimosa? The heck are we talking about now?

-Task managers. But they are not cool anymore. We used them in like, 2015, then we used Makefiles, but now we wrap everything with Webpack.

I’m going to stop you right there, by using Boot we get tasks built with Clojure. We get the full expression of the Clojure language when building our applications, were not just building apps anymore, we are building apps that build apps.

Sigh. You mentioned something called Webpack?

-It’s another module manager for the browser while being kind of a task runner as well. It’s like a better version of Browserify.

Oh, Ok. Why is it better?

-Well, maybe not better, it’s just more opinionated on how your dependencies should be tied. Webpack allows you to use different module managers, and not only CommonJS ones, so for instance native ES6 supported modules.

At this point, as we already discussed, this is a none issue. Boot gives you all the things you need to interact with existing build tools and the GCL gives you everything you need to interact with JavaScript libraries and frameworks. Everything is just Clojure(Script) now.

Wait, so can’t we just add the three original libraries for React??

-Not really. I mean, you could add them as external scripts from a CDN, but you would still need to include Babel then.

Sigh. And that is bad right?

-Yes, you would be including the entire babel-core, and it wouldn’t be efficient for production. On production you need to perform a series of pre-tasks to get your project ready that make the ritual to summon Satan look like a boiled eggs recipe. You need to minify assets, uglify them, inline css above the fold, defer scripts…

More things that can be replaced by Clojure and Boot…

I got it, I got it. So if you wouldn’t include the libraries directly in a CDN, how would you do it?

-I would transpile it from Typescript using a Webpack + SystemJS + Babel combo.

Typescript? I thought we were coding in JavaScript!

Finally! I was waiting for another flavour of JavaScript to popup. But look at the level of complexity you got to before this point. ClojureScript takes care of all of this, all of this is ClojureScript. Have I made my point yet?

-Typescript IS JavaScript, or better put, a superset of JavaScript, more specifically JavaScript on version ES6. You know, that sixth version we talked about before?

I thought ES2016+ was already a superset of ES6! WHY we need now this thing called Typescript?

-Oh, because it allows us to use JavaScript as a typed language, and reduce run-time errors. It’s 2016, you should be adding some types to your JavaScript code.

I’m gonna say you shouldn’t be doing that. Instead you should realize that everything is data and you don’t need types. But if you want it Typed Clojure does exist.

-Flow as well, although it only checks for typing while Typescript is a superset of JavaScript which needs to be compiled.

Sigh… and Flow is?

-It’s a static type checker made by some guys at Facebook. They coded it in OCaml, because functional programming is awesome.

OCaml? Functional programming?

-It’s what the cool kids use nowadays man, you know, 2016? Functional programming? High order functions? Currying? Pure functions?

I completely agree! Functional Programming is awesome, and thats what Clojure is all about! This is one of those “the answer is staring you in the face” moments.

At this point I feel like I am beating you with the Clojure(Script)/Lisp stick.

If you want to learn how to really build applications grab tickets to ClojureRemote 17:

--

--