Thanks for the link to cornet. Must be the kerning on my font, since I read comet. :-) I'll definitely check it out. At first glance it looks like a replacement for Dieter/Stefon, more focused on transpiling than optimization. I can't see any mention of it tackling problems like cache busting, and the issues that come with it. For instance how the cache busters on CSS files need to be a cascade of the assets they link to.
As for basic ring middlewares, I try not to reimplement them. So you would use wrap-content-type, for instance. As for wrap-not-modified, that's an interesting thought - especially since we know the asset hasn't changed, or it would be under another name. I'll have to look into that further. Nice tip, thanks. - Magnar On Monday, November 25, 2013 10:56:33 PM UTC+1, Jason Bennett wrote: > > Ok, thanks for the reply. Cornet is at > https://github.com/cosmi/cornet<https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fcosmi%2Fcornet&sa=D&sntz=1&usg=AFQjCNGTDwnsbtlpY6VpnA2Xpg3UKB19Sg>, > > 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.
