4 ms·

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 le

by 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.

by aikah 11y ago

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.