Tom is one of the two main developers you're talking about when you say "most of the people working on Ember were SproutCore developers."

I think the "lack of architectural road blocks" is called ember.js. If you're working with Sproutcore and haven't spent time with ember.js, you should take a look. It has a bit of a learning curve but it's very powerful once you get past that. The guys who built the table would tell you that instead of being an architectural road block, ember.js was the power that made the table possible. That's why it's called ember-table.

I am well aware that he is, but since he didn't say so it sounds accusatory if I point that out. If you read my original comment, I said that SproutCore has been missing a table view for years, and that it wasn't an oversight but something that people attempted to fix a number of times. So if Ember has solved the problem, I am glad it has finally happened. But as someone who has been trying to build projects on SproutCore for years and finding roadblocks, this was long overdue. Perhaps Ember has attained the maturity that SproutCore never seemed to be able to find.

The guys who built the table would tell you that instead of being an architectural road block, ember.js was the power that made the table possible.

That's what it means to be a roadblock... if you don't run into one, you would never imagine that there could have been one. A roadblock is what happens when you attempt to do something logical and find out that due to something outside of your control, it's realistically never going to happen.

I'm not trying to beat a dead horse here, but the two really do not share much architecture, especially when it comes to the view layer. The only place where the two started out looking similar is in the object model, and even that has evolved so much in Ember.js they only look the same if you squint.