I highly recommend devs (especially JS devs) try out a Clojure/script project. The tooling has improved immensely, and Cursive is one hell of an IDE. JS devs will really appreciate how clearly you can express these seemingly new frontend paradigms (immutability, one way data flow, single source of state) in Clojure.
Not to mention that REPL-driven development and hot-reloading are so pleasant to work in, leading to development environments like this: https://github.com/danielsz/holygrail
I'm curious if any Clojure veterans would weigh in on the state of Boot.. is it gaining traction, or is the consensus to stick with Leiningen?
Trying out Clojure/Script is really too. I recommend starting with Reagent https://reagent-project.github.io/ as it has a minimal API and requires learning only a handful of concepts. Here's all you need to get started:
This will start the live ClojureScript compiler and your app will be available at localhost:3449
You can now navigate to the src/cljs/myapp/core.cljs file and start editing it. Any changes you make will be reflected live in the browser without having to reload the page. I recommend trying the code from the Reagent docs page linked above in the project.
I'm working on a React+ES6 project professionally, and use Clojurescript+Reagent for all my hobby projects. I would gladly use cljs+reagent for everything if I could.
First off, cljs allows you to type less. Second, functionality provided by Immutable.JS is built into the language. Third, I can use paredit. I love paredit. Fourth, google closure has amazing code minification, dead code removal and a good standard library. Fifth, I've found figwheel to be better to react-hot-loader, the latter cannot always reload my application. Sixth, devcards. Seventh, incremental compile speed is faster. Eight, macros can greatly simplify code you're writing and allow new syntax to be exposed by libraries (core.async).
But it seems that 4 out of your 8 points are covered by external libraries that are pretty good - Immutable is great... lodash is great... and google closure compiler is usable (https://github.com/mihaip/react-closure-compiler). I use systemjs/jspm as well as its hot reloader and it works great (unless a particular component is legacy JS.. which will be a problem anywhere).
Not really refuting your point, but ES6/ES7 (and from what I'm hearing.. Typescript) with all these libraries have sort of taken over the mindshare that clojurescript used to have.
IMHO the only reason for me would be the package manager. I mean Systemjs/jspm is okay.. but the whole AMD/global/cjs/webpack/requirejs/browserify crap is way too much. Nothing works anywhere in the javascript world .
Google Closure is usable, but only if you write your app in a way that is google closure compatible, the same goes for any dependencies you pull in. In clojurescript, all code you write, and any pure cljs library, is google closure compatible.
Immutable.js is great, but your libraries probably doesn't use it, and you have to make sure you use it everywhere as well. This can lead to subtle bugs that boils down to using .value instead of .get('value'), a problem you'll rarely encounter in cljs where everything is immutable by default.
I haven't used systemjs/jspm, so I can't say anything about that. I can only say that I have yet to encounter a case where figwheel doesn't successfully reload my code, whereas I encounter this in webpack/react-hot-loader all the time.
ES6/ES7/Typescript are great improvements over ES5. But you have to pair it with Immutable.js for it to be comparable to the offering that cljs provides. Even then, when you have a setup that gives many of the same benefits as cljs, you'll have written way more code, and you need to be a bit paranoid to make sure you're using the correct API at the correct place, and that you don't have any libraries that are incompatible with your setup.
In short. While you can have a setup that gives you all the advantages of cljs+om/reagent, it's just a lot easier to do it in clojurescript.
You are completely true. In fact I spent the last couple of days fixing some incompatibility issues with Handsontable - a very popular spreadsheet component.
But that's precisely my point. Is there value in a pure language when you will need to leverage tons of third party libraries...most of which are incompatible? To get anything meaningful done, you would need to write EVERYTHING in cljs...or you could use a component which will be in old js. So where's the tru value of cljs in a real life project.
Let's take Handsontable - to cover all the corner cases that a spreadsheet needs, it would take me an inordinate time. But it does not even play well with npm..forget cljs
I've done a fair bit of integration with handsontable from clojurescript. It has been excellent so far. Clojurescript isn't really a pure language, it just makes some types of purity the default. If you need to get dirty and mutable then that's simple, still simpler than plain js in my opinion.
Clojurescript and Clojure have very good interop with their host language, integrating 3rd party libs is very simple. To be fair, you will have to write the glue code more often than when working in js since there is a smaller user base.
Is your handsontable/cljs work open source? Would love to see it.
I have given up on handsontable being usable in a modern js setup. I had to fall back to including it in a script tag and get it to work. Am quite interested to see if I can build it in cljs
Unfortunately it's not, but I find out if that is a possibility.
And now that you mention it you have jogged my memory about having to sidestep our build process in some unfortunate ways. We're certainly not passing it through Google Closure, we have to use the handsontable build scripts to remove unused features.
Getting it to co-exist with React was the real tricky part, but Rum was quite useful in providing the hooks to make handsontable act like a react component.
The way you got handsontable to work in your setup. That would be awesome - that would be a good learning of how to integrate complex, legacy js packages in cljs.
Well, if you literally have to leverage TONS of third party libraries, most of which are incompatible, then I would at least be glad that my code, the ui framework, the date handling library, the routing library, the ajax and the validation library, was all written using compatible and immutable by default code.
It's better to have a problem with some dependencies, than to have an issue with your entire codebase. So yes, I would argue that clojurescript has value.
I was about to write a comment like Skinneys below, but he/she put it so well.
I found this joke on r/ProgrammerHumor and it strikes me that I've been falling into this trap for the majority of my career.
> You know what we need? Another mostly imperative garbage collected language, that's what. If we just tweak the syntax and feature set just right, it will change everything!"
As Skinney writes, the mix of libs and tools that you base your webapp on might not be what the libs you want to use the next months agree with.
Use of immutable collections are nearly pointless if only parts of your app use it, and you have to carefully maintain barriers that translate to/from them. Clojure(Script) makes their use succinct and natural, something I doubt yet another lib can make ES2015/TypeScript do.
I find ClojureScript to be far preferable. The language is much better designed in my opinion. It's simple and consistent, while being very flexible and expressive. from what I can tell it does everything ES6 does and more right now.
The biggest problem with ES6 is that JavaScript just keeps growing as a language. It has lots of features and quirks already, and more are getting added. This is what you end up dealing with when using ES6 + React (https://i.imgur.com/AjSTP20.png).
I think the problem with this is that it adds mental overhead when you're reading and writing code. Something that looks like it might be doing one thing does something subtly different. This leads to hard to debug errors and wastes you time. It also distracts you from the actual problem you're solving.
I also find tooling for ClojureScript is better in many areas. Instead of having to juggle things like npm, gulp, grunt, and so on. You can use a single build tool like Leiningen that handles all those things. You have a live coding environment with Figwheel, and you get an editor integrated REPL where you can inspect things easily at runtime.
I've been using ClojureScript in prod for about a year now without any issues. I simply wouldn't go back to using Js at this point.
I'm not a boot guru, so take my $0.02 with a grain of salt.
I've been using boot for smaller and experimental projects because by default it feels so much leaner then leiningen does, however, because the support tooling around leiningen is still so further advanced, for project we're putting into production here, those are still all lein based.
The other thing I'd say is, I've found what tool lein vs boot gets minimized over time as the project evolves.
In general, I do think it's gaining traction and its a great project!
I've done Clojure, but haven't had much contact in the last several months, and I haven't been keeping too close tabs on the community. Regarding Boot, I just heard of it the other day for the first time.
This all seems really exciting for Clojurescript. To me, it seems like it is a good option to have code that runs on multiple architectures. The ecosystem was lacking in some basics though, especially interacting w/3d party JS libraries, and I think CLJSJS (or something like it) will probably be one of the most important things for Clojurescript.
I have nothing to say on Lein vs Boot, but I'm a long-term emacers with > 10 years and I can't endorse Cursive strongly enough. I've got easily at least 1k hours in my .emacs.d. Suffice it to say, it takes a lot to take away from Emacs/SLIME. Never bought into the Textmate hype during the Ruby days, or the SublimeText hype subsequently because Emacs already had all that functionality if not out of the box, there certainly was someone with an .el I could borrow. It takes a lot for me to leave Emacs, especially for a LISP.
Here's my 2 cents - Cursive is worth it. (Hey Ideogram folks, if you want an endorsement, feel free to use that paragraph in exchange for a lifetime license ;)). For one-off-scripts, for back-end solutions, and what tipped me over the edge, it's CLJS script integration goes beyond acceptable -- it's actually fun to work in-- Cursive is my go-to. Om and Figwheel (optionally with Prismatic Schema if you like type guarantees) makes web development's feedback loop a lot tighter.
Rich Hickey assembled a team of just insanely talented and charismatic(1) developers who not only are a) remarkably intelligent but b) know when to steal ideas and integrate them [none of that too-proud-NIH-syndrome there], and c) know how to interact in a way to that is community-feedback-positive(2) so people contribute. Watch this talk by David Nolen https://www.youtube.com/watch?v=ByNs9TG30E8 (CLJS lead). [Sidebar - He even mentions how that whole immutable, one way data flow, datomic-ish single state idea existed in other languages, but read (2) on that].
Anyways, Cursive + Lein + ClojureScript + Om is the holy grail for me right now. On the other hand, that nREPL/cider/boot setup is what I'd be using as a long-time emacs'er were I to give up Cursive.
(1) Having someone like Hickey or Nolen to shepherd ideas is actually really important in garnering traction. Developers go to conferences and when everyones talking about that 4PM Thursday talk that someone gave, it really resonates within the community for quite a while. I like Perl 6's ideas but if you've ever seen Larry Wall talk, well, yeah.
(2) Some communities cough Haskell have great ideas, Lenses, FRP, applying (pun not intended) monoids -> functors -> applicative functors -> monads was genius. But for some reason the barrier to entry is so high (even for me with a fairly advanced math background) that concepts remain isolated within the community. LINQ is a monad (though few know it) and it took Brian Beckman (or Anders, or Bart de Smet, or whomever) to take it into C# to make the concept widely used by the Joe-the-programmer (again, pun not intended).
Hey Ideogram folks, if you want an endorsement, feel free to use that paragraph in exchange for a lifetime license ;)
Well, I'd hate to be accused of buying positive reviews :-). But thanks, I really appreciate it and I'm glad it's working well for you.
One of my main goals for 2016 is to focus heavily on CLJS support to bring it fully up to par with Clojure support. Better REPLs, a much easier getting started story, testing support, a debugger, and as much support as seems to be required for React Native. I'm increasingly convinced that CLJS may turn out to be more important than Clojure, and certainly has the potential to bring a lot more devs to the CLJ(S) world if it manages to take off properly.
One of my main aspirations with Cursive is that it can help make both languages more accessible. I think Clojure support in Cursive is further along that path and I'm hoping to do the same for ClojureScript this year.
I've been a vim user for a number of years and have fiddled with building in Clojure support at different times with repl support, syntax highlighting and other basics. My success was varying and incomplete. Tooling has been a barrier for me learning Clojure. Half the time I want to learn or practice Clojure, I remember gaps in my tooling. Subsequently, I spend a few hours yak-shaving to improve it.
I've contemplated learning Emacs because of the general praise for its workflow in the Clojure community. I even know some basic emacs from bash scripting. Switching just seemed like it would add another learning block to an already long list of tools to learn. Cursive, on the other hand, is based on IntelliJ, which is familiar to me through RubyMine.
Thanks for taking the time to write up about Cursive. You just convinced me to finally install it and give it a shot.
I've been using boot for about 6 months now and it's wonderful ... for doing build tasks (take my source and create some artifacts). Especially with the improvements just released in boot 2.5.
You will want to understand how pods and filesets work if you are doing anything interesting, as some interactions with them can be confusing if you don't have the right mental model. The wiki is quite good, but the source is a bit messy.
For code reloading type tasks things are bit less nice, mostly because of the immutable nature of pods and filesets that make build tasks so trouble free. That means incremental cljs compilation, cljs repls and auto-test type tasks (for clj and cljs). We have transitioned to just using functions run from the repl to manage our clojurescript tasks and it has been a big improvement.
How does ClojureScript/Reagent/Om/etc interoperable with "legacy" (heh) React + Webpack projects? I'd be interested in using our existing "dumb" React/JSX components with one of these new "Graph-Query-View" systems (Clojure or plain-old-JS)
Not to mention that REPL-driven development and hot-reloading are so pleasant to work in, leading to development environments like this: https://github.com/danielsz/holygrail
I'm curious if any Clojure veterans would weigh in on the state of Boot.. is it gaining traction, or is the consensus to stick with Leiningen?