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…
Ember.js is driving me crazy
41–50 of 113 posts
Re: Ember.js is driving me crazy
#42" 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…
Re: Ember.js is driving me crazy
#43" 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…
Re: Ember.js is driving me crazy
#44" 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.
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
#45Earlier 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.
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
#46Earlier 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.
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
#47Earlier 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)
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
#48I 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
#49Earlier 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.
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
#50I 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…