Live data from Hacker News

Ember.js is driving me crazy

softwaresimply.blogspot.com

41–50 of 113 posts

Re: Ember.js is driving me crazy

#41

I'm an experienced web developer (Backbone is my preferred framework) whose team is migrating to Ember. It has its high points, but on the whole, it's been driving me nuts. Ember, like most modern frameworks, represents itself as MVC. But it's more like MVCLCTMRA (model-view-controller-layout-component-template-mixin-router-application, if you're following along at home). There are just so many moving pieces, and the…

If you're experienced with Backbone but want something that competes with Angular/Ember in terms of features, you should really try CanJS[1]. It has a small API surface area so it's very easy to learn but still manages to bring advanced features like Web Components to the table.

[1]http://canjs.com/

Re: Ember.js is driving me crazy

#42
post #7

" but at some point I decided that the widget was no longer needed, so I commented out the widget's markup" SOURCE CONTROL, DO YOU SPEAK IT? In all seriousness, this is a major peeve of mine - the time that you're most confident that code can be deleted is when you're removing the pieces that depend on it. If the deletion really turns out to be wrong, you should be able to restore the code from source control. If you…

I hate it as well. I do know quite a few people that do it all the time.

Re: Ember.js is driving me crazy

#43
post #7

" but at some point I decided that the widget was no longer needed, so I commented out the widget's markup" SOURCE CONTROL, DO YOU SPEAK IT? In all seriousness, this is a major peeve of mine - the time that you're most confident that code can be deleted is when you're removing the pieces that depend on it. If the deletion really turns out to be wrong, you should be able to restore the code from source control. If you…

I compleletly agree. But I will add that another solution is to keep the code alive, but wrapped in a conditional with a feature flag. This is not always a good alternative to just deleting code, but it can be a good alternative to commenting-out a block of code or using compiler directives.

Re: Ember.js is driving me crazy

#44
post #7

" but at some point I decided that the widget was no longer needed, so I commented out the widget's markup" SOURCE CONTROL, DO YOU SPEAK IT? In all seriousness, this is a major peeve of mine - the time that you're most confident that code can be deleted is when you're removing the pieces that depend on it. If the deletion really turns out to be wrong, you should be able to restore the code from source control. If you…

While you're not wrong, this doesn't speak at all to the issue that the OP is expressing. While you might think his/her style is messy, it should still be valid. Commented-out code should behave the same way as deleted code.

> Commented-out code should behave the same way as deleted code.

But it did, that's not the problem the author encountered.

The issue wasn't that commented code caused a behavior change, it's that uncommented-but-assumed-unused code caused a behavior change. The only thing that got commented out was the markup that originally invoked said code.

Re: Ember.js is driving me crazy

#45
post #23

Earlier quoted context omitted.

The mental effort required to find and pull the old code is far greater than that required to toggle a code comment, or just the line using that code. The author rightly points out bad behavior by Ember: Unused code should not affect program behavior.

True, but I find commented out code really distracting while I read a file. It's really easy to use the comment method to excess and end up with a file full of old trash code. As far as Ember's issue, we didn't see the actual code. There's almost certainly a misplaced pointer somewhere. The author made of not being a JS regular, my guess: missing `var` somewhere.

If there is so much commented code that you can not read, delete it. If I'm not sure whether I will be putting the code back soon, no way I'm willing to dig repository history.

However, commented out code is by definition free to be deleted by anybody else if it happen to be forgotten later on.

Re: Ember.js is driving me crazy

#46
post #20

Earlier quoted context omitted.

The mental effort required to find and pull the old code is far greater than that required to toggle a code comment, or just the line using that code. The author rightly points out bad behavior by Ember: Unused code should not affect program behavior.

But that's a one-time mental cost. There's also the mental cost of navigating among all that commented code every single time you need to read that piece of source.

Yes code should be deleted and then later recovered from source control.

In the event it is needed to be glanced at or restored, but you're exaggerating how problematic commenting a method out of code is. If I'm scrolling through code and see a commented out method my brain says "well that's not in use" and I move forward.

If a commented method stays in code for a few months I would complain or simply remove it myself, but it isn't hurting anything (unless in the case of Ember).

Re: Ember.js is driving me crazy

#47
post #35

Earlier quoted context omitted.

> Deleting the code and relying on source control removes the issue from top of mind. That's the goal. Your top of mind is very limited; use tools like version control to help you conserve it. > Also, it will require more work to bring back later. Then you need better version control. You can either grab the reverse diff from the commit removing it and apply that (possibly with conflict resolution against more recent…

This assumes that you knew that the code was once there, and where it was. Working on a team with partially implemented features with planned future hooks, it's just easier to keep the intent in the live code (hopefully with some good comments/docs)

Your half-implemented feature will never, ever make it into live code.

Ever.

Just delete it, you commented out code leaving scum. We all hate you. And you smell.

But seriously. Never commit commented out code. It's a cardinal sin and massive code smell. Never leave YAGNI, but maybe one day, hooks in code. Just delete it. It will never make it live and when someone actually comes to do that feature they'll usually half finish the feature before they even find your code, and then won't be 100% sure your code is supposed to do exactly the same feature and so they won't delete your cruft as they don't really know what on earth it's supposed to do.

And on top of that your code won't work because it hasn't been refactored along with all the live code, so all the property names are wrong, it references methods with signatures that have changed and probably even the names of the classes have changed.

Re: Ember.js is driving me crazy

#48
I think this is the culture shock of not working with a compiled language.

I mostly work in compiled, statically typed languages, and it can be a bit of a surprise in Javascript when you don't find out about a syntax error until execution just stops, half way through your application loading, because of some code in a function you didn't think was called.

It's a surprise. But that doesn't mean it's wrong. We just aren't using the right tools - unit tests, JSLint, etc.

Question to regular JS users - what do you do 'in place' of static checking?

Re: Ember.js is driving me crazy

#49

Earlier quoted context omitted.

I use the debugger all the time. One problem is that when you're using Ember a lot of the call stack is cluttered with Ember internal calls, which obscures things. But even after I isolated the problem down to that line, the debugger still didn't help me fix the problem.

I seem to remember reading that chrome added the ability to "black box" libraries to remove them from the debugging call stack to help with situations just like this.

its still WIP, once they provide framework authors with what we need, rest assured ember will land it.

We are actually working close with the firefox and chrome teams, to drastically improved general JavaScript developer ergonomics when debugging.

Re: Ember.js is driving me crazy

#50
post #18

I attempted to use Ember in side projects for quite a while, really dove in. Sadly, I never got productive with it. My conclusion was that Ember works for super smart people with a background in traditional MVC UI architecture (different than MVC server architecture), but that mortals like myself probably aren't up to the task. I moved from Ember to React, and it has been a joy. It does what I actually want: makes in…

What do you use for routing and models with react?
Post reply on HN