6 ms·

> If your app runs on Ember 1.13 without raising deprecations, it should run on 2.0. Every framework should take note: that's how you avoid creating another fr

by nercury 11y ago

> If your app runs on Ember 1.13 without raising deprecations, it should run on 2.0. Every framework should take note: that's how you avoid creating another framework and fragmenting community! It's is great to see this in action :). Amazing work.

westoque 11y ago
Agreed. This is how to handle deprecations gracefully.
aikah 11y ago
To be fair, Angularjs (since you are obviously talking about it) backpedaled their "second system" a bit(since users complained loudly) and there is now some level of compat between the v1 and v2. But yeah, one shouldn't break apis to a point where each version is a brand new framework.
- jacquesm 11y ago
  > To be fair, Angularjs (since you are obviously talking about it) backpedaled their "second system" a bit(since users complained loudly) and there is now some level of compat between the v1 and v2. Why is that obvious? I can think of several other frameworks that this would apply to. Drupal for instance, Yii is another and there are quite a few more.
  - 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.
  - mattwad 11y ago
    Been a while, but from what I remember, upgrading Drupal itself usually worked okay, but you couldn't because most sites relied on 3-4 contributed modules, and it would take another half year-year for them to also upgrade, if ever.
    - dubcanada 11y ago
      I've had the same experience as you. I've never had a problem upgrading a Drupal site because of the core modules. Everything in the core upgrades fine. It's always a contributed module that breaks stuff.
  - SwellJoe 11y ago
    The upgrade situation with Drupal is, frankly, a disaster. Every major revision from 6->7->8, breaks literally every module and every third party piece of code. I'm months into migrating our website from 6 to 7 (I'm the only person working on the migration, and my PHP experience is somewhat limited). Many common modules provide no usable upgrade path, even if there is a version for both 6 and 7 (which is often not the case). And, there seems to be no inclination on the part of Drupal core developers to alter this course, or even recognition that it's a horrible user experience. According to some conversations I've had with folks, Drupal 8 seems to be even worse than Drupal 7, and Drupal 7 is literally the worst upgrade experience I've ever had. Piles of new jargon and new APIs get introduced in every new release, and often replaces or subsumes entire swaths of similar functionality in previous releases (e.g. nodes -> entities), and Drupal was already ridiculously jargon-heavy to the point of documentation making no sense to someone without extensive experience with the specific ways they use terminology, and googling generic terms like "node" and "entity" is a laughably unhelpful process. I have, at many points in this process, thought: "Fuck everything about this, I'm migrating to WordPress." I probably should have done so the first time I thought that, as it would be done by now. But, every time I made it over another hump in the upgrade, I thought, "Surely that was the worst of it." and kept slogging along. Upgrading WordPress is literally a no-brainer, now...you just get emails every week or two saying, "Your website has been updated to the latest version of WordPress." Sometimes, you click the "upgrade database" button. Sorry to rant. But, I happen to be working on my Drupal upgrade again today, so I'm grumpy.
    - BillyParadise 11y ago
      Software brings out the best in people :) (now if I can get this damned rails gem to work properly....)
    - johnatwork 11y ago
      The biggest gripe I've had with Drupal was when moving from 6 to 7, they had module writers pledge that their modules would be ready on the release day of 7, which a lot of folks broke the promise or worse, abandoned the project all together without letting anyone know. So some folks were caught not being able to upgrade due to a crucial module being abandoned at 6.
  - pbowyer 11y ago
    To list a few more: - The switch from symfony 1.4 to Symfony 2.0 requires a complete rewrite. Support for symfony 1.4 stopped fairly quickly; there seemed no understanding that companies wouldn't pay to rewrite their messy-but-working systems onto a 'cleaner' framework. - MODX Content Management System. There is no upgrade path from 1.X to 2.X. Good luck to you if you've invested years developing your site on 1.X...
- ChrisArgyle 11y ago
  Unfortunately the aforementioned backpedaling--the new router--only allows Angular 2 components to live side-by-side with Angular 1 components. If you want any Angular 2 features you still have to rewrite that component.
