[modularfurnitur]

I think Clojurescript might be the thing. With advances in the Google Closure compiler, it's getting better and better. And the front end developer tools and libraries in Clojurescript are _the best_ out there. The holy grail for javascript exists in Clojurescript. Until then I'll keep making my Javascript env look like Clojurescript. With janky react devcards, Immutable.js, and react-redux.

[rockmeamedee]

I just finished watching this talk "ClojureScript for Skeptics" (https://www.youtube.com/watch?v=gsffg5xxFQI) that laid out the pros of ClojureScript and completely sold me on trying it out. Weird seeing this article about Clojure dying right after, too.

In this talk I watched, the speaker argues for ClojureScript for SPAs because it has: * an excellent standard library (great functional programming so no need for lodash or other hacks, no issues with things like map(Integer.parse), solid date support, etc) * Go-level easy concurrency * Immutable types built-in for a fast React experience (immutable.js by default) * built-in Google Closure Compiler for optimizing, (also with sourcemaps and devtools) * built-in tree-shaking (only import what you use) from Google Closure Compiler * built-in code-splitting (don't import the code for the settings page on the home page, automatically load it when the user goes there), also from Google Closure Compiler

And the talk is from 2015! So there's probably been even more added I don't know about yet.

Then again, in 2017 I feel like we have an embarrassment of riches of programming languages. I'm already playing around with Elixir (loving it), wanna try out Rust's zero-cost everythings, and have finally finishing learning Haskell on my back burner.

[joncampbelldev]

Also super easy hot reloading with figwheel.

Literally just 'lein new figwheel' and you've got a project ready for everything you mentioned with hot reloading ready to go

[lilactown]

As someone who writes JavaScript for a living (among bits of Java and Swift), I'm loving ClojureScript. I'm currently building a side project with it. But I am still a bit skittish of Clojure (JVM). The JVM just feels slow and cumbersome compared to what I'm used to (Node.js, Erlang/Elixir, Python). The lack of good error messages is manageable when combined with figwheel on the CLJS side, but there doesn't seem to be something comparable on the server side.

I feel like Clojure needs a really good use case or story to have it become more popular. It feels really nice to program in, it's just that for specific needs - native UI programming, CLI apps, concurrent programming, data processing, web programming - other languages are better in those areas, and are good enough in other areas, that Clojure just doesn't seem compelling.

I think that Elixir's (which is really the same story as Ruby's) success is worth looking at. Elixir is really cool, but it's main hype train really doesn't have anything to do with it's technical strengths (concurrent programming) - it just has a really compelling web development story through Phoenix.

[bpicolo]

> The JVM just feels slow and cumbersome compared to what I'm used to (Node.js, Erlang/Elixir, Python)

In what regard? Because the JVM is faster than all of the above.

[moomin]

It's the startup and REPL time, typically. The JVM is super-powerful when it comes to compute tasks, but define a function on the REPL and Clojure will compile it, which is necessarily slower than what Python does.

So yeah, Clojure's faster, but perception matters. Erlang's a different case because it optimises for responsiveness for small tasks. It's very hard to write Clojure or even raw Java code as good at that as an easy Erlang program.

But yeah, a Mandelbrot set will be faster in Clojure.

[sz4kerto]

JVM startup time is typically sub-second. Anything above that is not the JVM, it's something else.

[pmontra]

I agree with you, it's the startup time. It is felt when running unit test too.

That's why JRuby is still a niche and most developers keep using MRI despite JRuby being eventually faster. It's a different example of developer happiness.

[lilactown]

In fact, I would say that if ClojureScript's interop with React Native could be made to be much smoother, that would be a real killer app.

[shadowmint]

I hear this a lot from the clojure community... but I think it's a missed attempt to pivot off the JVM and have clojure be useful for more people on a more popular platform.

Missed?

Yes.

Pick a thing.

Be excellent at it.

What is clojurescript excellent at?

Its a nice language, with not very nice tooling, that is hard to maintain and significantly different from the existing javascript code base you already have, with poor interop to the existing js ecosystem (it is poor, compared to some other compile to js languages).

On the JVM, java sucks, but your choices are limited; what, maybe groovy, kotlin, scale, clojure?

Clojure has pride of place as the best dynamic language in that space.

For javascript, that crowd of alternatives is so much larger, clojurescript needs to actually be good to stand out amongst all the others.

...and I don't think it really does.

The people who use it seem to just like it as a language; and I get that, that's a thing.

...but aesthetics are personal preference and its difficult to ague they make a compelling use case.

[lsdafjklsd]

> with not very nice tooling

The tooling is the best. Figwheel is hot reload that never goes down, devcards is revolutionary, and a browser repl for live in editor evaluation...

> significantly different from the existing javascript code base you already have

It actually isn't. Clojurescript is basically javascript that's immutable first, has underscore in it's core library, and then a bunch of other awesome language constructs. The libraries use the same patterns, re-frame is a nicer, more succinct abstraction over react-redux.

> poor interop to the existing js ecosystem

The interop might be the best out there. Seriously you can write javascript in clojurescript. you can straight up import es6 jsx javascript into your clojurescript code. (thanks Google Closure)

> For javascript, that crowd of alternatives is so much larger

I mean, what are the options? Clojurescript's benefits are so much more than the language. The real pluses for clojurescript are the Google Closure compiler, hot reload, browser repl, devcards, front end libraries. The language is the cherry on top. There are no alternatives that have a comparable platform not completely alien to JS developers.

[lenkite]

I am beginner to Clojuresript/Clojure. I am not that impressed by JVM Clojure (it is bloated, slow and laggy) and frankly there are better choices on the JVM - Ex: Kotlin offers more possibilities.

But I do like Clojurescript. However, it needs to wean itself away from the all the Java tooling and not require a JDK. We need a lein/figwheel written in node CLJS. An extension that supports REPL like Lumo and step through debugging within visual studio code. A good Clojurescript book. A good React-based UI component library written in CLJS.

[shadowmint]

> The tooling is the best.

No, it's really not.

Have you tried other ecosystems? You should. If clojure is the best tooling you've ever used, look around, there's a wide world out there.

Heck, even the article linked above from lambdaisland lists tooling as one of the issues clojure suffers with.

> I mean, what are the options?

Haxe. Dart. Typescript. Elm. Scala. LivesSript. ES6. CoffeeScript. Flow. PureScript. ...

There must be what, 50 odd listed on https://github.com/jashkenas/coffeescript/wiki/List-of-langu...

...but I mean, even if we accept that the things you say about clojurescript are true (and I don't agree that they are, but even if I did), the point I'm making is that it doesnt stand out from the crowd in terms of features.

Nothing you've described is something that would be missed particularly using say, typescript, webpack and npm.

[bschwindHN]

> What is clojurescript excellent at?

ClojureScript excels when writing frontend UIs, in my opinion. There are so many good ideas in Reagent and Re-Frame. JS tries to be like Re-Frame, with Immutable.js, react-redux, etc.

[vorg]

> Clojure has pride of place as the best dynamic language in that space.

Yes. The only other JVM dynamic language in your list is Apache Groovy. Last month it released version "2.5-alpha-1" with Groovy's very first macro facility, something Clojure's been doing since its inception. And I can't imagine how long a version tagged "alpha-1" will take to be suitable for actual use!

[Nekorosu]

How much experience do you have with ClojureScript and other compiled to JS languages?

[shadowmint]

A lot. We use clojurescript and ES6 in production.

(the clojurescript is now considered 'legacy')

[boubiyeah]

Well, clojure is better designed than javascript, that's for sure. But the holy grail for me would absolutely need static typing.

[ledgerdev]

You should look into Clojure Spec. It's a very nice balance of trade-offs for helping developers build correct software. While it uses a different approach than static typing, it seems a more natural fit for dynamic languages. Plus it's sort of a toolkit to be used in many different ways.

[ledgerdev]

Agreed. I suspect one current thing hurting adoption from the JS community is the very heavy JVM based tooling. With the Google Closure compiler now running on top of JS, there would seem to be a path for the CLJS(not clj) tooling to become more JS ecosystem friendly.

For the JS developers out there, is this something that's of interest? Or is the existing tooling(lein) good enough? What would be your ideal tooling story?

[philbo]

As a JS programmer with some Clojure experience I can confirm that the JVM is absolutely the biggest turn-off for me personally. Lisp syntax, immutable data structures, laziness, all splendid. The build/runtime environment, not so much.

Sounds like I should revisit CLJS based on your comment.

[ledgerdev]

Well at the moment, the tooling is all lein/JVM based.

That said, Figwheel hooked up with atom+protorepl+parinfer is pretty amazing if you haven't tried it.

https://github.com/bhauman/lein-figwheel

https://www.youtube.com/watch?v=0WMga5E7Vsk

[lsdafjklsd]

Parinfer is a huge game changer. Everyone afraid of writing lisp needs to try again using parinfer.

[lilactown]

As a JS developer using CLJS in my spare time, I've found that once I got my project setup with figwheel and everything, I can pretty much ignore the JVM. The moment that "classpath" is mentioned I usually try to find another way, though.

[owebmaster]

I like leiningen. The stability is something I never saw anywhere. You have plugins without updates for like 2 years and working like it was updated recently. Although it is becoming less common for clojure/script projects to be unmaintained.

[saosebastiao]

I don't know. Javascript is pretty slow as it is, and clojurescript is even slower. There is an inherent problem with compiling a dynamic typed language to another dynamic typed language...if your target language doesn't have the same semantics as your source, you end up having to embed a bunch of runtime code into your compiled output, or sacrifice compatibility. [0]

With a strong statically typed language like scalajs or elm, you have a lot more static reasoning that can be done at compile time, allowing you to omit a lot of runtime support.

[0] http://www.lihaoyi.com/post/FromfirstprinciplesWhyIbetonScal...

[raspasov]

JavaScript slow? Compared to what? ClojureScript is within 10-20% of JavaScript or less (virtually the same).

[bbsss]

Immutable.js when mori.js is available? :)

Having tried both I really prefer mori, mori imports some core clojure functions with it. I found working with iterators which was recommended with immutable.js very awkward.

[lsdafjklsd]

The issue is more that I have to add, and use an immutable library vs it being just baked in to the language. I have to convert from and to JS. Worry about setting a deep value that is regular JS. It's janky is all.