Why i'm leaving ember

I see your point, but all of this is totally non-obvious to any new Ember developer. And why not make the “calling set on destroyed object” stuff a warning instead of an error?

I agree it is totally non-obvious to developers without exposure to other programming environments. But that’s part of what you need to learn, the same way you learn to free() memory in C, delete objects in C++, use with keyword in Python, invoke the close method of objects that have one in Java…

As Javascript emerges from being a quick-and-dirty webpage gimmick to being a solid development platform, javascript developers too will have to learn correct programming idioms eventually.

Maybe the documentation should insist more on this. I believe there should be a section about integrating external code and common caveats.

But, yes, it would be possible to make the check a warning indeed.

Actually, I believe only the debug version of ember does this check. If you load ember.prod.js instead, all asserts should be gone, including this one. On the other hand, if you load ember.debug.js (the default version), it seems to be reasonable that such mistakes trigger failed assertions. After all, in debugging mode, you’re trying to pinpoint code issues.

1 Like

How do Angular and React handle this situation (if at all)?

Angular does have what they call $destroy events, and proper cleanup in those is mandatory. However, it does not have computed properties, so I doubt it can detect those errors easily.

Interestingly, this article features something very close to your code sample, that is: setting a timeout, and then destroying the object without doing the required cancelling of the timeout.

From what they say, this can lead…

all the way from code that fails silently to code that raises an exception to code that makes repeated $http requests to your server for no reason. The trick to managing your $timeout timers properly is to cancel them in your $destroy events.

That would seem to confirm that the bug is not detected by Angular, and random, difficult to debug behavior ensues. Granted, the article is dated from end of 2013, but reading the comments section, it’s obvious that nothing has changed in this respect as of today. (not that I blame them: detecting this kind of bug is tricky).

Also, from angular official documentation for $interval:

Note: Intervals created by this service must be explicitly destroyed when you are finished with them. In particular they are not automatically destroyed when a controller’s scope or a directive’s element are destroyed. You should take this into consideration and make sure to always cancel the interval at the appropriate moment.

(emphasis mine)

Fair enough. I really can’t compare. This is the first time I hear about this reasoning - or, for that matter, about Ember.run.cancel (though, to be fair, it is mentioned in the return value description of the Ember.run.later documentation). The problem ist that if you learn C there’s a gazillion resources and (hopefully) all of them tell you to free your memory etc. There should really be a section about proper “resource management” (or whatever you want to call it) in the guides, because otherwise, how could you figure this out?

Ok, maybe you’re supposed to know this if you do JS development. But one of the great assets of e.g. Rails is that its guides not only teach you the framework but also web development in general. The Ember guides, it seems, are too much about Ember and not so much about SPA development with Ember. Maybe that’s the crucial issue. I don’t know how Angular or React docs compare in this matter.

Anyway, thanks for highlighting why this behaviour makes sense. Just a followup question:

Right, but I think in the case I mentioned it should not be a problem? I mean, yes, you potentially keep a handler around longer than necessary but it only runs once anyway, so it should not cause a memory leak. Now, if it were something that runs regularly, you’d be right, so I guess it helps to know the “right” way to solve this.

I think maybe Fryie has stumbled onto one of the bigger problems.

Ember seems to be positioning itself as something that you move into after you know SPA development.

But for the masses, they would have to see significant benefits to go through the learning curve of understanding how to build an SPA (with React, Meteor, Angular, etc…) and the go through another steep learning curve to re-build it with Ember.

It’s doubling the learning curve by trying to assume that your users already know SPA. Not a bad approach if you are more clear about who your target users are, but that’s not how Ember is being positioned.

@Fryie it is a completely fair point. There is a huge lack of emphasis on proper coding practices in most JS resources available at large, probably due to this gimmicky background, and that’s something that should be improved. And since most JS newcomers turn to frameworks, the frameworks have a big role.

Ember documentation is coming back from a terrible state. Documentation for v2.2 is a huge improvement over previous versions, but there is a lot of things still lacking. For instance, a section with common problems, how to approach them and what pitfalls lurk around would be most welcome.

