
ClojureScript Year in Review - pella
http://swannodette.github.io/2015/12/23/year-in-review/
======
modarts
Clojurescript has made me excited about frontend again.

------
dmohs
I think that cljs-devtools [1] also deserves honorable mention. Not only does
this improve console output, but it improves inspection while doing
interactive debugging (e.g., pause on exception) in Chrome.

[1] [https://github.com/binaryage/cljs-
devtools](https://github.com/binaryage/cljs-devtools)

~~~
dr_win
Thanks for the plug. I'm glad you find it useful.

I've been working on Dirac - a Chrome DevTools fork for ClojureScript
developers. That will be a complementary tool to cljs-devtools:
[https://github.com/binaryage/dirac](https://github.com/binaryage/dirac)

------
keldlundgaard
For devcards, you can see the full strangeloop talk about the tool here:
[https://www.youtube.com/watch?v=G7Z_g2fnEDg](https://www.youtube.com/watch?v=G7Z_g2fnEDg)

~~~
swannodette
I meant to link to that one actually. Thanks for the catch, post updated.

------
wiineeth
Really intresting clojure and clojurescript seems to be wonderfully designed
and with the advancements that's going to take place in jvm I hope it can be
as good at performance as java or Go.

~~~
yjgyhj
I don't know about Go, but it certainly is as fast as Java. And it can
definitely be faster than your average Java program, because you will have a
really easy time doing concurrency. That is why it is a neat language, worth
investigating.

It is by default slower than Java and Go because the default data structures
are immutable. When execution speed is more important than statelessness you
can make your data structures mutable.

Read more about that here
[http://clojure.org/transients](http://clojure.org/transients)

Happy holidays :)

------
cnp
Parinfer is the craziest lisp exponent ever. I highly recommend any curious
and / or skeptical dev to download Atom, install it, and give it a shot. This
book also helps: [http://funcool.github.io/clojurescript-
unraveled](http://funcool.github.io/clojurescript-unraveled)

From straight up confusion to basic productivity in just a week, it has also
completely removed the learning fear. Highest regards to this beautiful tool
that will hopefully bring lisp to the masses.

~~~
chrisoakman
Thank you for the kind comment :) I'm glad you like atom-parinfer!

------
idibidiart
ClojureScript will enrich your mind but at some point you might get tempted,
as I have, to switch to ES6/7 via the Babel route and enjoy the benefits of a
much more diverse ecosystem, with your ClojureScript-enhanced perspective.
Same with Elm and Haskell and prefty much any language wortg learning. In
fact, learning a new language esp one drom a different world will always
expand your horizon and I can't over recommend ClojureScript as one of those
enlightenment languages.

~~~
yogthos
I switched to using ClojureScript in prod last year and couldn't be happier.
The Js interop is great, ClojureScript is fast, and the runtime is pretty
small. I simply can imagine any reason to bother with ES6/7 at this point as
they will offer nothing that's not already available in ClojureScript right
now.

You also get a clean and well designed language as opposed to a mountain of
kludges that is current state of Js
[https://twitter.com/capotej/status/677926991513780225](https://twitter.com/capotej/status/677926991513780225)

------
jhund
I'm exploring ClojureScript via the re-frame SPA pattern and it got me really
excited about UI development again. What's the best way to sync data with a
REST server backend?

~~~
_halgari
I recommend the following: 1) read up on how Om.Next handles remote calls. Not
that it's the only way to do it, but it de-couples the async functionality of
a remote call from the rendering loop. 2) Just code against something like
Google Closure's XHR libraries, making a HTTP call isn't complicated, just
wrap basic functions to suit your needs.

But over all, no matter what you use, core.async, or callbacks or whatever,
limit the async bits to the edges of your code. Done correctly (Om.Next is a
great example) you shouldn't need a whole lot of async bits to get a nice
clean app. If you have core.async "go" blocks littered all through your
codebase, you're doing something wrong.

------
neoncontrails
Diving into clj/s 4 months ago was such a wonderful, arbitrary decision. The
#clojure community on Freenode is friendly and wildly clever. They are
delighted to answer your Clojure questions. The language itself is great. It's
a terrific language for a CS Sophomore to pick up after learning Scheme and
Java.

My one complaint with cljs has been the difficulty of configuring Ring HTTP
beyond the trivial SPA defaults: getting it to respond to other URL requests,
other types of HTTP requests. I spent close to 3 hours trying to configure it
to accept a POST action before finally giving up, frustrated by the opaque
stack traces that went >1000 frames deep. 20 minutes later, I had an Apache
server up and running. So it wasn't really a big deal, but I can't remember
the last time I felt so baffled by a problem that I simply had to throw in the
towel.

~~~
yogthos
I put together the Luminus micro-framework
[http://www.luminusweb.net/](http://www.luminusweb.net/) to help with this
kind of stuff. The docs provide lots of examples on how to get stuff done. For
example, here's the section on doing Ajax with ClojureSCript
[http://www.luminusweb.net/docs/clojurescript.md#ajax](http://www.luminusweb.net/docs/clojurescript.md#ajax)

~~~
neoncontrails
Thanks for putting this together. This looks like a fantastic tool, and really
well-documented. I noticed from a quick perusal of the docs that Luminus still
requires a handler function to map URLs to a named page asset (about-page,
home-page, etc.) using defroutes -- requiring too, of course, definitions for
each of those pages. Could you explain in a few words why that is? Is it a
Node requirement? Isn't that a lot of complexity to have to deal with? If so,
how do people manage it?

I'm just curious because my only exposure to the HTTP layer so far has been
via Apache. Apache is... for lack of a better word, a bro. It's up for just
about anything. It seems like the default mode of Apache is to do whatever the
HTML recommends. Apache is happy to serve an arbitrary "/about.html" URL,
provided it exists, and asynchronously execute any server-side scripts to
which it injects a dependency. I don't know if this strictly requires the use
of jQuery, but it certainly seems easier to do it that way. Is it even
possible to serve a cljs app this way? In light of the fact that jQuery is not
compatible with the Google Closure compiler?

------
Touche
Very cool to see such a robust community.

As far as self-compilation, I haven't seen anything on how to compile a
ClojureScript project without Java, is there an article somewhere on how to do
so?

~~~
_halgari
One of the reasons that ClojureScript is so fast and efficient is that it
leans heavily on the Google Closure optimizing compiler. This compiler goes
beyond normal "minimzation" and goes into dead code removal, function inlining
and a ton of other stuff. That compiler is written in Java. So it's highly
unlikely that JVM is removed as a dev-time requirement anytime in the near
future.

On the other hand, I have never really seen a need to remove it. Once the CLJS
compiler is up and running, incremental compilations on huge codebases (~300
files) takes a fraction of a second. So in the end...I'd rather have the JVM
as a requirement if it allows that fast of a dev cycle.

~~~
pjmlp
Another reason is that is doesn't do all the things that standard Clojure
does, which are the actual cause for slowness, it is not the JVM.

[http://blog.ndk.io/2014/02/11/jvm-slow-
startup.html](http://blog.ndk.io/2014/02/11/jvm-slow-startup.html)

------
draw_down
They do seem to be doing really nice things. And from time to time I try to
keep up, watching videos on new tools and things.

But I guess I always get hung up on the idea that you should just write in the
language that you're targeting, and I wonder about the cost of the (admittedly
pretty nice) developer experience of cljs. When you have a bug in production
you're stuck debugging the generated JS. This was also my problem with
CoffeeScript.

~~~
yogthos
I've been using ClojureScript in production for about a year now. The runtime
is very fast, and in some cases it actually outperforms native Js. For
example, both Om and Reagent are actually faster than React.js itself
([http://www.youtube.com/watch?v=VSdnJDO-
xdg&t=9m36s](http://www.youtube.com/watch?v=VSdnJDO-xdg&t=9m36s)).

Debugging story is very good. You pretty much never have to see the generated
JavaScript. ClojureScript uses source maps, so any errors in the compiled Js
will map back to the original ClojureScript source that caused them. Chrome
dev tools even do syntax highlighting for ClojureScript now.

Having a live dev environment with Figwheel and a REPL goes a long way here as
well. You can inspect a lot of things at runtime very easily.

Using immutable data structures by default avoids a lot of the debugging pain
as well. You practically never have to trace through a bunch of function calls
to find the problem. In most cases the problem is exactly on the line where
the error occurred.

~~~
draw_down
What if your thing crashes in IE?

~~~
yogthos
IE 11 supports source maps, so that's helpful. The other nice thing is that
you rarely end up dealing with browser specific quirks since all popular
ClojureScript libraries piggie back on React.js and the Google Closure
library.

These do a great job of handling the platform specific quirks for you. The
first app I developed with Reagent actually had to run on IE8, and to my shock
and surprised worked without any issues after I added the standard IE shims.

So, overall my experience is that you're better off dealing with IE than with
most Js frameworks.

------
chowes
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](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?

~~~
iheartmemcache
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](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).

~~~
eric-hu
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.

~~~
freshhawk
As a fellow vim user and full time clojure dev, I should point out that
spacemacs is pretty great for getting the best of vim and emacs in one editor.

But to get up and running and try things out? Use Cursive until you are
comfortable, don't get distracted by tooling problems (which there _will_ be).

------
abhishivsaxena
Since the GSoC project mentioned still seems to be incomplete, can anyone
suggest a way to use npm/es2015 modules with cljs applications for the
browser?

I build the first version of my app with cljs, and it was the
cleanest/simplest code I ever wrote. Just the lack of npm interoperability
makes in non-viable for me.

Anyone tried systemjs with cljs?

~~~
glenjamin
The simplest approach that works for this at the moment is to have something
like webpack build a UMD bundle and then add that bundle as a foreign lib.

