You must be new to Hacker News then. Welcome!
Events need not be the same for us to try to use them to understand and vocalize our experiences.
Great writeup! Some days I feel similarly about Ember.
This is like Apple's marketing, except without the product and aimed at developers.
What I learned from doing it that way is that there's a level of process abstraction which is higher than "best practices" but lower than pure CS theory. It's the level at which documents like 12factor.net are. The best word I've found that describes it is "opinionated". You want software that's opinionated enough to drive design decisions but not so much that it dictates them.
People are very proud of this sort of understanding because it is hard-won. When you look at 12factor.net, if you haven't been developing for awhile, you might not understand just how useful a document it is. You might be thinking top-down rather than bottom-up. But if you're like me, you've seen lots of anti-patterns in the things you've built and long for a way to get them out of your apps.
That's where frameworks come in. They make decisions for you that cut back on those anti-patterns. Very useful if that's what you're looking for. When I first started building, I found Rails to be too much bloat, too complex, so I used Sinatra. Now I have a large project that I'm finishing up, and I wish now I'd used Rails. You can build an opinionated Sinatra app, but why when you could just use Rails?
You don't think you need someone else to make decisions for you, until you do.
Let's consider also the simple fact that ALL client-side MVC frameworks are JavaScript (unless they are precompiler-based, which none of the big ones really are, currently). The fact that all of them are based on the same language, the massive cracks in server-side systems that are further exacerbated by language idiosyncrasies are reduced significantly.
> I've seen [the problems that occur when you're working
> with an immature ecosystem] before. I started with Rails
> in 2006. It was difficult in the earlier years. It has
> only really matured in the past 3 years. I think Rails
> 3.1 really embodies everything you need to make a
> certain class of web applications. Ember and its
> ecosystem are so far off.
Using rails as our yardstick: Rails Releases Ember.js
--------------------- --------------------------
3.1.0 August 31, 2011 Now + 6.5 Years (End 2020)
3.0.0 August 29, 2010 Now + 5.5 Years (End 2019)
2.0.0 December 6, 2007 Now + 2 Years (Mid 2015)
1.0.0 December 13, 2005 Now (Mid 2013)
So starting an Ember.js project today is like starting a Rails app in 2005. Probably too much headache to take on for six month to a year long projects, but if you're looking at a 2-3 year timeframe and Ember.js gives you a technology advantage over other frameworks, then it might a good time to try it.Ember is really cute and charming. When it works it is all magic - but when it doesn't it is way harder to figure out what is wrong.
So far, Angular seems to have a stronger foundation and will eventually catch up in beauty.