lewisl9029 11y ago
Agreed. As great as Angular 2 seems to be, by breaking compatibility to the point they did, they've essentially created another framework. For someone looking to upgrade from Angular 1.x, this shifts their thought process from "should I upgrade to Angular 2?" to "which new framework should I upgrade to?". And for many people, that new framework isn't going to be Angular 2.
- mmastrac 11y ago
  As someone who loves Angular, searching for information on Angular 1 vs Angular 2 is insanely frustrating. They should have just renamed the damn thing.
- johnatwork 11y ago
  It's actually why my company ditched Angular. Even though the Angular part wasn't very big at the time and the rewrite would not have been too costly, it would not have been wise to move to Angular 2 just to have them pull the same thing again for Angular 3.
- Bahamut 11y ago
  The Angular team is currently exploring options to ease the upgrade path - the current plan last I saw is to create an engine that runs angular 2 components in angular 1 and vice versa for seamless interop, so upgrading can be more incremental. That is an evolving story, which has changed several times before reaching that point. That said, Angular 2's performance is already looking phenomenal, and assuming some of the stats I have seen out in the wild are to be believed, it can run over 30x as fast as some of the existing frameworks for large datasets, including angular 1. If I had to choose a library to use now, it'd be React, but if I had the opportunity to hold off upgrading, I would absolutely wait for Angular 2.
- couchand 11y ago
  There's a very natural upgrade path from Angular 1.x to React: start building new little components in React and patch them into your app in Angular directives. You can even apply the flux pattern to good effect within the directive while still making use of your existing Angular service infrastructure. Per Evans this would be an Evolving Order over a pair of Bounded Contexts.
jbergens 11y ago
To release a 2.0 that basically is a 1.3 without some things is not much of progress. It will be interesting to see if they can complete new planned features without breaking the api when they move through more 2.x releases and later 3.0.
- _____s 11y ago
  No, actually, there were quite a few new introductions between 1.11 and 1.13 (Glimmer, the new rendering engine; Actions and API changed, ED became 1.0, got more stable), and, as a result, there were numerous deprecations in the 1.13 release. 2.0 removes things that were deprecated in 1.13. Things like views, active model adapter, etc. have been extracted out in an addon. None of these things broke the API; there was always a sane (although sometimes painful) process to help you through the upgrade. There are other things planned for the next few releases, such as routable components, new component syntax, etc. but the things they will replace (controllers and the old component syntax) will be supported through the 2.0 cycle (at least that's what's said). Ember's deprecations in 1.13 were a bit of work for me, as a developer, but the new features in the past few months have done a lot of good to the framework and removed a lot of the complexity. I much prefer this way of upgrading, and I really, really appreciate the Ember team for doing it this way.
- golfstrom 11y ago
  It's not a marketing release, Ember is simply following semantic versioning. Many of the new features that might've slipped into a 2.0 have made it into the last few 1.x releases, since they could be made backwards-compatible; e.g. Glimmer could've been held back for marketing reasons, but they pushed hard to get it out ASAP in 1.13 in June.
chasb 11y ago
Robert gave a talk about this at Ember.js NYC last month: https://www.youtube.com/watch?v=ltzN4v-ymo4 https://www.youtube.com/watch?v=ltzN4v-ymo4
steveax 11y ago
Yes, super happy the core team keeps as a priority minimizing the pain of tracking new releases while continuing to evolve Ember. Kudos to the core team.
tsmarsh 11y ago
Except... have you seen the changes between 1.8 and 1.13? It might as well be a new framework. So far moving from 1.8 to 1.8 on CLI has taken my team 3 months, and we still need to migrate to 1.13 if we are to remain supported. Ember provides an upgrade path, but it is a long, miserable slog.
- adamesque 11y ago
  It sounds like the core team is contemplating doing LTS releases, which should ease the fears of anyone who worries they'll be left behind if they can't keep up. source: https://github.com/emberjs/rfcs/pull/84#issuecomment-130451156 https://github.com/emberjs/rfcs/pull/84#issuecomment-1304511...
  - tsmarsh 11y ago
    I'm not sure LTS would help us. If 1.8 had been deemed LTS we may have delayed the upgrade work until it was EOL... then what? We'd still be facing months of upgrade work, but on a significantly larger code base. This is a problem of platform maturity. The Web is moving too quickly for monolithic framework solutions to keep up. ES6, web components, shadow dom etc were not part of the landscape 12 months ago. Ember and Angular are both doing admirable work in all of these spaces, but they're leaving their users in their wake. I'm just not sure what you are supposed to do if you want to build a multi-year project with modern frameworks in 2015. My current suggestion is that we don't, accepting that the web site is just a skin over your api, that needs to move with the fashion, so expect to replace it every 12 months, minimum... that doesn't go over very well with executives.
    - phren0logy 11y ago
      Sure, but does doing it all by yourself really put you that much further ahead? That does not slow the pace of change. You have more granular choices, but you have many many choices you are forced to make. If you trust the people making decisions behind the framework, it still seems like the better choice.
    - wldcordeiro 11y ago
