4 ms·

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,

by 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
    The solution would be to do the incremental updates as they were released. Yeah it's no use to you now after you've fallen behind but it's the easiest way to be able to update your project rather than dropping behind 4-5 versions.
  - mixonic 11y ago
    > they're leaving their users in their wake. The jump to Ember.js 2.0 involves API changes, but I see no reason why the majority of application will not move forward. Your experience sounds very painful, but many Ember applications, even ones that are over two years old, have already made it onto 2.0. That is not meant to trivialize your pains, but just to challenge the idea that we're leaving people behind. Ember's 2.0 strategy is specifically designed to ensure as many people get to 2.x as possible. That is our goal. I'm rather proud of the number of mature, long-living codebases build with Ember that continue to progress with us. > 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 That is an option. The web, and single-page applications, offer unique advantages but like any platform also come with limitations. Companies like Yahoo, LinkedIn, Zendesk, Twitch, Bustle, and many others have placed big bets on this architecture though, and use it successfully.
ldpg 11y ago
My experience working through ember and ember CLI versions was that it was tedious and time consuming as well. It is not stable software and fixes don't happen or don't happen fast (so many utterances of the word "months" in the ember world). Lots of marketing though. It's not really backwards compatible, they just like to claim things like that. If you say it doesn't work, well you must be doing it wrong. Very typical of Emberjs.
tomdale 11y ago
I'm really sorry it's felt like a slog for your team. We've learned a lot from the transition from 1.x -> 2.0, and definitely didn't get everything right. That said, we think we can refine the 2.x -> 3.0 transition to make it much smoother based on what we've learned. Given how fast the frontend ecosystem is moving, we've tried to strike the right balance between delivering new features and taking care to ensure that we don't leave the existing ecosystem of apps behind. I think you'll agree that if we did nothing, our community would slowly die off as people moved to competing libraries and frameworks that made them more productive. So total stability would feel good in the short term, but long term, having to do a wholesale rewrite of your app because the framework stagnated would be much more painful, right? (You can approximate this effect by locking yourself into an older version of Ember, which sucks! People rightfully want the new features.) The goal of Ember's additive-only strategy is to deprecate features, rather than remove them. This is more work for the maintainers, but we think it's worth it because users can "refactor towards the future" at their own pace, amortized over the year and a half between major releases. Development teams have a natural ebb and flow, and that amortization of deprecations over the year means you can use lulls/downtimes to refactor the deprecations out when it's most convenient to you. We made a mistake and rushed in a bunch of deprecations in 1.13 because it was our last chance to remove features for the next year or so. In retrospect, we got overzealous, and for that I am sincerely sorry. Users like you rightfully felt overwhelmed, and that is something the entire system is designed to avoid. If there's a bright side, it's that your app should continue to work as you upgrade, and when you're ready to make the jump, you can upgrade to Ember 1.13 and refactor away all of the deprecations. Once that's done (whenever you decide to do it), you will be able to upgrade to the latest version of Ember 2.x, because Ember's SemVer guarantees means that a deprecation-free 1.13 app is compatible with any 2.x version (2.7, for example). Sorry again that it's been a slog for you. Once you're through it though, we hope you enjoy all the new features, and we certainly hope the simplifications we've made to the framework over the last year make it easier for new developers to join your team and get productive.
dasil003 11y ago
Pretty much goes with the territory. Javascript is sort of a mess right now. Everyone is figuring out the best way to do things. The exact same thing happened in previous projects of Yehuda's like the Rails merge where 3.0 brought a tremendous amount of pain, but 4.0 significantly less so. Or Bundler, where people cursed it up and down for the first two years, but once it stabilized it was amazing and now everyone just quietly uses it without problems. I really trust Yehuda and Tom's approach with Ember. Yeah there will be pain and breakage, but that's better than making a long-term commitment to the wrong thing. Over time it will converge (and I think it is already to a significant degree) on the right abstractions and then stability will come, but to do so prematurely leads to an inferior framework. If you need stability in your front-end then Ember (or god help you Angular) is probably not the wisest choice—I would even consider your options of just going server-rendered for current projects to give a bit more time for the ecosystem to mature.

