Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ember.js is driving me crazy

softwaresimply.blogspot.com

Post reply on HN
Print view View original

91–100 of 113 posts

Re: Ember.js is driving me crazy

#91

Post by whatevsbro »

al2o3cr wrote: 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…

> SOURCE CONTROL, DO YOU SPEAK IT?

So you're saying you're an Ember.js user, huh?

Re: Ember.js is driving me crazy

#92

Post by mmatants »

Kequc wrote: post #46
ef4 wrote: post #20

Earlier quoted context omitted.

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 mysel…

Commented-out code is a "FIXME" to-do item that has no explanation of intent. If I comment out code, I always annotate it with a @todo marker and an explanation of why it is commented out. Otherwise, just delete it - commit message becomes the documentation.

Re: Ember.js is driving me crazy

#93

Post by coldtea »

hobo_mark wrote: post #53
oinksoft wrote: post #14

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.

In this day and age, why isn't there an automated way to keep file history? (like Dropbox does, but locally and with a decent interface) I am looking for something like that for Linux and my (admittedly short) research didn't turn up much.

Well, OS X has such a framework built in for apps to use.

Re: Ember.js is driving me crazy

#94

Post by coldtea »

plorkyeran wrote: post #59
mightybyte wrote: post #40

Earlier quoted context omitted.

> Your top of mind is very limited; use tools like version control to help you conserve it. Seeing a commented block scroll by doesn't waste top of mind. And if you really don't want to see it editors have something called code folding. > Then you need better version control. Have you ever tried searching a version history with thousands of commits to find a piece of code that you think you might have written awhile…

Tag commits which delete things you suspect you may want to restore later with a descriptive name and message. Occasionally go back and prune those tags when you have nothing better to do.

Yes, be a full-time source control maintainer instead of programming...

Re: Ember.js is driving me crazy

#95

Post by nathanhammond »

mixonic wrote: post #88
nathanhammond wrote: post #75

Zombie Code Apocalypse: I would love to help you identify what it is that caused that problem. I don't suspect that it is an issue with Ember itself, though note that the Ember resolver will load code when you store it in `App.Foo(Controller|View|Route|...)` if that code is "needed" (say, by visiting the Foo route). So, unless you commented out the entire declaration it is entirely possible for that code to execute.…

Just a nit for accuracy, but the implication that "the Ember resolver will load code when you store it in App.Foo(Controller|View|Route|...)`" eagerly is not true. I believe the author use an HTML comment to comment out his usage and not a handlebars comment, so the code was still being run (just hidden behind html comments). But regardless, Ember will not load everything in the App. namespace blindly- it will wait u…

I've edited it for clarity based upon my original comment. :) I actually rely on this behavior every day because the app I've built uses require.js to load values into the `App.` namespace dynamically.

That being said, now that you mention it, it seems far more likely that the issue was HTML vs HBS commenting. As an aside, what is the default behavior going to be for HTML comments inside of HTMLBars templates? That seems like a really weird edge case to decide how to handle (for developers).

Re: Ember.js is driving me crazy

#96

Post by mightybyte »

nathanhammond wrote: post #75

Zombie Code Apocalypse: I would love to help you identify what it is that caused that problem. I don't suspect that it is an issue with Ember itself, though note that the Ember resolver will load code when you store it in `App.Foo(Controller|View|Route|...)` if that code is "needed" (say, by visiting the Foo route). So, unless you commented out the entire declaration it is entirely possible for that code to execute.…

I posted a comment on my blog with more information.

Re: Ember.js is driving me crazy

#97

Post by ufmace »

Kequc wrote: post #46
ef4 wrote: post #20

Earlier quoted context omitted.

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 mysel…

I generally don't like seeing commented-out code in source control because you don't have any idea why it was commented out. Is it something that you added to debug while in the middle of a bug fix, and thus now useless? Is it a half-done refactoring that you ran out of time for or ended up not needing? Is it an attempt at a speedup or new feature that didn't work out? Did it have some tricky bug and get replaced by code that fixed it?

I can't think of any reason to do it that isn't a half-assed attempt at something a good source control system does much better. If you have lightweight branches, blame, and logs you can search and check by date, along with good changeset comments, then you already have everything your commented-out code can do, and all in the same place and system, instead of spread out into several different systems.

Re: Ember.js is driving me crazy

#98

Post by jairtrejo »

Kequc wrote: post #46
ef4 wrote: post #20

Earlier quoted context omitted.

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 mysel…

The scary part for me is uncommenting it, because the code has been removed from normal QA and testing (automatic or manual) and you don't know what evils you are unleashing upon the world.

Re: Ember.js is driving me crazy

#99

Post by mightybyte »

jairtrejo wrote: post #98
Kequc wrote: post #46

Earlier quoted context omitted.

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 mysel…

The scary part for me is uncommenting it, because the code has been removed from normal QA and testing (automatic or manual) and you don't know what evils you are unleashing upon the world.

That's because you're not using Haskell. :) Herein lies the crux of my point. Haskell's purity and strong static types allow you to make lots of very strong assertions about what kind of evils you might be unleashing.

Re: Ember.js is driving me crazy

#100

Post by mixonic »

nathanhammond wrote: post #95
mixonic wrote: post #88

Earlier quoted context omitted.

Just a nit for accuracy, but the implication that "the Ember resolver will load code when you store it in App.Foo(Controller|View|Route|...)`" eagerly is not true. I believe the author use an HTML comment to comment out his usage and not a handlebars comment, so the code was still being run (just hidden behind html comments). But regardless, Ember will not load everything in the App. namespace blindly- it will wait u…

I've edited it for clarity based upon my original comment. :) I actually rely on this behavior every day because the app I've built uses require.js to load values into the `App.` namespace dynamically. That being said, now that you mention it, it seems far more likely that the issue was HTML vs HBS commenting. As an aside, what is the default behavior going to be for HTML comments inside of HTMLBars templates? That s…

Oh my man, you really need to dig into the resolver! You can avoid the App. namespace entirely if you already use modules. This is what Ember-App-Kit and Ember-App-Kit-Rails already do with ES6 modules, just transpiled to AMD internally.

And yeah, I'm unsure of that the behavior will be in HTMLBars. I really hope it doesn't touch logic inside HTML comments- that would be quite nice.

Post reply on HN