techcrunch

...look no further than the comments on this TechCrunch post. Reacting to the scoop that Twitter is dumping Ruby on Rails (which almost immediately turned out to be wrong), more than 150 people decided to chime in about what Twitter's scaling problems are and how their own preferred web framework never would have encountered them. A whopping one person managed to refer to Twitter's custom message queueing software by name.

The rest presumably just like the (drag & drop HTML creation in Visual Studio|error detection in Zend|Google-enabled buzz surrounding Python), and have read "Rails doesn't scale" somewhere. I suppose their prattling is still slightly more meaningful than the yammerings of the web's legions of widget evangelists, social network triumphalists and self-proclaimed "SEO experts". But not by much.

At any rate, I think this is a good reminder of the signal:noise ratio facing our clients as they attempt to find technical help in a crowded marketplace. If you're not a technical person it's genuinely hard to tell the difference between someone who knows what they're talking about and someone who's simply regurgitating buzzwords. My rule of thumb when encountering bold pronouncements like the ones in that TC thread: ask "why?", then count the number of unexplained acronyms and buzzwords in the answer.

I haven't got a lot to add to this TechCrunch post other than to say that I find it immensely cheer-inducing. There are a lot of unknowns surrounding the OpenSocial platform, but its looming marketshare at least makes it seem likely that I'll be able to avoid learning any more bowdlerized web technologies with "FB" at the front of their names.

FBML, FQL, FBJS — it was getting out of control, and it all stinks of proprietary lock-in and a rather lame (but admittedly necessary from a security standpoint) attempt to wrap the LAMP stack under a layer of branding. That's not to say that every technology coming out of Facebook is worthless — I've heard some encouraging things about Thrift from people I respect (although if you're not in the market for an especially high-performance RPC framework, using something established like XML-RPC still seems like a better idea to me).

But Google's got a fairly good track record of only reinventing the wheel when they need to build a particularly enormous wheel. So cheers to this potential game-altering alliance. I want APIs, not languages; interfaces, not environments.