by tsmarsh 11y ago

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
  The solution would be to do the incremental updates as they were released. Yeah it's no use to you now after you've fallen behind but it's the easiest way to be able to update your project rather than dropping behind 4-5 versions.
- mixonic 11y ago
  > they're leaving their users in their wake. The jump to Ember.js 2.0 involves API changes, but I see no reason why the majority of application will not move forward. Your experience sounds very painful, but many Ember applications, even ones that are over two years old, have already made it onto 2.0. That is not meant to trivialize your pains, but just to challenge the idea that we're leaving people behind. Ember's 2.0 strategy is specifically designed to ensure as many people get to 2.x as possible. That is our goal. I'm rather proud of the number of mature, long-living codebases build with Ember that continue to progress with us. > 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 That is an option. The web, and single-page applications, offer unique advantages but like any platform also come with limitations. Companies like Yahoo, LinkedIn, Zendesk, Twitch, Bustle, and many others have placed big bets on this architecture though, and use it successfully.

ldpg 11y ago

My experience working through ember and ember CLI versions was that it was tedious and time consuming as well. It is not stable software and fixes don't happen or don't happen fast (so many utterances of the word "months" in the ember world). Lots of marketing though. It's not really backwards compatible, they just like to claim things like that. If you say it doesn't work, well you must be doing it wrong. Very typical of Emberjs.

tomdale 11y ago

I'm really sorry it's felt like a slog for your team. We've learned a lot from the transition from 1.x -> 2.0, and definitely didn't get everything right. That said, we think we can refine the 2.x -> 3.0 transition to make it much smoother based on what we've learned. Given how fast the frontend ecosystem is moving, we've tried to strike the right balance between delivering new features and taking care to ensure that we don't leave the existing ecosystem of apps behind. I think you'll agree that if we did nothing, our community would slowly die off as people moved to competing libraries and frameworks that made them more productive. So total stability would feel good in the short term, but long term, having to do a wholesale rewrite of your app because the framework stagnated would be much more painful, right? (You can approximate this effect by locking yourself into an older version of Ember, which sucks! People rightfully want the new features.) The goal of Ember's additive-only strategy is to deprecate features, rather than remove them. This is more work for the maintainers, but we think it's worth it because users can "refactor towards the future" at their own pace, amortized over the year and a half between major releases. Development teams have a natural ebb and flow, and that amortization of deprecations over the year means you can use lulls/downtimes to refactor the deprecations out when it's most convenient to you. We made a mistake and rushed in a bunch of deprecations in 1.13 because it was our last chance to remove features for the next year or so. In retrospect, we got overzealous, and for that I am sincerely sorry. Users like you rightfully felt overwhelmed, and that is something the entire system is designed to avoid. If there's a bright side, it's that your app should continue to work as you upgrade, and when you're ready to make the jump, you can upgrade to Ember 1.13 and refactor away all of the deprecations. Once that's done (whenever you decide to do it), you will be able to upgrade to the latest version of Ember 2.x, because Ember's SemVer guarantees means that a deprecation-free 1.13 app is compatible with any 2.x version (2.7, for example). Sorry again that it's been a slog for you. Once you're through it though, we hope you enjoy all the new features, and we certainly hope the simplifications we've made to the framework over the last year make it easier for new developers to join your team and get productive.

dasil003 11y ago

Pretty much goes with the territory. Javascript is sort of a mess right now. Everyone is figuring out the best way to do things. The exact same thing happened in previous projects of Yehuda's like the Rails merge where 3.0 brought a tremendous amount of pain, but 4.0 significantly less so. Or Bundler, where people cursed it up and down for the first two years, but once it stabilized it was amazing and now everyone just quietly uses it without problems. I really trust Yehuda and Tom's approach with Ember. Yeah there will be pain and breakage, but that's better than making a long-term commitment to the wrong thing. Over time it will converge (and I think it is already to a significant degree) on the right abstractions and then stability will come, but to do so prematurely leads to an inferior framework. If you need stability in your front-end then Ember (or god help you Angular) is probably not the wisest choice—I would even consider your options of just going server-rendered for current projects to give a bit more time for the ecosystem to mature.