I really hope at some point in the future, it will be good and thorough enough that it could lead JS beginners into creating quality code. When I’ll be less busy coding and have some time to start contributing to Ember, I think I will focus on docs. The work of Ember team is amazing, but the amount of what’s to be written and maintained is huge.

Right, but I think in the case I mentioned it should not be a problem?

This specific example won’t be a problem. Though once I got used to doing proper cleanup, I found it easier to do it consistently throughout my applications, rather having to wonder everytime I hit an odd bug, whether one might have run loose.

@jesmith:

It’s doubling the learning curve by trying to assume that your users already know SPA.

Interesting way to put it. Most likely true. Ember would benefit a lot from more newbie-oriented guides.

I also strongly disagree with the “negativity” complaint. I can’t point to a single negative comment here that is straight-up ranting without a carefully crafted flow and argument. Anyone/anything that cannot receive and learn from criticism will never improve, just sayin…

2 Likes

With Ember, I am like watching “game of thrones” (some killed, some newly born). But I admit that it’s quite a journey and I love watching! It does pain me to catch up …but the changes are great and making sense. I hate it, but I love it.

2 Likes

OK - I get it - everything loads into the browser - and navigation now works directly in the browser - AJAX requests can get more data as needed.

Nice - and to me EmberJS is more pure than Angular - I like the opinionated aspect and the insistence on URL’s linking to a unique resource.

I like ember-cli - nice way to be able to create routes quickly - nice to be able to easily fire up the app using nodejs so it can be viewed - and nice to be able to create the files to be distributed (in the /dist directory).

Also, the fact that EmberJS (like Angular) is purely browser side MVC - so we’re just deploying HTML and JS and this can be served up by any web server (Apache, Nginx, etc).

OK - niggles - the current release needs to be tidied up: npm install -g ember-cli@2.2.0-beta.6 ??? And this is in the docs for 2.3.0. Also, ember seems to be installed via bower - where ember-data is installed via npm - or the other way around - this needs to be clarified in the install doc.

Also - the issue of components replacing routes etc needs to be more clearly explained

So - overall - a bit heavy going - but seems to be going somewhere.

BUT.

All our work these days to providing web pages MUST cover the fact that the pages need to be responsive - and let’s face it Bootstrap is the main game in that particular town. But - although ember-bootstrap seems to be OK - the drop-down menus do not work.

I’m wondering if this is a key problem with Browser side JS MVC frameworks in general. They need to control all click events to control the routing - and this stops the Bootstrap menus from working.

Anyway - I get the feeling that Bootstrap isn’t really supported - so for a current project I’m switching to a PHP based framework. At least that sends out pure HTML and then Bootstrap can do its thing in the browser.

It will be interesting to see any responses to this post. The worrying thing is that I’ve asked for recommendations for a responsive framework nearly a year ago and there wasn’t anything definite which came back:

This is just my opinion based on my perception of things.

When it comes to the types of applications many/most people who are building with rich JS MVC such as Ember or Angular often times CSS frameworks like Bootstrap and Foundation don’t fit their needs. Frameworks in general, of any type, make sense when there is some amount of time/money to be saved.

Looking at some popular Ember.js apps: Discourse, Travis-CI, Intercom, Bustle and Twitch. Often times these apps are built by teams with full time designers, frontend engineers, etc. They have highly specific designs and CSS frameworks may hurt more than they help.

So what I’m suggesting this translates to is NOT incompatibility with CSS frameworks, but rather just a low demand for them in the community. After all, ember-foundation and ember-bootstrap addons exist and do get some amount of usage (looking at npmjs and github stats). But it’s my belief that many of us in the community are working on well staffed teams who build very unique, highly customized UIs.

Again, just my opinion based on many conversations I’ve had with others :slightly_smiling:.


I don’t think this is the case at all. Ember does not need to control all click events. Often times issues like this arise from jQuery based plugins being improperly initialized or improperly wired into Ember’s lifecycle. This may be a point of confusion for some new to Ember, but I don’t see it as a weakness or cause of failure.

Thanks for the response.

I think you kinda confirm my perception - that Ember is a great in browser MVC framework and produces some real benefits in sites such as discuss.emberjs.com - but as you say - it needs effort on the presentation side and it’s not easily possible to just drop in Bootstrap and we’re away.

