For me, I try posting regularly new and interesting stuff to Hacker News.
I always talk about it my local Javascript meetup (Paris.js). I may even give a talk about it at a Web/Javascript conference next summer. I’d like to evangelize it.
He also asked:
What one thing would most accelerate Clojure’s user growth?
Unpopular opinions and wild ideas welcome
!
Templates that are a well-written app that you can mold & delete into what you want. With cheatsheets in the comments/docs. And some of the files are meant to let you poke around interactively.
Example
Suppose you select one of the webserver+postgres templates. (There’ll be a few.)
-
It’ll come w/ a DB dump, with simple instructions how to load & dump it. Like a videogame.
-
Aren’t running postgres? No prob! It’ll mention how to grab Docker & tell you the simple
docker cp&docker execcommands to load & dump the DB. -
A
playground.cljcan pop out a graphviz image showing how the DB schema’s wired up. -
The HugSQL files have little cheatsheets, like
id in (:v*:ids), with warnings like “don’t stuff too many elements in there or postgres’ll have this error.” -
Throw in a couple examples with left joins and subselects, because who wants to look that up.
-
-
It’ll start a webapp with various attractively-styled widgets, hooked up dynamically.
- The idea: delete what you don’t want, customize what you do. Do similar things as with the DB, above.
-
Stuff you put in a real app (if you weren’t so lazy), like remote REPL, logging, monitoring, etc
-
Like any real app, it should have an embarrassing utils.clj with all those oddities you really should put into a lib but never will:
group-by-singly,merge-with-keys,with-ns.
Disclaimer
Maybe this exists, or exists in a better form. Didn’t do research; I’m procrastinating. 
I believe the brightest path forward is community based CLJS distribution/community, called something like “CLJS Stack” that breaks(not a fork and still use clojurescript) from the core clojure team and focuses on the javascript community. I would minimizes/hide the jvm as much as possible and operate with a community culture like that of the rust, reasonml or elm communities. It could include
- node based cli called cljs where startup time is important (lein/boot need to go)
- shadow-cljs is the compiler
- cljs libs deployed to npm or somewhere js friendly.
- common way of running unit tests in browser and in node.
- vscode primary editor (emacs needs to be discouraged)
- debugging with chrome devtools
- docs.cljs.io, (api docs cljs only) how.cljs.io (task based cljs only)
- forum for cljs questions (no jvm clojure stuff) so we don’t confuse users
- workflow to handle css/design assets (for designers)
- community managed & supported libs for primary/common needs
- guidance for common app types (cli/jsapp/api/serverless/etc)
- easy way to support financially (patreon or open collective)
I would really like to see some beginner tutorials on egghead.io or other websites that are popular in the javascript community. That would be really neat when selling clojurescript to javascript devs.
As a beginner it’s a lot of hard work to get a “production ready simple app”. I don’t wont a template with 40+ options… Would prefer more opinionated templates.
One of the major pluses of javascript community:
I can have just basic understanding of react and by choosing a starter-kit that fits my needs, I can have a minimal decent app in production in 1 week.
Just to have something working and in production fast I think adds immense value…
Only so much people can work on something just on there local computer before they lose momentum and interest.
I came to Clojure(Script) precisely because of the fact that I could use the same language for the server and client. Having one language for everything was the main draw for me. I had a lot of experience with Java previously so the JVM was actually a big plus for me. I probably would not have stayed if I had to do JS server side.
If I was going to sell Clojure I would probably focus on the “hosted” aspect and the ability to choose. The same language with a syntax that also suits HTML/CSS as well as code is so huge I can’t even consider doing something else.
Going sort of off topic again …
In some way this is what shadow-cljs does. I don’t think we need to hide the JVM, just make it more user-friendly. shadow-cljs uses it and works well I think. Startup time is the most common complaint but last time I tested it was actually about equal to the react-native tooling. I also have plans to improve this …
They are called lumo or planck.
Does it really matter where it is published to if all you have to do is run a command like lein deploy clojars? Yes the setup is a bit weird and shadow-cljs publish is still missing. I really don’t see the point in publishing to npm over clojars. They do the exact same thing (IMHO).
WIP, it is kinda working already but not as usable as I’d like.
I tried going down that route when I started working on the Language Server implementation for CLJS. vscode unfortunately does not allow creating custom UI elements (yet) so there was no way to implement a REPL window without resorting to all kinds of unofficial hacks. I basically stopped there since that is not an option. Cursive is very good and easily better than vscode in many ways. I struggled through emacs for a very long time before that so yeah I don’t want to go back to that either but that doesn’t mean we should “discourage” any editor.
Also on my list.
The big ticket item for shadow-cljs however currently is documentation. I should focus on that instead of actually coding but it is absolutely no fun for me so I usually don’t do it. If anyone would like to help out with actual docs I will happily walk you through everything … I just hate the writing part.
It’s interesting that the founder of Egghead seems to be into Clojure, he mentions it a couple of times on his blog http://joelhooks.com/, and even tells that he wants to deploy production Clojure code to Egghead 
Does it really matter where it is published to if all you have to do is run a command like lein deploy clojars? Yes the setup is a bit weird and shadow-cljs publish is still missing. I really don’t see the point in publishing to npm over clojars. They do the exact same thing (IMHO).
It does when I have to read a lot docs installing Lein or Boot in order to release a package. It took me very long time to finish my script of deploy my library.
For npm, very simple:
- create
index.jswith your code - init
package.jsonwith decentnameandmain npm install -g .and launchnodeto check if it works correctlynpm release. If it’s first time,npm loginfirst.
For Clojars:
- read docs in Lein…
- read docs in Boot…
- writing scripts
- lein deploy
- go back to docs…
Well aware of those and not at all the sort of experience I was suggesting, but rather a lein like replacement to handle templates, deps, builds, repls, etc. I was thinking of something like https://github.com/cljs/tool with shadow-cljs being the build component.
Back on topic, I really think a dedicated cljs stack and small focused community around it, would be much more attractive to js/node developers than the current state of things, and drive significant growth.
I think you are missing that with NPM it’s all the same. You have to install Node, read NPM docs and so on.
Yep confirmed, and he seems to have great respect for @dnolen and the work he’s done with om.
As for selling clojure(script). Just did a presentation at the local javascript group in my city last night. No questions at the end, digging in a bit seems a lot of the previous presentations were pretty basic, so most of the target audience just does not attend that much.
The feedback was really good on material & talk, but the general consensus was that FP + react seemed a bit to much for most, 3-4 were quite interested and seemed to get it (30 people attended).
These are the slides from my talk https://goo.gl/Rt2Hqj in anybody’s interested. Any feedback would be really appreciated. Still new to presenting & teaching, working hard to get better at it.
So far for my next talk will:
*separate “Why I chose language & ecosystem” and “Language details” part better
*focus on side by side comparison with js (arity, mutability, destructuring, truthy/falsy, etc… )
*highlight repl & parinfer
As @roman01la already said that is because you know npm. I did not know npm and it wasn’t any easier for me to setup than lein deploy clojars. Installing a current version on node + npm on a linux machine is not exactly easy either. OSX makes it easy due to brew. Debian and others still have ancient versions.
- create
project.clj lein deploy clojars(yes, it would be easier if it asked for credentials)
I still hope someone write a little deploy utility for tools.deps that I can re-use for shadow-cljs but I otherwise I’ll write a publish fn at some point. The hard parts are already available in many libraries so its just a matter of writing things up properly. Other priorities currently get in the way.
I was comparing the time I used to publish my first npm package and the time for Clojars. Publishing to Clojars can be simple if there’s very friendly guide or a very simple tool described by @thheller , but it took me long time in reality despite that I have several years of experience of using JavaScript.
Check this Publishing Your First Package to npm
Publish the Package!
And now, the moment you’ve been waiting for – publishing your package for the whole world to see!
If this is indeed your first package, you’ll need to register on npm by running
npm adduser. If you’re already registered on npm, usenpm logininstead.Here comes the big one:
npm publishThis one might take a few seconds, but once it’s done – so are you!
Congratulations! You just published your first npm package like a boss! Go ahead and run
npm install is-null-or-emptyand attempt to use your package in another project! =)
Agreed. Except that install Node.js on Ubuntu is not hard. Linux users get better command line tools:
https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions
curl -sL https://deb.nodesource.com/setup_9.x | sudo -E bash -
sudo apt-get install -y nodejs
Yes of course they are similar… but what you both are missing is that every javascript developer already has npm installed and is already familiar with it. Sure you might have been familiar with the JVM and JVM clojure was a draw to you, but most developers these days actively avoid the JVM. Plus, Leiningen is yet another tool to deal with and is a terribly slow cli experience. These are just additional barriers to bring new users from the JS community into the CLJS community.
Along the same lines having to know the JS platform for the client, and the JVM platform for the server side means there’s much more incidental complexity(e.g. money, datetimes, etc). Why not just a single platform for both when the nodejs usage on the server is exploding, where java is relatively flat or falling. On top of this, JVM clojure is less that ideal or even unusable in many scenarios(e.g. serverless/mobile) because of it’s slow start times and large memory footprint.
Why though? FUD or actual reasons?
Again I don’t think startup time is a good enough reason if the goal is to have something I start every few days. We are not there yet but startup time does not matter once the kinks are worked out.
There are many others communities that would equally benefit from clojure(script) so focusing on one seems counter-productive. Yes we can do more for all of them.
How is this different in the JS world?
Equally JVM clojure is much better suited for many scenarios. I take a JVM over node for a server every single time, they aren’t even in the same category when you actually want shared memory and threads. Yes choosing the right tool for the Job is important but don’t dismiss the JVM outright because it doesn’t excel at a few things. No platform does it all equally well.
Thats why I think the “hosted” aspect is so valuable. I can use the JVM or node, it is the same language after all.
… most developers these days actively avoid the JVM
Seeing from JavaScript side, most other platforms are shrinking… illusion or reality…
I see startups people around me choosing Node.js and Golang for new projects. For company that are getting really large, they migrate to Java.
Well, yes or no, if you program enough and old enough, you would found every era will have this kind of illusion.
In the previous Java era, everyone try to build everything from spaceship to toilet paper using Java and have a illusion Java will rule the world. They provide many sentiments for proving it, however, time will tell the truth. Java still a power tool but we know its boundary now, or, at least we will not build a Java CPU again.
Since people using Clojure/Script are tend to be really sane, they use Clojure for hobby until they find it profitable enough. Not enough insane fanboy is the most serious problem in Clojure/Script Community…
Noone tests the boundary so noone knows the boundary.
Sorry that was a poorly worded comment. I was just suggesting that it requires knowledge of multiple platforms being JS on the client side and JVM on server side which handle stuff like date-times differently so you need to know both.
I would have to disagree and feel startup time does matter quite a lot especially to newcomers first experiencing clojure.
Absolutely agree the JVM is far superior for old school big iron server apps where memory and startup time don’t matter. But nodejs seems to be good enough and the choice of a huge and rapidly growing(~100% per year) number of developers and businesses, where jvm growth is relatively flat.
Enough about JVM versus JS, let’s get back on topic of how to grow the clojure community, because that’s what we all really want.