Project Page: Kickstarter:
marciol 2016-09-06T19:35:11.000006Z

Hei, I just saw that more one piece reached the repo, asset pipelines 🙂

luke 2016-09-06T20:01:13.000007Z

Yep! Pretty happy with where they’re at (although I have no actual asset modules yet, and haven’t done docs)

luke 2016-09-06T20:01:19.000008Z

But feel free to give it a look-over.

luke 2016-09-06T20:01:48.000009Z

It’s backed by an immutable fileset implementation inspired by boot:

martinklepsch 2016-09-06T20:09:06.000011Z

@luke what's the kind of use case for asset pipelines, is that for SASS/image processing? I haven't used an asset pipeline in ages... (favoring static builds instead of dynamic ones)

luke 2016-09-06T20:11:08.000012Z

@martinklepsch This asset pipeline is for all processing of static assets (i.e, anything your server isn’t generating on the fly in response to each request.

luke 2016-09-06T20:11:34.000013Z

So yes, useful for scss, coffeescript, minifying, image compression, creating thumbnails, compressing, etc, etc.

luke 2016-09-06T20:11:58.000014Z

if you have an Arachne app that only contains the asset pipeline, not an HTTP server, you in fact have a static site generator 🙂

martinklepsch 2016-09-06T20:13:08.000015Z

ah ok, so asset pipeline, even in arachne, is a build-time component? image compression/thumbnails sounds like something that'd be on the fly

luke 2016-09-06T20:15:07.000016Z

Well it actually slots in at “startup” time, which is slightly different from build time; Arachne doesn’t really do anything during build to keep things simple. But you can “build” in a static way by having an Arachne app that starts (and processes the assets) and immediately exits.

marciol 2016-09-06T20:15:08.000017Z

great, I think this work will be great for the clojure community, without doubts 🙂.

luke 2016-09-06T20:15:29.000018Z

Sure, you could do compression/thumbnails at runtime too. kind of depends on what you want.

luke 2016-09-06T20:15:39.000019Z

but if your inputs are static files on the file system doing them ahead of time is better

martinklepsch 2016-09-06T20:16:02.000020Z

Ok, I think I understand

luke 2016-09-06T20:16:43.000021Z

I couldn’t wire things into “build” time without creating a hard dependency on a particular build tool (lein vs boot) or building my own.

martinklepsch 2016-09-06T20:17:07.000022Z

Well, there's an obvious choice 😄

luke 2016-09-06T20:17:26.000023Z

So it just does all the “static” type things as part of its startup process. And deployment tools will be able to hook into that pretty easily to upload to CDNs or whatever.

martinklepsch 2016-09-06T20:17:34.000024Z

Anyways thanks for clarifying. 👍

luke 2016-09-06T20:17:44.000025Z

there will be lots more docs & stuff forthcoming too

zane 2016-09-06T20:17:45.000026Z

Sounds a lot like Optimus's approach.

zane 2016-09-06T20:18:16.000027Z

Re: "build time" vs "startup time".

zane 2016-09-06T20:18:48.000028Z

Although Optimus does the work on the first request rather than at startup, I believe.

zane 2016-09-06T20:18:57.000029Z

marciol 2016-09-06T20:23:48.000031Z

It is possible to have some kind of task (I don’t know how to make this independently, in elixir we have mix tasks and in rails rake tasks) to precompile the assets statically

marciol 2016-09-06T20:24:21.000032Z

so you can decouple this kind of stuff from build time, but generate as you want the static precompiled assets.

luke 2016-09-06T20:25:03.000033Z

Yeah, the vocabulary is a bit different bot that’s totally doable. In Arachne you can have multiple runtimes, which load up a different set of modules/components. You’d just set up a runtime which only did static stuff and then terminated, and run that. It would effectively be the same as a “build task”.

martinklepsch 2016-09-06T20:25:06.000034Z

@marciol I generate everything static using a build (boot) task and upload to S3/CloudFront

marciol 2016-09-06T20:25:56.000035Z

yep, despite the different vocabulary, it is what I mean 🙂

luke 2016-09-06T20:27:30.000036Z

I really like the way boot does things, but like I said didn’t want to create a hard dependency on a particular build tool, and also I wanted to keep all Arachne-related things as homogenous as possible. So your build tool of choice does a minimal amount of bootstrapping (basically just figuring out a classpath and starting a JVM) and Arachne takes it from there.

luke 2016-09-06T20:28:09.000037Z

So a lot of things that are currently “build” time activities, like CLJS compilation and asset deployment, are actually first-class modules in Arachne that work like any other module.

luke 2016-09-06T20:28:19.000038Z

Simplifies the programming model IMO, and everything lives together in the same config.

luke 2016-09-06T20:30:11.000039Z

and then you also don’t have to do anything magic to support file watchers that rebuild your assets when an input file is changed. You just keep the asset component running, instead of letting it shut down.

martinklepsch 2016-09-06T20:40:06.000040Z

I'm not yet seeing the benefits but it's early so I'll just wait until things get specific 🙂