aaronbrethorst 11y ago
Which is sort of ironic, given that Ember.js was originally called Sproutcore 2.0 [1]...But I digress. Props to Tom, Yehuda, and everyone else. I've been dithering over whether to get up to speed on Ember or React, but I feel like the 'Batteries Included' approach that Ember provides and the very aggressive approach to cruft removal is what's right for me. [1] http://yehudakatz.com/2011/12/12/amber-js-formerly-sproutcore-2-0-is-now-ember-js/ http://yehudakatz.com/2011/12/12/amber-js-formerly-sproutcor...
jhall1468 11y ago
As already mentioned, the upgrade path for large apps is not quite as simple as the line implies. Ignoring that, this concept of backwards compatibility above all things is so strange to me. How modern browsers work has changed fairly dramatically over the last several years. Not to mention a major, major overhaul of ECMAScript. And yet, every. single. time. we have something that mentions backwards compatibility being straight-forward, the top comment is always about how re-writing frameworks are bad. I don't have a problem with the way the Angular team are doing things. Angular 1.x will be supported for a long, long time. And even though this hasn't been announced, I expect the 1.x and 2.0 branch to gradually merge, requiring minor changes to code at each minor version increase. So effectively, Angular 1.4 -> 2.0 is no different than Ember 1.0 -> 2.0 with the caveat that 2.0 was planned in advance so all of the minor version changes will lead to 2.0, rather than 2.0 being the outcome of minor changes in 1.x.

by nercury 11y ago

westoque 11y ago

Agreed. This is how to handle deprecations gracefully.

aikah 11y ago

To be fair, Angularjs (since you are obviously talking about it) backpedaled their "second system" a bit(since users complained loudly) and there is now some level of compat between the v1 and v2. But yeah, one shouldn't break apis to a point where each version is a brand new framework.

jacquesm 11y ago
> To be fair, Angularjs (since you are obviously talking about it) backpedaled their "second system" a bit(since users complained loudly) and there is now some level of compat between the v1 and v2. Why is that obvious? I can think of several other frameworks that this would apply to. Drupal for instance, Yii is another and there are quite a few more.
- 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.
- mattwad 11y ago
  Been a while, but from what I remember, upgrading Drupal itself usually worked okay, but you couldn't because most sites relied on 3-4 contributed modules, and it would take another half year-year for them to also upgrade, if ever.
  - dubcanada 11y ago
    I've had the same experience as you. I've never had a problem upgrading a Drupal site because of the core modules. Everything in the core upgrades fine. It's always a contributed module that breaks stuff.
