Clojurians Log v2

@jiyouyou125 has joined the channel

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

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

But feel free to give it a look-over.

It’s backed by an immutable fileset implementation inspired by boot: https://github.com/arachne-framework/arachne-fileset

@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)

@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.

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

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

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

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.

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

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

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

Ok, I think I understand

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.

Well, there's an obvious choice 😄

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.

Anyways thanks for clarifying. 👍

there will be lots more docs & stuff forthcoming too

Sounds a lot like Optimus's approach.

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

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

https://github.com/magnars/optimus

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

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

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”.

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

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

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.

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.

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

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.

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