I’m keeping my eye on EmberJS - and for the right project it will be a great fit. My current needs are for a v simple site and Bootstrap so I’m looking at (probably) Silex.

Cheers!

That’s not exactly what I meant. I was trying to say that Ember.js isn’t now, nor has it even been, focused on providing you with an out of the box CSS framework. Obviously CSS is a part of every app and ember-cli does a great job of offering you a lot of flexibility (SASS, LESS, etc). But the point that I was trying to get across was that for many people who use Ember, they have widely varying CSS needs. If many people had similar CSS needs in the community, then I’d expect you would see more high profile ember-addons focused around a CSS framework and/or utilities. But to my knowledge, we haven’t really seen that.

And I don’t think this something that’s exclusive to Ember. My impression is that this is just the nature of the industry right now. Many web apps really aren’t designed from a template or designed to be similar. Even with good UX, designers often strive to differentiate their apps from others in the market.

Anyways, just my opinion.

These last weeks I have been evaluating(and implementing proof of concepts) frameworks for a pretty complex system. The frameworks/libraries evaluated where React.js, Angular.js, Polymer.js, Ember.js, knockout.js and Backbone.

My conclusion is that there is currently no javascript framework at the same level as Ember+Ember CLI.

Having started from scratch to create an IDE experience I want to bring up some of the selling points that I think bring Ember.js head and shoulders above its competitors:

  • Conventions
  • Built on top of well known and recognizable patterns
  • Separation of concerns
  • Good API documentation
  • Enforces workflows that provide speed and accuracy (less errors)
  • An amazing tool-chain with amazing support for debugging, deprecation help etc.
  • For once, useful error messages!!!
  • A big plugin-in repo for any need (and if something is missing, a clear interface to create your own)
  • A big component repo
  • Dependency Injection (via the locator pattern OR via the IoC pattern, your choice)
  • ES6 NOW (with the help of babel)
  • easily extendable and configurable

I could go on with a lot of clear examples, but I guess I have driven my point across. Now, before you ask I will try to provide some information on what I felt was wrong with the other frameworks.

React: To be honest I mostly do not like the imperative approach. I guess the biggest thing is that react is not a full framework and as such does only try to solve a subset of the domain problems. If you like the backwards feel to its structure and don’t mind learning some new patterns then react could be for you, it is just not for me.

Angular: In short - angular is a hack. It becomes blatantly apparent once you go beyond the simplest applications. If you then consider the atrocity that is directives you will have a hard time not puking in your mouth. From my point of view the popularity of angular must be attributed to marketing and the promise that simple “hello world” apps present.

Knockout: It was just to small for what I wanted, I did not want to choose X more libraries to complete my stack. Having that said the HTML first approach is interesting, but the amount of javascript that might be inside a html attribute quickly becomes ridiculous. Also the component concept has been slapped on, but it has many flaws, one being that the components are not inheritable (through the framework, you can still do it the old fashioned way with prototypes) and it does not provide a way to use things like reopen(kind of evil?!)/mixins/behaviours.

