ClojureScript has been hailed as the language that brings functional programming to the web. The blog has listed the following reasons for using ClojureScript: dommy, a "fast" ClojureScript templating engine, which they have benchmarked to be 38% slower than jQuery, even with the strange usage of multiple jquery functions chained together. They state the expressiveness, and the functional paradigm design of ClojureScript as the tradeoff for using a slower templating library, i.e. using code as data in macros.

In other words, they want a Lispy Javascript, with Clojure syntax, which is what Wisp aims to be.

The idea that having the same language for the client and backend is nice, which is all Meteor about, but using Clojure and ClojureScript for development? With JavaScript occupying front end development, and nodejs steadily gaining popularity while being used to create native applications, with frameworks like electron (which the kobito app I'm typing on is based on) and cordova, gaining popularity, one might wonder where ClojureScript fits into all of this.

The fact is, it doesn't. While ClojureScript itself can use JavaScript libraries, core mechanisms of ClojureScript, including immutable data structures and functional programming, does not gell well into the already present JavaScript framework. Clojure itself cannot use any of the npm modules, which in quantity and quality is increasing, to support both ends of web development, which is not what Java is going to be.

Java has risen in popularity due to the rise of the Android framework, not web development. The fact that we're trying to use Clojure for the back-end and ClojureScript fo the front-end while the rest of the world is moving on with npm modules and javascript is just showing how stubborn we are against fighting a losing battle. As this StackOverflow answer puts it,

"Any new language can only succeed if it capitalizes on an emerging frontier in computing".

Javascript has taken over the web, and is rapidly becoming the byte code of the web itself. Clojure itself shouldn't be aiming for this niche. Python aimed, and failed to takeover much, settling instead into scientific programming. Ruby tried with Rails, and look how much we're mentioning RoR nowadays. Even for both languages they didn't even try to take over the browser programming niche, because JavaScript has won, hands down.

Clojure is a nice language, and I have a special liking for it, as it includes many neat ideas, but it shouldn't be aiming for the web, unless it could, one day inter-op with Node JS.

The other thing is the speed of development with ClojureScript. It requires a delicate Java enviroment, and the startup of the Java VM before anyone could start doing something productive with it. Loading the Java VM is slow and unwieldy. Starting the whole process just to plug in some code for an interactive webpage is not something you want to do. Nowadays, none of the OSes ship with Java, which is not something you want when shipping your app. Users expect your app to run out of the box, not needing them to install Java or worry about compatibility problems.

Besides, if we wanted to use the Google Closure Library, why not just import it into the webpage like any other JavaScript library? Google Closure itself is not a reason why we should be choosing one over the other. Javascript itself is very expandistic, as said in this blog post. There is nothing we can't do in ClojureScript that JavaScript can do, even porting ClojureScript immutable data structures.

JavaScript has it's shares of problems, but really we should be looking into a language that offers the same power of ClojureScript, i.e. code-as-data-as-code and JavaScript, i.e. extreme flexibility.

Enter Wisp.

Wisp is a Lisp dialect that compiles to Javascript, runs on Node and can be used in the browser with Browserify. Node starts up instantly, or at least faster than Leineigen. Wisp has seamless interop with JavaScript, since it is compiled to something like handwritten JavaScript. I could imagine how the Closure Compiler could optimise it even more.

The best thing is, Lisp macros are still available since it is an homoiconic JavaScript with Clojure syntax.

It is, by definition, supercharged JavaScript.

Need Clojure immutable structures? Require Mori.
Need more functional programming tools? Require Hu, or Ramda, or lodash-fp.
Need AngularJS for templating? Require Angular.

We could use any of the JavaScript libraries available for the front-end and back-end by web developers around the world without worrying about inter-operability, unlike Clojure and ClojureScript for the web.

Also, the Wisp compiler is self hosting, and could be compiled down to an executable that you can run in any environment. All of this adds to speed up development speed.

While the language itself is only in the early alpha stages, it only requires the development of the core engine since the libraries are already written for it. I see hope in Clojure ideas for the web, but not through the JVM, but JavaScript itself.