Ember.js is driving me crazy • Hacker News Board

Re: Ember.js is driving me crazy

#51

Post by machty » Tue, Jan 28, 2014, 5:39 PM UTC

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

It might not be so much a genius vs non-genius thing so much as your particular app not needing the heavyweight app-state management that Ember provides.

It's worth pointing out that the Ember core team has been approached by the React core team with the intent of unifying React's view layer with Ember's application state management, which is a major component of what Ember offers relative to other frameworks. If you haven't had to solve major problems with navigation, routing, complex nested async logic, etc., for the particular app you're trying to build, then it sounds like React would get you most of the way there, but even the React team themselves realize that for medium-large scale apps, React's only going to take you so far.

Re: Ember.js is driving me crazy

#52

Post by danneu » Tue, Jan 28, 2014, 5:40 PM UTC

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…

I hear this sentiment a lot, and I at least understand the sort of purity of deleting code instead of commenting it out, but that's the only value it seems to bring whenever I try it.

Scrubbing back into history (or remembering that there's even something to scrub back to) doesn't seem to ever be as convenient for me as it is for people that are peeved by commented out code.

I'm not that great at Git, but I'm also not trawling through history very frequently and there still seems to be a mental overhead associated with it compared to seeing some commented code a few lines away.

The article goes on to say:

    > I wasn't sure whether we would ultimately keep the 
    > widget or not, so I opted to keep the above 
    > javascript code for the controller and view around
    > for awhile so it would be easily available if I 
    > later decided to re-enable that UI element.

That seems reasonable to me.

In a file I was just working on before I decided to habitually check HN, I have two past versions of a function commented out above the final revision of the function. Next to each older revision, I've annotated some reasons why they were revised. When I continue to work on this function a week from now, I'm reminded of my efforts so far.

Someone would probably say that those annotations should be moved into commit messages and the git log should tell the story about this function.

But all that really seems to do is disperse my notes about this function across intermittent entries into this file's commit history. And once those past revisions are deleted from the current view of the file, I certainly won't remember that those notes exist for me to scrub back to in the first place.

- How do you manage this kind of stuff?

- What's your workflow for looking for and fetching deleted code?

Re: Ember.js is driving me crazy

#53

Post by hobo_mark » Tue, Jan 28, 2014, 5:42 PM UTC

oinksoft wrote: post #14

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…

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.

Re: Ember.js is driving me crazy

#54

Post by jessep » Tue, Jan 28, 2014, 5:44 PM UTC

machty wrote: post #51

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

It might not be so much a genius vs non-genius thing so much as your particular app not needing the heavyweight app-state management that Ember provides. It's worth pointing out that the Ember core team has been approached by the React core team with the intent of unifying React's view layer with Ember's application state management, which is a major component of what Ember offers relative to other frameworks. If you…

Yeah, that's a good point. The things I've been building with both have been small and relatively simple.

Re: Ember.js is driving me crazy

#55

Post by andrewingram » Tue, Jan 28, 2014, 5:44 PM UTC

danneu wrote: post #52

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…

I hear this sentiment a lot, and I at least understand the sort of purity of deleting code instead of commenting it out, but that's the only value it seems to bring whenever I try it. Scrubbing back into history (or remembering that there's even something to scrub back to) doesn't seem to ever be as convenient for me as it is for people that are peeved by commented out code. I'm not that great at Git, but I'm also no…

At work, our approach is to simply not allow commented out code to get through code review. It allows individual developers to comment out blocks, and even commit those comments if they so desire, but they never make it into master.

Re: Ember.js is driving me crazy

#56

Post by kevincennis » Tue, Jan 28, 2014, 5:45 PM UTC

shubb wrote: post #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 are…

JSHint is helpful, especially (I think) for people who don't write a ton of JS. Unit tests are obviously important. I've been using Istanbul lately to check my test coverage, and that's made a big difference. It's awesome to be able to see, quickly, that "Oh. I'm not even testing half of this function."

Sticking to some kind of style guide also helps. Idiomatic.js is a good starting point.

Also, doing some basic checking on your own is often a good idea. Look at your arguments, make sure they're what you expect, and if now, throw an error. That'll make it a bit easier to see where your problems are, since you won't have to dig around stack traces as much.

Re: Ember.js is driving me crazy

#57

Post by oinksoft » Tue, Jan 28, 2014, 5:45 PM UTC

shubb wrote: post #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 are…

Some people use type-checking compilers like the Google Closure Compiler or Microsoft's TypeScript to perform static analysis.

Re: Ember.js is driving me crazy

#58

Post by MatthewPhillips » Tue, Jan 28, 2014, 5:45 PM UTC

shubb wrote: post #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 are…

jshint is static checking. It would have caught your syntax errors. Even catches when you do something stupid like define a new function inside of a for loop. As far as type checking, typically it's not needed and can be confined in functions that care about types, you just defensively cast to the type you need. Closure's also an option if you really make heavy use of types of your application.

Re: Ember.js is driving me crazy

#59

Post by plorkyeran » Tue, Jan 28, 2014, 5:46 PM UTC

mightybyte wrote: post #40

JoshTriplett wrote: post #25

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…

> 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.

Re: Ember.js is driving me crazy

#60

Post by twerquie » Tue, Jan 28, 2014, 5:47 PM UTC

shubb wrote: post #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 are…

Generally speaking, in dynamically typed languages, unit tests are the replacement for compile-time type checking. Type safety should not be a goal, duck typing is embraced and the correct behaviour is verified.