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.
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.
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.
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.
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.
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.
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.
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.
...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.
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.
> 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!
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.
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?
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.
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.
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.
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.
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.
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.
Not sure why this is posted. But I'm working on a straight port of re-frame in javascript, it's an abstraction on top of react-redux, a true 1:1 port. For me re-frame's api is the holy grail (for now) of UI programming.
Keeping all external state in a db like abstraction, and having any component, regardless of view tree depth, be able to query against it for data that it needs, and have it update when that data changes, is the way to go, and it's the future.
Applications developed this way are very easy to change and update. Deleting a completely self contained component, not having to update the parent by removing the wiring of the data, is a blessing.
I cut my teeth using Ember a few years back, the whole community is amazing and does great work. Using react/redux now, and while I think it's the simplest and most pragmatic approach (the connect function changed the game), I think the api's over in clojurescript land, specifically re-frame are the best . It's conceptually the same as react/redux, but with a few more facilities for isolating side effects in actions, and a wayyyyy simpler api for querying the store in functional components.
But what I came to say is I think templating languages are sub par. Using an actual programming language that returns "html", or some variant (like clojurescripts hiccup language) is way more useful. I wouldn't use this because of that.
https://github.com/babel/babel-preset-env/ should help with this to remove the polyfills that are already supported, and with some future work to remove polyfills are unused.
