[dracolytch]

I always have a problem with these kinds of frameworks. Every time I try to use one, and want to do something more in-depth for fancy than a lot of the functionality out-of-the-box, then I end up having to hunt down the way to extend X feature, and it often takes me more effort to do that then just writing in the root language would be.

That is to say: The abstraction isn't as expressive as the root language, and when I need something more expressive, then it's more troublesome than writing than the root language.

The rendering engine here does seem to perform admirably, and I have to congratulate them on that. Maybe I've just been burned a few too many times from this kind of language.

[Mc_Big_G]

I've built many apps using Ember and the time I save not writing boilerplate code or jquery spaghetti is well worth the time I spend understanding how to do more complicated things. Every time I get a bit frustrated with something seemingly complicated, I always realize it was better that way in the end.

Often I discover that I can do exactly what I wanted in just a few lines of code and writing it in pure javascript or jquery would have been many, many more lines of code and much less maintainable.

Developers smarter than I have struggled with these problems and developed optimal solutions that might not be easy to fully grok at first, but are always worth the effort to understand.

[untog]

Every framework has a learning curve. In this instance it seems to have a significant performance benefit. That's your trade-off.

[aero142]

I didn't take his comment to be about a learning curve. I think the complaint is that the abstraction on top is not as expressive as the thing it abstracts. This means that when you break the abstraction you have the complexity of the thing you abstracted away on top of the abstraction layer itself, which means you might have been better off without the abstraction in the first place.

[itsbits]

I have been following Ember since its 0.9 beta stage and believe me until it released around 1.3 or 1.5 there has been lot of change and was a huge learning curve. But now that I know how exactly ember works, it is easy and fast to write Ember Apps since lot of boilerplate can be easily avoided.

[nostrademons]

That's what I like about the whole WebComponents movement. Whether you use Polymer or X-tags, it's just new DOM elements, and they function just like regular DOM elements, and you can drop down to vanilla JS easily without throwing the productivity benefits of a framework out the window.

[jjbiotech]

Yeah, I think what you just stated is an issue for any type of abstraction. You really just have to examine an interface in depth before you start writing code with it to see if it's capable of supporting the functionality you need.

Only a few months ago while developing a REST API in Ruby, I implemented MongoMapper for my ORM/Database access layer. Turns out it didn't support a few things I wanted to do, so I hacked my code into little (ugly) pieces just so I could continue using MongoMapper (Didn't have time for a rewrite). I think if I would have just stuck with using the native Ruby Mongo driver, development would have taken less time and my code wouldn't look like a steaming pile of shit!

[emodendroket]

Well, you know, the native Ruby Mongo driver and Ruby itself are both abstractions, too.

[cloverich]

I've been working on a large app using Ember, and this has been my experience over the last several months. I'm still excited about embers future, and hopeful our choice to use it will one day pay off, but for this first project, we would absolutely have been further along, and happier, had we chosen a less all-encompassing framework and built the required abstractions ourselves (for the very reasons you have pointed out).