For me, I try posting regularly new and interesting stuff to Hacker News.
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.
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 execcommands to load & dump the DB.
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:
Maybe this exists, or exists in a better form. Didn’t do research; I’m procrastinating.
- 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)
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.
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
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
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:
index.jswith your code
npm install -g .and launch
nodeto check if it works correctly
npm release. If it’s first time,
- 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.
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
npm on a linux machine is not exactly easy either. OSX makes it easy due to
brew. Debian and others still have ancient versions.
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.
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, use
Here comes the big one:
This 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:
curl -sL https://deb.nodesource.com/setup_9.x | sudo -E bash - sudo apt-get install -y nodejs
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
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.