Reasons to give up trying Clojure

Questions & Help General Questions
1

Got one on Last time I looked into Clojure, I found myself frustrated that I was expected t... | Hacker News

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.

4 Likes
2

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 :stuck_out_tongue: 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.

8 Likes
3

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.

So… opinions related to my experiences anyway. I would accept the difference that I started learning programming in JavaScript, and Java is hard. Java is not hard to everyone.

npm ecosystem maybe look like a mess, comparing to Java side, which started in the 90s. npm is a young ecosystem. I found nice guides on JavaScript, and toolchains evolves quickly. Bash(or more…) in the old days, then Grunt came, then Gulp, and now Webpack, things are evolving. JavaScript community has absorbed lots of great ideas from all around. I don’t say JavaScript is great, but JavaScript serves lot of people well, people like us who are building things with it.

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.

1 Like
4

I’m doing mostly back-end these days at work, tried to get back to front-end, but after 1 year decided to learn clojurescript. React, redux, fp, immutablejs, webpack… I really liked the flow but it seemed like I was learning all the right stuff, but the complexity was just going through the roof, could not see a way out (still can’t for reactjs in javascript).

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.

1 Like
5

It’s long story for me since I started learning JavaScript(Acrually CoffeeScript) in 2012. I spent a lot of time in React since late 2014. It got me enough experience to be familiar with most of the concepts appeared in React, and me aware of several tricky problems in React.

My opinion is, JavaScript is a messy language, which led to the fragmental fact of React libraries. People are trying in different directions, using stores that are immutable and observable as well as plain js objects. Meanwhile people add syntax sugars to libraries too with tricky of JavaScript.

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.

2 Likes
6

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.

2 Likes
7

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 install.

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)

8

The problem that people from the Java ecosystem have with JavaScript is not a particular technology, but the constant breakage and churn of tooling and basic language libraries. Java on the other hand is stable since 1995, you can still take out your old Java code, put it on the classpath and link against it. Clojure is trying to even not break code in version updates, which is the holy grail. When Java is really boring corporate technology that feels clumsy to JavaScript people, JavaScript looks like this forever amateurish web playground where people who are beginners in programming frame the barrier of entry to any kind of technology and the wheel is constantly reinvented.

Just to hit this point home, it is ridiculous that I have to update a 6 month old node.js for certain libraries up to this day (node is roughly as old as Clojure, for which I barely had to do any version shuffeling). This kind of bleeding edge behaviour is not good if you want to build something solid that runs in some environment maybe for decades. JavaScript is a maintenance nightmare for that reason.

Now having said this, I think ClojureScript on node.js could provide serious benefits by making ClojureScript more accessible to JavaScript people and by providing Clojure(Script) code as libraries to node.js people. lumo already provides a starting place and can load custom libraries into your js environment. I would really love to see experienced JS developers showcase cljs backends and get rid of the JVM for their needs. I can totally understand that people do not want to go on the JVM, because it is an additional environment to carry around. But then some stable cljs backend has to emerge and who else to do the job than good JS devs?

6 Likes
9

I would also like to point out that you usually do not rerun leiningen. You either do autobuilds or you develop with figwheel on node or in the browser. I remember people in JS meetups talking about all the stuff they have to learn about webpack and how these tools compare to yarn and what not. I have not had to read a ton of stuff about leiningen and it does not get in my way. I also rarely run build scripts except in deployment scripts. I understand if you hit walls and are frustrated, but I don’t think the build systems of JavaScript are a match to maven, leiningen, boot and now clj, just because they have a way shorter half-life period and are not really standardized in JS land.

1 Like
10

Well, problems have mostly been fixed by shadow-cljs.

Webpack actually has been there for many years, and it will be.

1 Like
11

Great! I just had a quick peek at it. Does it integrate with your webpack stack? I have not tried it yet. I like some aspects of JavaScript, like its small core and its emphasis on interactivity btw., just not its fast churning time.

I am working atm. to bring datahike to JavaScript and node and it would be really cool if it would integrate well. I try to serve npm as well, but it would be great to have more js backend devs in cljs to also give feedback and help to integrate cljs libs into the js ecosystem.

12

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 cljs.core in a JavaScript project. shadow-cljs also supports targeting :node-library, might be useful in your case. On the opposite, using npm modules in shadow-cljs is trivial task now.

You may find more on docs.shadow-cljs.org and shadow-cljs Slack channel.

13

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.

1 Like
14

Hi,

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.

15

Have a look at https://oakes.github.io/paren-soup/ . You can try clojure right now, in the browser :slight_smile:

1 Like
16

Credit to @sekao who already answered on this thread.

17

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.