
The Next Five Years of ClojureScript - tosh
http://blog.cognitect.com/blog/2016/12/13/the-next-five-years-of-clojurescript
======
lkrubner
About this:

"In many ways ClojureScript has and continues to be ahead of the JavaScript
mainstream with respect to best practices. Concepts which are only starting to
break into the mainstream such as immutability, single atom application state,
and agile UI development via robust hot-code reloading are old news to
ClojureScript users. "

To my mind, the most compelling thing about Javascript-in-Clojure is working
with Om Next. I say this as someone who has recently done some big projects
with React.

I think it would be accurate to say that over the last 2 years React has been
the Javascript framework that had the biggest impact on how people think about
working with Javascript. You look at how much Angular tried to reinvent itself
to be a bit more like React.

There are a lot of interesting ideas in React, and I learned a lot while
working with it, yet I hate working with it. It is ridiculously verbose. And I
hate the way it handles mutations -- it's as if React was trying to be
Functional, but then decided to go back and be Object Oriented when it came to
mutations.

But I don't mean to go off on a tangent. There are a lot of good ideas in
React. Especially GraphQL, which arose as part of the React effort, but which
I think will have a long life quite independent of React. React might some day
fade away and be forgotten, but GraphQL's critique of the RESTful style is
likely to change the way the industry thinks about APIs over the net.

But as I said, React is verbose. I like where Om Next is going -- in terms of
immutability and data flow, it has the same basic outlook as React, but Om
Next is simpler and it is truer to the Functional paradigm.

If I do any further work with ClojureScript, it will be because of Om Next.

