@bhauman: excellent feedback, thanks

I’m kind of wandering around trying to figure out what’s possible and beneficial to do here

i have been thinking about a build tool that wraps cljs.jar, for providing the one thing missing from Quick Start, which is dependencies

it’s interesting to see the jump to ‘mies’ and ‘cljsbuild’ when deps are needed. i at least want to see what a tool would look like if it occupied the space between Quick Start and ‘mies'

just gathering more data there to judge the experience provided, which is hard to guess before seeing it

a build tool is certainly a YUGE undertaking

the build tool I’m considering (occupying the space between Quick Start and ‘mies’) is more of an npm tool, in that it downloads dependencies, runs named command strings, and has the Quick Start scripts which read build info from cljs.edn.

it won’t be a general purpose build tool like lein, boot, etc

two more points you brought up: 1) clojure as a dominant backend for cljs users, and 2) building libraries instead of tools to improve cljs ease-of-use

I think relying on clojure is definitely a sound technical decision for backend things

coming from the JS world, and working in there now, I know that JS people will prefer something node with cljs for backend

I'm just trying to confirm the assumption that it makes sense to continue having cljs be a part of clojure’s build tooling where clojure is the first-class citizen (lein, boot)

but I’m not talking about going to the extreme and using bootstrapped tools on node for doing all the building

i’m saying the experience of lein/boot may be too secondary to what js people coming into the cljs world will want-- a first-class cljs tool like the elm tool for elm

in that respect, we still need java of course, just providing a cljs-first experience through a cljs tool

i’m more curious than convicted about this direction tbh

so I think if the tool isn’t a huge general purpose build tool and can provide the elm-like first-class experience, and it caters to people who aren’t interested in a clojure backend, it is at least worth spending a little time looking into

I hear you

for your last point, libraries instead of tools, I think the better libraries could certainly be used by such a tool, and that are concerns may intersect there

I think all the lein plugins should be written a libraries first and then have plugins be thin wrappers around the library api

so agree

lein-doo does that well I think

and your sidecar

There seems to be a bias against lein. Which I don't really understand. It seems superficial. What would be wrong with having a central lein cljs plugin that handled all the tasks? lein cljs package lein cljs watch , lein cljs deploy, etc.

or really a library that backed up those tasks?

And as a side note I used elm a bunch today. Its still very very early in its tooling.

and abiities

and documentation

lein bias is superficial, and design/experience is all about the superficial

(sorry for the blanket statement)

i could go into it, but i’ve rambled enough about where i stand

but that is not exactly true, design takes into account the realities of the situation as well, the constraints help and inform the design process

agree

I hear you

I am just trying to help, I share a deep desire to make cljs approachable

no, I hope I don’t sound hostile, i’m really glad to be talking about this and hearing your thoughts on it

oh you don't at all I was just clarifying that, I'm not hostile to your position

it seems there are two audiences, the JS crowd and the Clojure crowd

but let me back up

lein cljs

will differ from cljsbuild?

come to think of it, i’m not sure I understood what you meant by better build libraries, apart from “ease of use”, i’m not sure about the particulars you had in mind

maybe this would be more fluid in a hangout session

i can’t speak on elm btw, i think i just brought it up as an example of a simple first-class tool for a language

interesting to hear it’s early and lacking

Say a team has an existing web project, with its own code base and build scripts. They are interested enough in cljs to try it out in some limited way, maybe on a particular page that has a lot of interactivity. They would like to integrate cljs into the existing build, without a complete overhaul of the codebase, and such that they can later remove it if it doesn't work out. It's a use case I was investigating a year or two ago. The tools have improved but I still think there is room to address that situation better. I wonder if a more minimal, cljs-focused build tool would help there.

Maybe not even what I would normally think of as a build tool, but some way to call the compiler and possibly do dependency resolution from another ecosystem's build tools

Without doing a deep dive into the cljs compiler API up front

I thought about this a lot when I was working on a team using JavaScript and PHP. Then I worked on a Clojure team and the advantages of Clojure over cljs became more clear to me

I can understand why people who are already developing in Clojure wouldn't want to use cljs+node.

Anyway I'm following this discussion with interest, since I will be in a JavaScript-focused role soon and I'll be looking for places that cljs might fit into the picture

thanks for sharing, Josh. would like to hear more experiences like that outside the clojure bubble