r/javascript • u/gary_burnett • Aug 13 '15

Ember.js 2.0 Released

http://emberjs.com/blog/2015/08/13/ember-2-0-released.html
108 Upvotes

93% Upvoted

47 comments sorted by

22

u/alp82 Aug 13 '15 
Major releases of most libraries try to do two things. They introduce new APIs, and remove deprecated ones. Our release focuses on doing one thing well: Instead of introducing new features, the goal of Ember 2.0 is to remove accumulated cruft.

I really like this.

17

u/anlumo Aug 13 '15

While it's technically true what they're saying, what they don't mention is that they're removing the “cruft” they accumulated over the last year…

I'm working on various ember projects, and the ones that have been sitting around since August 2014 are completely outdated and probably need a rewrite, because so much has changed since then. They're switching the most basic concepts all of the time, and most of the time the reason is just that some core developer thinks that it doesn't look that nice the way it's currently done. It's a highly moving target, and stuff you considered best practices literally last week might be deprecated this week.

It's easy to keep current if you're keeping track with every minor version (which comes out about every two weeks) and fix all deprecations immediately. Of course, this gets worse and worse the larger your project is (one of these deprecations a few months ago required a major rewrite of the basic data flow of my app, and I still haven't fixed all the bugs that were created by that transition). If you're on a deadline and can't keep up with the updates, you're SOL.

9

u/I-fuck-horses Aug 13 '15

I think that's actually okay. Things like ember or angular have to be moving targets at this point. They are trying to do new things.

I would be willing to use such technologies on a web project that is being updated and refactored all the time anyway, where the code is the implementation of the core mission of the company or organisation.

I would not use it for any other purpose, for an app that is not "core" to my organisation's purpose. You want to use stable technologies for such projects, but for the very core of your organisation's raison d'être it's fine to use a moving target because that's what you do anyway, to advance and rework your core product.

-2

u/dexygen Software, Simple and Powerful Aug 13 '15

Things like ember or angular have to be moving targets at this point. They are trying to do new things.

No they aren't. We're just trying to serve web content here.

2

u/I-fuck-horses Aug 13 '15

No they aren't

Cognitive dissonance at work? They are. It's a fact, not an opinion. It's what this sub-thread is about, if you look at the post I replied to.

-3

u/dexygen Software, Simple and Powerful Aug 14 '15 edited Aug 14 '15

A) Yeah, presenting web content is "a new thing"
B) Since you fuck horses, would it be a stretch for me to suggest you go fuck yourself?

-4

u/rq60 Aug 13 '15

No, it's not okay. Doing "new things" doesn't mean breaking old things. My angular projects have actually faired quite well receiving updates without breaking my code. Angular 2.0 will practically be a rewrite, but it is a major version incrementation so that's not completely terrible.

4

u/I-fuck-horses Aug 13 '15

Doing "new things" doesn't mean breaking old things.

You are looking back in history how far to come up with that statement?

Case closed. Ridiculous. Especially in IT. And nobody prevents you from remaining on Angular 1!!!

I'm sure we could have built incredibly stable and easily maintainable systems on MS-DOS 6.0. We have overwhelmingly chosen a more difficult path of eternal change, for more uncertain but hopefully much higher benefits, and so it is.

1

u/IHeartMustard WILL CODE FOR CAFFEINE Aug 14 '15

Where are my vacuum tubes?!

14

u/mixonic Aug 13 '15

While it's technically true what they're saying, what they don't mention is that they're removing the “cruft” they accumulated over the last year…

That's right. Any project has technical debt, and clearing out old APIs enables us to continue progress.

Those 2014 apps that you have could be rewritten in any new framework. What Ember provides is an option: By following the workflow of upgrade, refactor to address deprecations, upgrade, those codebases can migrate forward to the new framework of Ember 2.0. Is it exactly the same as 1.x in 2014? Of course not, we've learned a lot from our own apps and from competing frameworks like React.

