On Monday, 25 November 2013 18:12:28 UTC-8, Paul Biggar wrote: > > [FYI: I'm the author/forker of stefon] > > These libraries aren't bad, but to be honest, I think we've done it all > wrong. We're just all scratching our own itches, not writing reusable > components (unlike most of the rest of the clojure web ecosystem). > > If you look at stefon, you get a set of non-composable functions, designed > for my exact use case. Optimus, cornet, and dieter all suffer from the same > problems. > > Cornet, supports compilation (with different compiler and versions from > stefon), serving assets, and configuring itself from a JVM command line. It > also has :dev and :prod modes (though these mean "dont minify" and "do > minify". It does split out the functions in a slightly composable way (you > can have `(wrap-lesscss-processor loader :mode :dev)`), but those still use > :mode. > > Stefon supports: concatenating JS and CSS, compiling less, coffeescript, > hamlcoffee, minification using Closure compiler (currently broken), some > trivial css minification, cache-busting and expiry headers, and asset > references (eg data-uri to put the contents of one asset in another). It > also supports caching compilation and clj-v8 for speed, and expiration > headers and cache busting. It has precompilation for production use with a > CDN). > > Dieter is basically like stefon, but older and less maintained, and some > different choices around precompilation. > > Optimus supports concatenating, minification, cache busting, expiry > headers, and something angular specific. Also assets dont have to be files > on disk, and a there's a list of a dozen or so other features that contrast > it to stefon or cornet in a neutral way (neither decision is right or > wrong, just different). > > So basically stefon supports all high level use cases, optimus support all > of them except compilation, cornet supports most of it but not cache > busting. But where we do support the same things, we do it in many > different ways. > > So my problem here is that we've each chosen to couple everything > together. If you want to use stefon's CDN feature in production, with > optimus' dev asset serving, with cornet's minification, you're out of luck. > > Weavejester made a critique of stefon on reddit [1] a while back. He made > the point "why isn't this just middleware", by which I believe he means > "why cant this all be split up into composable functions?" > > He's right. We should, IMO, stop doing what we're doing, and rebuild our > projects into a set of composable components that play well together: > > - a choice of caching middlewares > - a choice of minifying middlewares > - a choice of asset compilers (including different versions and > implementations) (also some way for them to interact to support a pipeline) > - a choice of precompilation/CDN and compiling on the server > - composable optimizations (caching compilations) > - a choice of how to concatenate assets > > I don't really know how to do this though, just that they should be > different libraries, and that all orthogonal feature sets should be > composable. I'd love to hear people's thoughts on how we can accomplish > this. > > [1] > http://www.reddit.com/r/Clojure/comments/1n1n0p/circlecistefon_asset_pipeline_for_clojure_closely/ccexi3a >
I got some feedback along these lines for Twixt, from technomancy. I rewrote most of the code and was pleased with the result. The approach I took was to have an "asset pipeline" that was used by Twixt; it was built by the application (there's a default for most cases). The asset pipeline works much like the Ring request pipeline, you can add middleware to it. Even the default pipeline understands production mode vs. development mode, which is (currently) mostly a question of what gets cached and when the cache is checked to see if it is dirty, if at all. > > On Monday, 25 November 2013 11:10:54 UTC-8, Magnar Sveen wrote: >> >> Hi Jason! >> >> Magnar, could you talk a little about how your project is better >>> than/different from Stefon/dieter and cornet? I feel like we have a lot of >>> these projects now, all doing mostly the same thing. >>> >> >> Thanks for asking. I'll try to shed some light on the differences as I >> see them, and hopefully the people behind Dieter/Stefon (they're very >> similar) can add some details into their thinking. I haven't seen Comet, >> and google didn't help much either. Can you share a link? >> >> As for Optimus vs Stefon: First of all it's a difference in focus. Stefon >> focuses on being an asset pipeline modelled after Sprockets in Rails. It >> lets you write LESS, CoffeeScript, Haml - turning it into CSS and >> JavaScript. Optimus is not about transpiling from other languages, but >> about frontend optimization. As such, it rewrites your urls to include >> cache busters and serves your assets with far-future expires headers, so >> they can be cached aggressively in production. As I add more features to >> optimus, they too will focus around better frontend performance - and not >> more languages to be transpiled. >> >> While this is the main point in my mind, there are also other differences >> that aren't just details that everyone will agree on. :-) These two come to >> mind: >> >> 1. Stefon serves assets live in development, but requires a build step in >> production to precompile the files. Optimus does not require a build step, >> but compiles your asset when the server starts. >> >> 2. Stefon creates bundles by having custom .stefon files with >> edn-flavored lists of files in your directories of static assets. Optimus >> also needs a list of bundles, but does so using Clojure in your program. I >> would think that Stefons' approach is better if your frontend developers >> are not comfortable editing the Clojure code, while Optimus' approach >> allows more programatic control. >> >> I hope I haven't misrepresented Stefon in any way - these are my >> impressions. Since I'm a front-end optimization nut, these arguments were >> enough to sway me to create a different package. It would be several major >> breaking changes to Dieter and Stefon's architectures and APIs, and I >> didn't think I would get anywhere fighting for these changes in github >> issues. >> >> >> >>> I also don't totally understand why they're all done as Ring middleware >>> instead of lein/maven plugins. Maybe this is my Java background talking, >>> but that seems to me to be the logical place to put this sort of thing. >>> >> >> Front-end development with a compilation step is pretty horrible. There's >> also the case that the URL to a static asset and its location on disk is >> entirely different after optimization. >> >> Hope that answers your questions somewhat decently. And if it didn't, >> maybe you'll be swayed by the argument that a little competition is a good >> thing for the community. :) >> >> - Magnar >> > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
