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.
project.cljlein 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.
I’m not sure I’m convinced that Clojure must try to dominate “the market”, but inasmuch as this thread is about discussing how to do it, my contribution:
I have had, shall we say, mixed success evangelizing Clojure to mostly-Java developers across several different teams and years of improvements to tooling, libraries, etc., following a fairly set pattern. Unfortunately, I recognize that this pattern doesn’t scale, nor is it amenable to the kind of self-discovery that would be the fastest, best path to widespread adoption.
The approach I take is to get the prospective Clojurist working at the REPL. Fatal uncoolness of the JVM, poor documentation of build_tool, presence of parens – all are irrelevant. Get them up and running, evaluating forms in a file and seeing the results in the REPL (and, where appropriate, in a browser via Figwheel or whatever). Let them play a bit and validate their intuition about what is actually happening in this weird new setup (though, the setup can be less weird/new - Atom for Atom/VSCode users, Cursive for JetBrains users, etc.).
Wait just a moment. Answer any initial questions. Watch them; after a minute or so ask the prospective Clojurist a single question:
“Well? Do you …see?”
Either she will have gotten a faint glimmer of the flow, the joy waiting just under the surface, or she will say something like “…but you could just do this with lambdas in Java 8…” Either way, you have your answer - a new Clojurist for whom things like mastering :cljsbuild or learning parinfer are small costs, gladly paid or …not a Clojurist.
In my humble opinion, Clojure(script) doesn’t already have a good turnkey solution for “do the same sort-of-awful work you’re doing today, but in this new language instead” (as every new JS frontend framework develops right out the gate) because we aren’t selling the same sort-of-awful work you’re doing today.
Clojure doesn’t need a better mousetrap, Clojure needs a way to communicate the experience of no longer being a lowly mousecatcher to earn your daily bread, in a manner that scales beyond interested mentors bootstrapping prospective users to the point where they can be asked “Well …do you see?” I think that’s a pretty tall order for an SPA framework or a CLI tool, but unfortunately I also don’t have any better suggestions.
I’ve written about this before, but here’s IMO what worked for Elixir — not sure if it can apply to Clojure:
A syntax-based illusion of familiarity — the syntax borrows heavily from Ruby, so a lot of Ruby people are coming in, ignoring at the beginning the fundamental differences between the BEAM and RVM.
An official, core-developed build tool (Mix). Takes care of dependencies, running tests, generating scaffolding and a bunch of other stuff.
An almost-official HTTP abstraction (Plug). Almost official means that one or two core Elixir devs are involved.
An almost-official SQL abstraction layer (Ecto).
Most almost-official high-level libraries use macros to keep things easy (and somewhat simple).
An almost-official, monolith-like web framework (Phoenix) with support for templates, routes, basic security, distributed web socket support, some default JS stuff. Flexible enough to customise, opinionated enough to get you started.
A widely accepted deployment story (Distillery) — allows you to build a tarball that can be extracted onto a server and start.
A promise that everything is built on the shoulders of giants (Erlang/BEAM/OTP) so you have this weird cool obscure runtime that you don’t have to deal with at the beginning.
A promise of a “safe playground” where you can write your code in a specific way and everything will click together without you having to worry about architecting your app.
A promise of scalability, whatever that means.
(Don’t get me wrong, I think Elixir can actually fulfil those promises for most people.)
If you see the whole narrative, Elixir tries to sell a familiar dev experience on top of proven and powerful tools.
I believe opinionated frameworks are one possible way forward — for example, re-frame gives you a somewhat rigid architecture and a lot of people choose it for that inherent promise.
Perhaps Fulcro is another framework that sells the promise of a full-stack Clojure experience.
Is there a purely back-end framework missing? Something that gives you a rigid architecture and you just write your routes and queries, while also having a story about web sockets, deployment and vertical scalability.
As a non web developer, I feel very different. I’m not even sure I want to attract more JS beginners. Maybe I want to keep beating the average like Paul Graham says 
I’d rather see Java, C#, Common Lisp, Scheme, Go and Scala devs come to it.
I do think Clojure is a hard language. That just makes it not attractive to beginners. You need to know what you’re doing. It’s like a race car, you don’t learn to drive on one or you’re going to hurt yourself.
That said, I’ve mostly promoted it by helping answering questions about it, some blog posts, and evangelizing it at work. My team has almost fully adopted it now. Most our systems were rewritten in Clojure. I’ve helped setup a lot of the tooling necessary to bridge Clojure with my companies internal tools.
I think Clojure lacks success stories. It has a few small ones, but it would need one big one. If Storm had won the war against Spark for example, I think it would have had a big impact. Or if Datomic had the marketing of MongoDB, there’d be Clojure devs everywhere. If OM didn’t need an OM.Next, and all ClojureScript devs had rallied behind it, it could have been Elm.
Otherwise, I blame Emacs for half the unpopularity of Clojure. JVM for 25%, and lack of static types for another 25%.
Nobody likes Emacs who doesn’t already like Lisp. People associate the challenges and bad experience and lack of modern charm of Emacs with Clojure. Emacs is just the worst at first impressions, and thus Clojure is too.
The JVM is unattractive to JavaScript developers. Or to any dev coming from an interpreted dynamic language background like Ruby, Python, etc. If they’re not learning Java, Scala, Kotlin or even Groovy, they sure won’t learn Clojure.
Finally, Java, C#, Go, Scala, C++, D, etc. devs, they can’t understand not having static types. They’ve used Python once, and don’t think it can scale beyond scripts without becoming an unmaintainable mess. Also, they doubt the performance will be good enough for them.
For all three things, we’d need a solution. I don’t know what though.
For a full-stack framework, I personally favour Duct and I think it has potential to grow and become “the” standard framework. It is a very lightweight yet powerful framework that lets you plug in new functionality across the stack very simply. The only downside right now with it being relatively new/early is it lacks great and unified documentation, I often have to explore a few different repository repos/wikis to find certain documentation. I hope (and I’d be willing to help with this) the framework gets a dedicated website with extensive documentation.
One of the weaknesses I find in clojure (and experience daily while trying to bring other devs on board) is spotty documentation. Pedestal, for example, has clickable links to “Crash Course” guides that simply bring you to placeholder templates, which can be incredibly frustrating when you are starting out. There are a couple projects I’ve run across that do it really well though, like re-frame, luminus, cats, official spec guide, duct’s individual pieces, etc.
This boils down though to community effort, we can’t feel entitled to this stuff; all the placeholder guide templates for pedestal are just waiting for PRs to their documentation repo, I believe duct has a doc repo as well. A couple of volunteer hands over a few days could really improve the new-dev onboard experience.
I don’t wont a template with 40+ options… Would prefer more opinionated templates.
I think this is very true. Part of what helped Rails take off was that there were decent official solutions to most every problem you’d run into starting a web app: SQL/ORM, database migrations, auth, filters, testing/fixtures.
It’s much easier to learn when most people are using the same solutions, effectively out of the box – much easier to help coworkers when it’s likely they’re doing it the same way you already know how.
I think part of the issue here is that Cognitect is the “official” source and they don’t build websites/web applications as their bread and butter. And even when they have been building full stack websites, we’ve gotten Pedestal (experimental, poorly documented, mostly abandoned apart from a core library), Om (deprecated/abandoned), Om.Next (still not stable or well documented). It looked like we might get a semi-official framework with Arachne but that seems to have ground to a halt now (and seemed ridiculously complicated and, again, very poorly documented).
I’ve tended to stick to the simple stuff: Ring, Compojure (for routing; although we’ve also used Bidi in one project), Selmer (for templates), clojure.java.jdbc (for persistence, with HoneySQL if I need composable queries). But I don’t build anything full-stack (no JS/cljs) and none of that address security (we have JWT/OAuth2 for one project and Azure AD for another).
I originally ported a lightweight MVC framework that I created for CFML (ColdFusion) – it’s one of the two most popular in that community – but after using it for a while to build a few Clojure apps, I decided that it didn’t bring as much value to Clojure as it had to CFML, because Ring + Compojure + Selmer was already almost everything I needed (and pretty much the entirety of what FW/1 had added to CFML).
Just wanted to put in my two cents as a Clojure beginner, and indicate what worked to hook me into this stuff.
But first, I will say that it was NOT web-frameworks
— sorry about this long self-indulgent background story, but it helps me frame my viewpoint —
In grad school (during the late 90’s), I had been huge on Mathematica and Maple and loved the intimacy of “notebook” programming. Also, I used LabVIEW for years to automate all kinds of instrumentation. Those experiences in grad school stuck with me and informed my tastes about what I want from a programming toolchain/platform. Basically, I CRAVE immediacy and expressiveness: being able to deliver what comes into my mind as a computer program.
Paradoxically, through a series of career accidents, I ended up working as a servlet/EJB programmer back in the day when web development was a giant dumpster fire. Over time, I came to the bitter realization that the type of computing I loved in grad school was long gone and it looked like my work was just going to consist of suffering through one turgid, over-engineered framework after another. I eventually left that stuff for other domains.
Although my day-job since leaving the j2ee world wasn’t “software engineering”, I still make programming a major part of my work. I work as a manufacturing test engineer responsible for automating hardware tests and performing failure analysis. I use C# for “doing stuff” and R for analyzing/visualizing data. To some extent, I was able to regain some of that feeling of “agency” with computing that I had back in grad school. Especially with R, it felt very notebook-like and once I got past the quirks, it started feeling expressive. C# also became really cool once I grasped Linq for querying collections and the concurrency sugar of async/await.
I first heard about Clojure quite a long time ago (2011-ish?) on a now-defunct podcast called “Java Posse”. My way of keeping tabs with the java world was by listening to Java Posse. Anyways, they frequently talked about exotic new technologies, mostly Scala (didn’t like, too baroque) but also Clojure which sounded cool because it was a weird old language, Lisp, on the JVM. I put that on my to-do list and never did anything for years.
Then, I came across the videos of the 2013 Clojure Conj, I had remembered hearing about Clojure on Java Posse, and it was a good time to take a deep-dive in the middle of the night while surfing youtube. There was one talk in particular that REALLY spoke to me: Tim Ewald - Clojure: Programming with Hand Tools. THAT talk expressed EXACTLY what I want from a programming language! After that, I started on a path of trying to learn Clojure. I subscribed to Eric Normand’s wonderful video lessons for a while and now I am trying to get some small personal projects off the ground with the initial goal of using Clojure at work for some of my projects.
The thing that makes Clojure great is not the availability of a “do-everything” web-framework. Not everyone is a web-programmer, there are other types of programming that people do. And what is meant by “sell Clojure” anyway? Does it just mean TIOBE rank? A popularity contest competing with javascript, Java, and C#? Is that really the measure of success?
I think if you want to make Clojure last in the long term and not become a historical footnote (like some previous #1 TIOBE “winners” are rapidly heading towards), it is vital to make it appealing to a broad base of practitioners. That means not just web-programmers, but also data analysts, scientists, computational folks, instrumentation, graphics people, and others who work with specialized domains that can use the power and simplicity of the language: games, music, AI, whatever.
I think it is headed in the right direction. OK, yes, error messages need work, but it seems to me like the community and clojure adoption is moving forward.
Personally think of cognitect more as innovators, they seem to pave the way but then move on to the next big thing leaving it up to the community to continue or base new stuff on what they developed.
Because of om.next we now have Fulcro, an om.next fork: stable, well documented, companion libraries and overall slightly different & better model than om-next (IMO).
Now at work were going with apollo client(only js & python), its just mind blowing how much better & simpler fulcro is. Think a big part of the credit goes to om.next for the innovative ideeas.
From what I know duct is inspired by archane and seems to be really nice.
Is that really the state of pedestal? I think it’s used by Walmart labs, so it can’t be that bad.