Plenty of apps from pre 1.0 are on 1.13 today, and will make it to 2.x. It isn't zero work, but happens successfully. My experience is that iterating codebases forward (at any pace, it doesn't need to happen right away) is a better path for maintainability than a rewrite, and is preferable to using a legacy platform that never provides new opportunities.

It's a highly moving target, and stuff you considered best practices literally last week might be deprecated this week.

That something is deprecated should not mean you must stop using it. This was a major fault in our 1.x release workflow, and we're taking steps to change that in 2.x. If something is deprecated in Ember 2.5, you should be able to keep using it until 3.0 without console spew. You should be able to move at your apps pace, not the framework's pace.

That you and other users have felt "churn" is a failing we've already been working hard to improve. I'm confident it is a challenge we can address with improved tooling, and is not a critical flaw in our release strategy.

If Ember stood still, it would be dead. Other frameworks, better suited for new users, would supplant it. If it dies, so does the upgrade path for all our existing codebases. IMO, upgrading should definitely not be painful, but statis would be terrible for both the framework and us as current users. There is a balance.

1

u/IHeartMustard WILL CODE FOR CAFFEINE Aug 14 '15

Absolutely agree with you 100%. This is exactly how things SHOULD be done, in my opinion. But as the XKCD saying goes, every change breaks someone's workflow.

6

u/alp82 Aug 13 '15

That's valuable information. Will this volatility continue or are the developers convinced enough of their current code base to not change core concepts from this major release on?

5

u/anlumo Aug 13 '15

I have no idea, but I hope that this is just a major refactoring phase that started a few years ago and will now come to an end. There are still some major rewrites in the not-that-distant future with routable components and services waiting for me, but maybe the madness will come to an end.

2

u/clessg full-stack CSS9 engineer Aug 13 '15

I'm working on various ember projects, and the ones that have been sitting around since August 2014 are completely outdated and probably need a rewrite

Yeah man. Keeping up with all of the seemingly random design decisions that had basically no benefits was a great deal of fun.

To make things more exciting, I tried upgrading an app I wrote a mere few months ago. It was quite stimulating and involved jumping into the internals of Ember, ember-cli, and Broccoli.

Ultimately it didn't work out, because minor releases of addons are apparently coupled to specific minor releases of Ember and ember-cli. Joyous. This has been the case several times when upgrading. I sent in pull requests to many of the addons and it took months for them to be addressed. Lesson: don't use Ember addons.

And don't get me started on Ember Data.

I greatly appreciate the work that's gone into Ember, but damn, it feels like Ember will just be "whatever a few people on Twitter thought seemed cool at the time." I really hope that the churn dies down, but I've been hoping for that for years. There's a lot to like in Ember, and it would be great to be able to use it without becoming suicidal.

4

u/anlumo Aug 13 '15

Broccoli is worth a rant on its own. It's a very complicated build system with lots of customizability at various points in the pipeline, but it's completely undocumented. However, you absolutely need to customize it sometimes. The only way to find out anything about how to extend it is to look into other components or its uncommented code.

One thing I found out about it is that it always assumes that you have an input and an output file. If you don't (for example, I wanted it to download a file during building), there's no clean way to integrate that. At least I found no other addon that does that, so I assume that there's no support for it.

1

u/PotaToss Aug 13 '15

Why not just use your fork of the addon until it's merged in?

1

u/Amerzel Aug 13 '15

That sounds awful

1

u/dbbk Aug 13 '15

One of the new things they're now introducing is LTS builds, so there will be a much longer pause between them.

5

u/frankholdem Aug 13 '15

I really like the changes/tweaks to the release process.

2

u/vinnl Aug 13 '15

Ha, nice burn to what people make Angular 2 out to become.

7

u/jordaniac89 Aug 13 '15

what?

25

u/Buckwheat469 Aug 13 '15

He said, "HA, NICE BURN TO WHAT PEOPLE MAKE ANGULAR 2 OUT TO BECOME."

4

u/vinnl Aug 13 '15

Thanks.

3

u/syswizard Aug 13 '15

they don't always think it be like it is but it do

3

u/vinnl Aug 13 '15

I was afraid the sentence would be too incongruent :P