[https://github.com/omcljs/om/wiki/Quick-
Start-(om.next)](https://github.com/omcljs/om/wiki/Quick-Start-\(om.next\))

~~~
thom
I found almost everything about Om almost egregiously, shamelessly complex. I
absolute _love_ the core philosophy, and I think it's a valuable technical
effort. But even Om Next is not the big refactoring towards user friendliness
that I was hoping for.

It's likely that I'm just too dumb for modern web programming, but I am
waiting for someone to distill the (admittedly brilliant) ideas behind Om into
something just as powerful but more usable. Reagent is elegant and simple, but
you can see how it falls down in the face of larger apps, re-frame I just find
a mess. I'm excited about all of this, but I don't think we're really there
yet.

~~~
cutler
Have you looked at the Untangled framework? It seems to be exactly what you're
looking for. [https://untangled-web.github.io/untangled/](https://untangled-
web.github.io/untangled/)

~~~
jasonjackson
we're using untangled framework in production, I can't say enough good things
about it.

------
errantspark
I'm a big fan of Scheme/CL but I find development in ClojureScript to be quite
frustrating. If anyone has some solutions I'd LOVE to hear them; while es6 is
great I'd still prefer a more lispy language.

My major gripe is with debugging, when I'm writing es6 it's really easy to set
a breakpoint and modify a function half way through execution. Or half finish
a program and then play around with completions in the REPL to explore a
problem. Sometimes I'll be traversing a complex data structure and I'll write
an empty loop with just a breakpoint. I can then run the code and work through
things in a concrete state and once I've got things working bringing the code
back into my codebase.

When I write in any compile-to-js language I always run into the same problem
where once I'm in browser I have to go back to vanilla js and any advantage I
may have gained is quickly erased by having to deal with transpiled code.

Additionally with libraries like lodash-fp and newer ES features (promises,
fat arrows, const and let etc.) the clarity in vanilla JS code is approaching
a reasonable level.

~~~
shriphani
Can't help much with your specific problem (I mostly do println debugging) but
I've found that figwheel is a great workflow. Following cljs tutorials and
whatever is at best painful and it is ridiculous that you need to read a giant
webpage like a torah to get started. Use figwheel and add some years to your
life: [https://github.com/bhauman/lein-
figwheel](https://github.com/bhauman/lein-figwheel)

------
shadowmint
My biggest complaint remains that without a meaningful concurrency story in
js, the benefits of clojure dont make much sense to me.

Its just another hard to debug compiles to js language.

I get you can share some code between server and client... but we've used it
in production and now we're getting rid of it; there just wasn't a compelling
reason to keep it over es6.

~~~
pandeiro
> there just wasn't a compelling reason to keep it over es6

\- hiccup syntax / sexps are trees analogous to the HTML you're constantly
generating, and first-class supported data structures supported by the
language which need no pre-compilation/transformation step, unlike JSX

\- syntax is a good 20-30% less verbose than JS (yes, even ES6), especially
when the core lib is taken into account (things like partition, zipmap,
threading macros)

\- one extremely battle-tested dependency resolution story, not named NPM - it
just works

\- incredible development tooling innovation, best of class for frontend web
development

\- the sequence abstraction and dozens of functions that operate on it, rather
than Object.assign, Array.map, etc

\- best-of-breed dead code elimination via Google Closure Compiler, meaning
much of third party libraries and development-specific code ends up weighing
less / nothing in production builds

\- sets and set operations built in, along with tree walking, diffing and
string utility libraries, included with the distribution

\- no more defensive copying, thanks to immutability everywhere

~~~
nickbauman
> one extremely battle-tested dependency resolution story, not named NPM - it
> just works

This alone is worth all of it.

~~~
edem
Yep. Leiningen is even better than mvn/gradle combined.

~~~
glenjamin
Leiningen uses the exact same dependency resolution model as maven and gradle.

It has many advantages over those tools imo - but its dependency resolution
model isn't one of them.

~~~
nickbauman
What kind of dependency resolution model would you prefer?

------
Touche
Talk is probably what you want:
[https://www.youtube.com/watch?v=mty0RwkPmE8](https://www.youtube.com/watch?v=mty0RwkPmE8)

------
qwertyuiop924
...Can't the Clojure people just implement a native code compiler for mobile
stuff? I mean, come on, CL/Scheme have been doing that for years, and they
weren't constrained by the JVM, forcing a more optimized design.

~~~
ethagnawl
You can already write Android applications using Clojure[0] without too much
trouble. There were a few rough edges when I last dabbled, but that was ~1.5
years ago and I imagine the ecosystem has only gotten better in the meantime.

[0] - [http://clojure-android.info/](http://clojure-android.info/)

~~~
pjmlp
No, the eco-system hardly changed and it just increases the development effort
by forcing developers to move out of the Android Studio workflow and being
slower than pure Java.

------
ekzy
The only problem with clojurescript is that it is much harder to learn than
most of the other JS framework out there. Simple is not easy, remember?

Clojurescript for skeptics:
[https://youtu.be/gsffg5xxFQI](https://youtu.be/gsffg5xxFQI)

~~~
greenyouse
I love using ClojureScript but one other downside is the lack of ClojureScript
jobs. There are thousands of JS jobs right now but how many cljs jobs are
hiring? Tens?

That sucks because cljs is great but it's probably the biggest incentive for
sticking with JS.

~~~
ff_
It's not relevant how many companies are hiring for that, as long as someone
is.

Clojure is growing fast, and a complaint I'm hearing consistently lately is
that there are not enough clj/s devs around.

~~~
dustingetz
market size is relevant, are the people doing the complaining willing to pay
$$$ for cljs devs? I was on the market last winter and could only find $$
(baby startups) which was a 50% cut in rate to work in cljs. BTW I am about to
start looking again, contact info in profile

------
jgalt212
> ClojureScript offers features like dead code elimination

In Clojurescript, it's my opinion the Closure compiler is of dubious value. It
adds yet another level of indirection between the source and the target. And
isn't it the dead code elimination that makes run time macros impossible in
CLJS? They are possible in Clojure proper.

~~~
bad_user
For runtime macros you need to also load the CLJS compiler in your app, which
is heavy and overkill in the context of JS apps.

Even so, embedding a CLJS compiler in your app (and hence runtime macros) is
possible.

~~~
jgalt212
> For runtime macros you need to also load the CLJS compiler in your app,
> which is heavy and overkill in the context of JS apps.

I agree, but with code splitting this could be done with 0 overhead for most
use cases.

