There's a difference between using a new technology and being clever. I've seen clever -- I've been clever. I've seen the "immature" dev who comes in and says, "So here I've written a dynamic binary interpreter that will inject into all known JS engines which will give me the ability to modify stackframes of the running Javascript program. So in scenarios where I write this code in JS, part of which will block a DCE, because I need a specific value on the stackframe, I can now access this below in Javascript. How you ask? With inline assembly in JS -- which I've also added. So now you can create a wide range of selectors."

"Like doing this common technique from jQuery?"

"Sure, if you want to suck the life out of programming you'll use that, but I prefer to keep my job fun. BTW, this will break on every rev of Chrome, so I have an alert set up to remind me to fix it for each new version. Anyways, I already checked it in. See you in three weeks, I'm going on that vacation I forgot to tell you about."

And for certain use cases that is good. However I wonder how many of those who did so were even aware of what the costs of moving to a solution which doesn't really readily support (and indeed actively discourages) solid database engineering would be when moving forward into new markets. Indeed the same thing is going on with a lot of NoSQL adoption and I think a lot of people are going to be badly bitten by choosing it without really understanding what the tradeoff is.

My own view is that ideal design processes in fact look at the established practices sympathetically before disregarding them. Where they are not applicable, they should be disregarded.

To be honest if Rails is capable of replacing J2EE for your application, then you were working on a toy.

That's all part of the architectural choice: if you're building a toy, then you don't to build it with an industrial class framework.

I've had the experience in reverse: working on a system built on a toy framework which started to fall to pieces the second it became obvious* that it required industrial level tooling. In that case it lead to irreplaceable data loss.

* It was obvious to me from the start that an Enterprise-level framework was required. I got the hint from the 30-page auditing requirements specification.

Oh come on. The evidence that tech like Rails can be used to build non-toy apps is abundant. When shops like Thoughtworks are bailing on Java for Ruby you know you can no longer shut down rational discussion of choices with weasel words like "toy" and "enterprise class". Rails is not the hammer for every nail but it wasn't long ago that doing the "right" thing meant pounding in every nail with a walrus like J2EE.

I think it's interesting that the emphasis on defending something like Rails is based on a comparison to J2EE. My real gripe with Rails is about how it disparages good enterprise-class database practices, and so this is why I'd call it a "toy" system.

That doesn't mean you can't do interesting things with it, but rather that you are essentially talking about an application closely tied to the db schema it stores its data in. The idea of enterprise-class applications sharing their data in a common database is something entirely foreign to (and incompatible with) the Rails way.

This doesn't mean it can't be used in an enterprise environment. For example, you could have a Rails/MySQL app with data imported periodically into a PostgreSQL multi-application database, but I wouldn't call the former "enterprise-class."

> When shops like Thoughtworks are bailing on Java for Ruby

They're swapping Java for Ruby, not Java for Rails.

Ruby is, performance aside, a really nice language. It's certainly possible to build something "enterprise class" in Ruby. Especially as soon as you start treating Ruby as a meta-language and build your own DSLs in it

Rails on the other hand isn't really enterprise grade. It's constrained by Active Record, and the immaturity (and lack of popularity) of the alternatives.