Fork me on GitHub
#cljs-edn
<
2016-05-12
>
shaunlebron00:05:55

@bhauman: excellent feedback, thanks

shaunlebron00:05:42

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

shaunlebron00:05:34

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

shaunlebron00:05:53

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'

shaunlebron00:05:49

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

shaunlebron00:05:27

a build tool is certainly a YUGE undertaking

shaunlebron00:05:03

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.

shaunlebron00:05:27

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

shaunlebron00:05:38

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

shaunlebron00:05:23

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

shaunlebron00:05:31

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

shaunlebron00:05:36

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)

shaunlebron00:05:04

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

shaunlebron00:05:19

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

shaunlebron00:05:05

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

shaunlebron00:05:48

i’m more curious than convicted about this direction tbh

shaunlebron00:05:20

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

bhauman00:05:36

I hear you simple_smile

shaunlebron00:05:08

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

bhauman00:05:18

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

shaunlebron00:05:45

lein-doo does that well I think

shaunlebron00:05:52

and your sidecar

bhauman00:05:10

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.

bhauman00:05:55

or really a library that backed up those tasks?

bhauman00:05:53

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

bhauman00:05:05

and abiities

bhauman00:05:30

and documentation

shaunlebron00:05:46

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

shaunlebron00:05:05

(sorry for the blanket statement)

shaunlebron00:05:53

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

bhauman00:05:01

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

bhauman00:05:30

I hear you

bhauman00:05:03

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

shaunlebron00:05:45

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

bhauman00:05:17

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

shaunlebron00:05:28

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

shaunlebron00:05:01

but let me back up

shaunlebron00:05:20

will differ from cljsbuild?

shaunlebron01:05:48

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

shaunlebron01:05:23

maybe this would be more fluid in a hangout session

shaunlebron01:05:14

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

shaunlebron01:05:16

interesting to hear it’s early and lacking

jheadapohl15:05:18

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.

jheadapohl15:05:17

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

jheadapohl15:05:50

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

jheadapohl15:05:00

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

jheadapohl15:05:56

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

jheadapohl15:05:30

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

shaunlebron22:05:32

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