3 ms·

Because both Ember and Angular are front-end frameworks AND competitors. The issues with Yii and Drupal are a bit different. Yii is a serverside framework. And

by aikah 11y ago

Because both Ember and Angular are front-end frameworks AND competitors. The issues with Yii and Drupal are a bit different. Yii is a serverside framework. And Drupal a CMS. I'd say the case with Drupal is way more problematic than Yii's though.

jacquesm 11y ago
GGP said framework, not front-end framework.
- andyfleming 11y ago
  I think both meanings are implied and definitely both percieved. The first have "every framework should take note" is more general, and I would mostly agree. The ember team has seemed to manage their project very well. Though I don't like the style of Ember itself, personally. There are often times with projects though where breaking changes are necessary for evolution of the software. I'm not sure if there were any major trade-offs with Ember. That may be because of good planning, but good planning like anything else takes resources, and often that resource is time. The "that's how you avoid creating another framework and fragmenting community" comment is pretty clearly about the angular mess last year, and rightly so. I have a love-hate relationship with Angular. It's been a complicated journey and at times handled poorly. They seem to be on a better track now. Regardless, I don't think there was any malintent in nercury's post. They are all good lessons learned.
  - nercury 11y ago
    No, I did not actually had Angular in mind when writing this. We often hear talks how new major version should handle deprecation gracefully. It was more the reaction of actually seeing it happen.
sbarre 11y ago
I think the more generalized point that was being made was for any framework, front-end, back-end, middleware, CMS, whatever.. Properly handling deprecations and providing a clear and reasonable migration path for your users will keep them happy and will keep them upgrading instead of either sticking to old versions or jumping ship. These are not concerns that apply only to front-end frameworks.

by aikah 11y ago

jacquesm 11y ago

GGP said framework, not front-end framework.

andyfleming 11y ago
I think both meanings are implied and definitely both percieved. The first have "every framework should take note" is more general, and I would mostly agree. The ember team has seemed to manage their project very well. Though I don't like the style of Ember itself, personally. There are often times with projects though where breaking changes are necessary for evolution of the software. I'm not sure if there were any major trade-offs with Ember. That may be because of good planning, but good planning like anything else takes resources, and often that resource is time. The "that's how you avoid creating another framework and fragmenting community" comment is pretty clearly about the angular mess last year, and rightly so. I have a love-hate relationship with Angular. It's been a complicated journey and at times handled poorly. They seem to be on a better track now. Regardless, I don't think there was any malintent in nercury's post. They are all good lessons learned.
- nercury 11y ago
  No, I did not actually had Angular in mind when writing this. We often hear talks how new major version should handle deprecation gracefully. It was more the reaction of actually seeing it happen.

sbarre 11y ago

I think the more generalized point that was being made was for any framework, front-end, back-end, middleware, CMS, whatever.. Properly handling deprecations and providing a clear and reasonable migration path for your users will keep them happy and will keep them upgrading instead of either sticking to old versions or jumping ship. These are not concerns that apply only to front-end frameworks.