Last time I looked into Clojure, I found myself frustrated that I was expected to install leiningen, Java, etc. and get it all working together before I could write any code.
I like to know how a toolchain works, how libraries are linked, etc. I don’t want to rely on “magic” that can be incompatible with alternative “magic”.
Clojure didn’t provide a good low-level interface, and I ended up giving up on it for that reason alone.
Now that there are some minimal command-line tools, I think I’ll give it another look.
I think you meant this link: https://news.ycombinator.com/item?id=15883164
I don’t blame anyone for being frustrated with tooling. I actually think clojure’s tooling is better than anything else I’ve tried, but it is different. If you invested a ton of time into learning npm, i don’t blame you for being hesitant to now install the JRE + lein + possibly a new editor. That’s why i shamelessly plugged lightmod in that comment thread last night My theory is that after getting more familiar with the language, you’ll be more inclined to break off the training wheels and use the normal build tools.
Thanks, link’s fixed.
Need to clarify that I’m a ClojureScript programmer, not Clojure at current. I spent several years playing with Backbone, React, and Node.js and Haskell(beginner level) . Then I found Clojure necessary for React, then I started learning. At first I used Clojure to build toolchains like things I used in build React apps, mostly Lein and Boot plugins. Months later more and more of my code in ClojureScript only.
Today we have Webpack and several MVC libraries. The tooling is much better than ClojureScript(Clojure gets a standard CLI in 1.9 , not used yet). The reason made me choose Clojure(Script) is ECMAScript, not tooling.
To be honest, before thheller presented me shadow-cljs, I never thought toolings in ClojureScript can be compared with Webpack.
Really curious what you mean by:
One of the things I list as bonus points when talking about clojurescript is the tooling:
GCC advanced, figwheel, garden css, macros, cljc, transit put together make a really interesting tool-chain.
I really like the end result and in just about 30-40 lines of config. Taking a look at something like react-starter-kit, just part of the webpack config is 500 lines long.
Ror the react ecosystem: redux, mobx, relay, apollo, cerebral, redux-observables etc…
There are a lot, but was doing a bit of research for work since we need to refactor most of the front-end. The end result is just crazy complex. Think clojurescript also has the upper hand in terms of react-js ecosystem.
By “much better” I meant Webpack. Webpack is lots of great features. Before Webpack, we tried lot of sulotions, however Webpack almost ended the war. It brought loaders, long term caching, hot module replacement, dynamic loading… all built inside Webpack. And it’s not slow to run, compared to Lein and Boot.
Speaking of the length of configure files. I think it can be better, not it’s essentially that complex. Now I’m using shadow-cljs for development and releasing, it’s not short too: https://github.com/mvc-works/coworkflow/blob/master/shadow-cljs.edn . If you want something short, check out some tools that does less, it can be very short: https://parceljs.org/ . I mean, modern web development does need lots of configuration, not problem of js.
For example, to build servers, add a few lines of code of Node.js , it would work. But server side programming is hardly that simple. There are databases, different environments, maybe dockers too. It always becomes complicated.
In the start of 2017, there are several things we can’t do in ClojureScript. Async module loading, long term caching, requiring npm modules in browsers… I used Webpack before and I knew some of them are essential to modern web apps. Now thanks to shadow-cljs and ClojureScript core team, it’s already possible.
Just took a glance at react-starter-kit’s Webpack configs. It’s really huge. Actually in our apps I would not have so many loaders, nor configs.
react-starter-kit uses Babel with presets. It definitely can be shorter if I use CoffeeScript or TypeScript, or even with less presets. For CSS, I use emotion, very short to configure. In our project, we only pick what we need.
If you invested a ton of time into learning npm
this is why you are mistaken. no one needs to invest a lot of time into npm because
- you are not expected to edit npm config by hand
- there is basically a single command you need to know to start using npm, and that’s
you can go from nothing to building things with just that. not really an “investment”. so stop repeating this completely baseless argument please because you are hurting your own environment by resisting to accept the fact that leiningen is not
simple the way that word is defined in clojure-land. there is no shame in this, no one expects anyone to solve complex problems with simple solutions. (at least i hope so)
Well, problems have mostly been fixed by shadow-cljs.
Webpack actually has been there for many years, and it will be.
shadow-cljs is capable of emitting CommonJS-compatible code, which allows Webpack to bundle it. It runs well and I used it in early days, just too large to have code from
:node-library, might be useful in your case. On the opposite, using npm modules in shadow-cljs is trivial task now.
As a recent Clojure adept I can still feel some pain about the tooling. At my company we have Windows 10 and a proxy (yes, I know…) and trying to make
lein work on this is painful. To avoid all the hassle I use Ubuntu on Windows - I would have used it anyway, but still - and a colleague of mine spent a whole day to make
lein work on Windows, but now he moved to Ubuntu as well.
Now I like
lein, I understand it is a very nice abstraction and I see its usefulness every time I have to fire up a package manager for Python, but its learning curve is pretty steep for newcomers. I’m wondering wether releasing and ‘marketing’ some simple and configurable Docker images would help the newcomers.
I understand it is painful that lein does not work on W10 with a proxy. I would advise you to open a bug report on github and see if you can get it resolved together.
Also I dont want to sound sharp, but as a developer sooner or later one has to go through the pains of using a build tool. I started out using make, then ant, then maven and then gradle extensively + some more hobbywise.
Even if you understand the concepts behind build tooling it is usually a tough process to understand the build tool + build chain of your current go to programming language. I have not seen an easy way around that so far.
Even for gradle, where the simplest working script is a build.gradle with this content:
apply plugin ‘java’
it gets messy fast as soon as you add more projects and start to do some not so simple stuff.