- SwellJoe 11y ago
  The upgrade situation with Drupal is, frankly, a disaster. Every major revision from 6->7->8, breaks literally every module and every third party piece of code. I'm months into migrating our website from 6 to 7 (I'm the only person working on the migration, and my PHP experience is somewhat limited). Many common modules provide no usable upgrade path, even if there is a version for both 6 and 7 (which is often not the case). And, there seems to be no inclination on the part of Drupal core developers to alter this course, or even recognition that it's a horrible user experience. According to some conversations I've had with folks, Drupal 8 seems to be even worse than Drupal 7, and Drupal 7 is literally the worst upgrade experience I've ever had. Piles of new jargon and new APIs get introduced in every new release, and often replaces or subsumes entire swaths of similar functionality in previous releases (e.g. nodes -> entities), and Drupal was already ridiculously jargon-heavy to the point of documentation making no sense to someone without extensive experience with the specific ways they use terminology, and googling generic terms like "node" and "entity" is a laughably unhelpful process. I have, at many points in this process, thought: "Fuck everything about this, I'm migrating to WordPress." I probably should have done so the first time I thought that, as it would be done by now. But, every time I made it over another hump in the upgrade, I thought, "Surely that was the worst of it." and kept slogging along. Upgrading WordPress is literally a no-brainer, now...you just get emails every week or two saying, "Your website has been updated to the latest version of WordPress." Sometimes, you click the "upgrade database" button. Sorry to rant. But, I happen to be working on my Drupal upgrade again today, so I'm grumpy.
  - BillyParadise 11y ago
    Software brings out the best in people :) (now if I can get this damned rails gem to work properly....)
  - johnatwork 11y ago
    The biggest gripe I've had with Drupal was when moving from 6 to 7, they had module writers pledge that their modules would be ready on the release day of 7, which a lot of folks broke the promise or worse, abandoned the project all together without letting anyone know. So some folks were caught not being able to upgrade due to a crucial module being abandoned at 6.
- pbowyer 11y ago
  To list a few more: - The switch from symfony 1.4 to Symfony 2.0 requires a complete rewrite. Support for symfony 1.4 stopped fairly quickly; there seemed no understanding that companies wouldn't pay to rewrite their messy-but-working systems onto a 'cleaner' framework. - MODX Content Management System. There is no upgrade path from 1.X to 2.X. Good luck to you if you've invested years developing your site on 1.X...
ChrisArgyle 11y ago
Unfortunately the aforementioned backpedaling--the new router--only allows Angular 2 components to live side-by-side with Angular 1 components. If you want any Angular 2 features you still have to rewrite that component.

lewisl9029 11y ago

Agreed. As great as Angular 2 seems to be, by breaking compatibility to the point they did, they've essentially created another framework. For someone looking to upgrade from Angular 1.x, this shifts their thought process from "should I upgrade to Angular 2?" to "which new framework should I upgrade to?". And for many people, that new framework isn't going to be Angular 2.

mmastrac 11y ago
As someone who loves Angular, searching for information on Angular 1 vs Angular 2 is insanely frustrating. They should have just renamed the damn thing.
johnatwork 11y ago
It's actually why my company ditched Angular. Even though the Angular part wasn't very big at the time and the rewrite would not have been too costly, it would not have been wise to move to Angular 2 just to have them pull the same thing again for Angular 3.
Bahamut 11y ago
The Angular team is currently exploring options to ease the upgrade path - the current plan last I saw is to create an engine that runs angular 2 components in angular 1 and vice versa for seamless interop, so upgrading can be more incremental. That is an evolving story, which has changed several times before reaching that point. That said, Angular 2's performance is already looking phenomenal, and assuming some of the stats I have seen out in the wild are to be believed, it can run over 30x as fast as some of the existing frameworks for large datasets, including angular 1. If I had to choose a library to use now, it'd be React, but if I had the opportunity to hold off upgrading, I would absolutely wait for Angular 2.
couchand 11y ago
There's a very natural upgrade path from Angular 1.x to React: start building new little components in React and patch them into your app in Angular directives. You can even apply the flux pattern to good effect within the directive while still making use of your existing Angular service infrastructure. Per Evans this would be an Evolving Order over a pair of Bounded Contexts.

jbergens 11y ago

To release a 2.0 that basically is a 1.3 without some things is not much of progress. It will be interesting to see if they can complete new planned features without breaking the api when they move through more 2.x releases and later 3.0.

