Hacker News Reader

Comment by judofyr | Hacker News Reader

Shouldn't this first check if Chrome Frame is actually used (by using the User-Agent header) before it injects the code? And why not just place the four lines straight into your layout?

View on HN

I feel like a complete jerk for saying this (partly because Sunlight Labs is a non-profit), but it suffers from what I like to call the snippet marketing syndrome: 4 - 5 lines of code being fancied up into a 10 - 30 line "plugin" with heavy references to the consulting studio that 'coded' it.

But, but, it's Rack! Everything related to Rack is awesome.

I wonder what the overhead of doing this as Rack Middleware is versus just putting it into your layout.

This is markup, it belongs in your layout files. You're really just disorganizing your app by putting this into middleware.

I think the biggest disadvantage of putting something like this in middleware, is that it's completely incompatible with stuff like memcache. The injection of this meta-tag is done after a memcache SET would have been done in the web app, and so if you have a reverse proxy in front of your webserver, for any cached page that's served, it won't include the injection. Also, the user-agent check that's being done in this plugin yields incorrect results in the presence of caching for similar reasons.

The idea behind Rack middleware is that it's incredibly easy to implement for the developer and re-usable across the spectrum of Ruby web apps.

Yes, implementing Google Chrome Frame in a given app is trivial. But removing this from the concern of a given app and into a re-usable middleware is where I think it's useful.

Reply on news.ycombinator.com