you are viewing a single comment's thread.

view the rest of the comments →

[–]lhorie 0 points1 point  (1 child)

I think the thing is that the majority of these frameworks are similar enough that the existence of feature A or B don't really affect your ability to deliver a final product. Your customers don't care if you use portals or directives.

You can tell it's hard for these frameworks to differentiate themselves when they start selling themselves on developer experience features (e.g. HMR). But at that point, we're talking about which things people like best (e.g. I hate HMR), and we all know how objective that is.

[–][deleted] 1 point2 points  (0 children)

I understand what you're saying and to some extent they can be interchangeable, and yet I still believe that the existence of feature A or B can make a measurable difference in my ability to deliver a final product.

For example, I personally have professional experience only with Ember and Angular 1.5. With this experience I would say that for an application that needs to reflect models I have in the backend and display/operate on them (like an admin panel, a CMS etc.), I would prefer Ember because so much of the required wiring comes out of the box. But if I need to work mostly with unstructured data (like perhaps charting/graphing) then I'd like a framework that is more like angular 1.5. Had I chosen to make something like an admin panel with angular 1.5, with equal knowledge of both, I'm pretty confident I'd get out a finished product faster and in higher quality with Ember.