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.
