Ok, thanks for the reply. Cornet is at https://github.com/cosmi/cornet, it's similar to stefon.
I believe there are some existing middlewares for ring that do similar things (like wrap-not-modified). Do you replace this or work with it? jason On Monday, November 25, 2013 11:10:54 AM 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.