Polymer: The only framework apart from Ember that actually is getting seriously considered. The basic syntax is nice (there are some features that really makes you puke once you start trying to do some more complex things with bindings, but magnitudes better than Angular. But again it is not a full framework, it only solves a subset.

Here comes a chocker! The promise of Polymer is currently a lie!! I feel the need to detail what I mean.

Polymer != Web Component! Polymer describes itself as a thin layer of sugar on top of vanilla web components, but in reality they are adding a lot more to the mix, even stuff that has been removed from the standard or that is not even being close to being resolved. Do you really want to build a huge app with those underpinnings.

Web Components are broken. A web component gives the illusion of true isolation, but in reality is not isolated at all. Ok, so if you use shadow-dom then your CSS gets true isolation, but everything else does not. This means that any loaded libraries will bleed into the global scope.

Ok, so you can try to solve it your self by using closures or trying to use libraries like requireJS with web-components, but it does not come out of the box.

The import feature does not solve the problem of loading a library multiple times, it only solves the problem of trying to load the same exact URL multiple times.

It is hard to properly solve DI, IoC with Polymer.

The idea that everything is a component is only viable in smaller applications with few to no services, do you really want your data-store, your system wide services and workers to have to be components? to have to be attached to the DOM just to run?

Currently the specs do not provide a standard way of getting meta-data(A manifest maybe?) from your registered component. If you prior to instatiation would want to analyze a list of possible “valid” attributes that this component will use and listen to once it has been loaded to the DOM, then you are out of luck. Every tech built on web components solves this issue in a different way so composing with polymer and non polymer components becomes a problem if you want to analyze the components prior to instatiation. This space actually has a lot more issues, but they are to extensive to bring up here.

Ok, so you might say HEY ember components do not solve the above problems, and worse they do not use shadow-dom so they dont get isolated CSS.

To that I would answer that you are both right and wrong. Ember solves the issue with DI/IoC. Also with an Ember-Addon you can add the possibility to have “virtual” isolated css (the code adds a generated prefix to the component CSS). Ember has a proper Service concept and Ember has a proper scheduler none of witch have to be attached to the DOM to work.

Other than that you are absolutely right, the problems are the same with the difference that Ember components never tried to give the illusion of solving those problems.

In practice there is currently only one real benefit with real web components, they REALLY register a new element that you can freely use in your document. If you are writing a small to medium app and don’t need all the bloated help that you get with Ember, and you don’t mind having services, datasources etc. as web components then I would really recommend Polymer just as long as you remember that it is truly to early to say Polymer === Web Components.

2 Likes

Thanks @Claudio_A.D_Medina, it’s always interesting to hear other peoples take on the JavaScript framework landscape. The only other framework I’d even look at is Aurelia. IMO they are on the same path as Ember and have a newer, fresh look on things. However, I also think Ember is more mature, in that they’ve already delt with (or are currently dealing with) the more complex scenarios (such as render performance and Fastboot).

Ill be checking out Aurelia now, always fun to look at other frameworks. The best way to find the good and the bad in anything is by expanding the sample :grinning:

Watching a little bit of that Aurelia presentation and scanning the docs made me realize something about Ember I never really gave much thought to before.

The Aurelia welcome video starts with an index.html file and really gets into the markup and view centric stuff.

With an ember cli project the index.html file is one of the last things that bubbles up to my attention.

Not a slight on Aurelia, just interesting.

I find with my day to day Ember experience I am not really thinking about markup, views or rendering much at all. This may seem counterintutive to anybody who is very much within the mindset of a “traditional” web developer. I have been slinging HTML and CSS together since the mid 90s and it is always a slog no matter how experienced one is with it. But I understand the impulse to drop down into the markup and go to town.

With Ember I am more often thinking about components and higher level application structure and constructs. And I find that this suits me well, personally. It is also perhaps one of the things that I instinctively don’t like about React.

These may boil down to personal style preferences and comfort levels that vary from person to person.

When I do have to worry about markup in Ember it is usually pretty effortless and well contained within a particular component’s boundaries.

When I see stuff like this it feels really foreign. Particularly seeing the html tags after a return statement. But I can understand why some people might find comfort in this.

var HelloMessage = React.createClass({
  render: function() {
    return <div>
      <h1>Hello {this.props.name}</h1>
      <p>some text</p>
    </div>;
  }
});

I agree with your feeling on react.

react, ext.js and some other libraries seem to be imperative JavaScript centric where the templating with HTML becomes a second-class citizen within the JavaScript.

knockout.js is the total opposite were HTML is king and the content of two attributes is the embeded second-class citizen JavaScript.

Ember and Polymer(even if Polymer elements are single-file) try to totally separate the JavaScript and the template.

Personally I really like the separation.

I think the best thing anyone could do, would be to delete this post… It’s outdated, and well - moot. Trying to do something and then getting frustrated “cause things didn´t go as expected” doesn’t warrant top billing in this forum. I don’t see how you can leave Ember if you were never a part of it.

Despite the initial rant, this thread has sparkled very interesting discussions, somewhat scattered but with valuable content. Deleting that would be a shame. Should any action be taken, locking would be more than enough I feel.
That said, it is probably useful as a focal point for people wanting to express some legitimate frustration about Ember. If it got locked, I bet new ones would appear within days, if not hours.