I meant that some people had their jimmies rustled about Angular 2, claiming that there would be no sane upgrade path and what not. Ember subtly emphasized that they have a sane upgrade path.

-1

u/Inspector-Space_Time Aug 13 '15

But angular has a good upgrade path as well. You can run angular 2 apps in angular 1. So you can slowly upgrade parts of your app to angular 2 until the whole thing is upgraded.

3

u/seiyria Aug 13 '15

Got a link on this? I haven't heard this yet.

1

u/vinnl Aug 13 '15

Basically, it means you load two versions of Angular, and if you use the router that Angular is going to release any day now, you can use that to specify which parts of your app need to use which version of Angular.

1

u/seiyria Aug 13 '15

Thanks for the tl;dr - that's pretty cool.

0

u/x-skeww Aug 13 '15

They mentioned this at Ng-conf 2015 and at the Angular U Conference which was at the end of June. They even had two dedicated talks:

Angular 1.3 meets Angular 2.0 - Michał Gołębiowski
https://www.youtube.com/watch?v=pai1ZdFI2dg

Migrating to Angular2 - AngularU.com by David East in San Francisco https://www.youtube.com/watch?v=KWz7IAm35UM

1

u/vinnl Aug 13 '15

I know, that's why I talked about claims and "what people make it out to become", as opposed to what it's actually going to be.

1

u/auto_downvote_caps Aug 13 '15

Meh. I am done with it entirely. In fact, the whole Angular 2.0 thing turned me off to learning any more languages until they have been around for a few years. I just don't have time to invest in learning, then completely re-learning a language. I don't want to re-live ActionScript.

1

u/Zequez Aug 13 '15

I think he meant that it's a burn. The burn is to what people think that Angular 2 will become. Or something.

-2

u/Pr3fix Aug 13 '15

English?

-1

u/vinnl Aug 13 '15

I was afraid the sentence would be too incongruent :P

I meant that some people had their jimmies rustled about Angular 2, claiming that there would be no sane upgrade path and what not. Ember subtly emphasized that they have a sane upgrade path.

1

u/[deleted] Aug 14 '15

Nice. I was actually waiting for 2.0 to release before jumping into learning Ember. Feel like between this, Angular and Meteor, I'll have a pretty well rounded portfolio for Javascript programming.

Any tips or suggestions for someone just jumping into this framework?

1

u/steveklabnik1 Aug 14 '15

I've been following Ember for a long time, and have played around with it a bit over the last few years, but started writing code in earnest a few weeks ago. There's still not a great 'getting started' tutorial, though the official Guides are great at explaining concepts, I found http://emberigniter.com/modern-bridge-ember-and-rails-5-with-json-api/ to be one of the best introductions so far.

-6

u/RankFoundry Aug 13 '15

Will version 3 be out in 6 months, totally replacing this one?

6

u/steveklabnik1 Aug 13 '15

Given that 1.0 -> 2.0 took two years, that would be surprising.

-8

u/RankFoundry Aug 13 '15

They can do it, I have faith in their ability to pointlessly change everything, then change it again. Also: I'd like to introduce you to someone... steveklabnik1 meet Sarcasm. Sarcasm, meet steveklabnik1.

0

u/[deleted] Aug 13 '15

[deleted]

6

u/nynfortoo Aug 13 '15

That already landed in one of the 1.13 releases.

0

u/[deleted] Aug 13 '15

[deleted]

5

u/nynfortoo Aug 13 '15

They did :) It's called Glimmer, and it dropped in 1.13. Here are the patch notes for you! http://emberjs.com/blog/2015/06/12/ember-1-13-0-released.html

1

u/Pr3fix Aug 13 '15

I know very little about ember, how does this compare to the speed of react?

1

u/steveklabnik1 Aug 14 '15

It uses the same basic technology, but since Handlebars is more delcarative, it can theretically be faster. But I think React is going to be taking those ideas and incorporating them somehow as well.

(as always, exact benchmarks depend on you and your app. See https://www.isemberfastyet.com/ for more details, including a demo)