_____s 11y ago
No, actually, there were quite a few new introductions between 1.11 and 1.13 (Glimmer, the new rendering engine; Actions and API changed, ED became 1.0, got more stable), and, as a result, there were numerous deprecations in the 1.13 release. 2.0 removes things that were deprecated in 1.13. Things like views, active model adapter, etc. have been extracted out in an addon. None of these things broke the API; there was always a sane (although sometimes painful) process to help you through the upgrade. There are other things planned for the next few releases, such as routable components, new component syntax, etc. but the things they will replace (controllers and the old component syntax) will be supported through the 2.0 cycle (at least that's what's said). Ember's deprecations in 1.13 were a bit of work for me, as a developer, but the new features in the past few months have done a lot of good to the framework and removed a lot of the complexity. I much prefer this way of upgrading, and I really, really appreciate the Ember team for doing it this way.
golfstrom 11y ago
It's not a marketing release, Ember is simply following semantic versioning. Many of the new features that might've slipped into a 2.0 have made it into the last few 1.x releases, since they could be made backwards-compatible; e.g. Glimmer could've been held back for marketing reasons, but they pushed hard to get it out ASAP in 1.13 in June.

chasb 11y ago

Robert gave a talk about this at Ember.js NYC last month: https://www.youtube.com/watch?v=ltzN4v-ymo4 https://www.youtube.com/watch?v=ltzN4v-ymo4

steveax 11y ago

Yes, super happy the core team keeps as a priority minimizing the pain of tracking new releases while continuing to evolve Ember. Kudos to the core team.

tsmarsh 11y ago

Except... have you seen the changes between 1.8 and 1.13? It might as well be a new framework. So far moving from 1.8 to 1.8 on CLI has taken my team 3 months, and we still need to migrate to 1.13 if we are to remain supported. Ember provides an upgrade path, but it is a long, miserable slog.

adamesque 11y ago
It sounds like the core team is contemplating doing LTS releases, which should ease the fears of anyone who worries they'll be left behind if they can't keep up. source: https://github.com/emberjs/rfcs/pull/84#issuecomment-130451156 https://github.com/emberjs/rfcs/pull/84#issuecomment-1304511...
- tsmarsh 11y ago
  I'm not sure LTS would help us. If 1.8 had been deemed LTS we may have delayed the upgrade work until it was EOL... then what? We'd still be facing months of upgrade work, but on a significantly larger code base. This is a problem of platform maturity. The Web is moving too quickly for monolithic framework solutions to keep up. ES6, web components, shadow dom etc were not part of the landscape 12 months ago. Ember and Angular are both doing admirable work in all of these spaces, but they're leaving their users in their wake. I'm just not sure what you are supposed to do if you want to build a multi-year project with modern frameworks in 2015. My current suggestion is that we don't, accepting that the web site is just a skin over your api, that needs to move with the fashion, so expect to replace it every 12 months, minimum... that doesn't go over very well with executives.
  - phren0logy 11y ago
    Sure, but does doing it all by yourself really put you that much further ahead? That does not slow the pace of change. You have more granular choices, but you have many many choices you are forced to make. If you trust the people making decisions behind the framework, it still seems like the better choice.
  - wldcordeiro 11y ago

aaronbrethorst 11y ago

Which is sort of ironic, given that Ember.js was originally called Sproutcore 2.0 [1]...But I digress. Props to Tom, Yehuda, and everyone else. I've been dithering over whether to get up to speed on Ember or React, but I feel like the 'Batteries Included' approach that Ember provides and the very aggressive approach to cruft removal is what's right for me. [1] http://yehudakatz.com/2011/12/12/amber-js-formerly-sproutcore-2-0-is-now-ember-js/ http://yehudakatz.com/2011/12/12/amber-js-formerly-sproutcor...

jhall1468 11y ago

As already mentioned, the upgrade path for large apps is not quite as simple as the line implies. Ignoring that, this concept of backwards compatibility above all things is so strange to me. How modern browsers work has changed fairly dramatically over the last several years. Not to mention a major, major overhaul of ECMAScript. And yet, every. single. time. we have something that mentions backwards compatibility being straight-forward, the top comment is always about how re-writing frameworks are bad. I don't have a problem with the way the Angular team are doing things. Angular 1.x will be supported for a long, long time. And even though this hasn't been announced, I expect the 1.x and 2.0 branch to gradually merge, requiring minor changes to code at each minor version increase. So effectively, Angular 1.4 -> 2.0 is no different than Ember 1.0 -> 2.0 with the caveat that 2.0 was planned in advance so all of the minor version changes will lead to 2.0, rather than 2.0 being the outcome of minor changes in 1.x.