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

61–70 of 113 posts

Re: Ember.js is driving me crazy

#61

Post by rgbrgb »

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…

Yep, compilers turn out to be a pretty cool idea :).

I don't think anyone's doing anything 'in place' of static type checking exactly. Oftentimes I'll check if a method exists on an object before calling it. Usually when I'm "type checking" I really just want to know if an object has a certain attribute. That gives a fair amount of flexibility because polymorphism is built in.

I think by and large the errors that would be compile-time errors in a statically typed language are caught with unit tests (I use mocha). For front-end work, end-to-end testing has also gotten quite good and easy. Take a look at karma if you're interested in a good front-end testing workflow.

Re: Ember.js is driving me crazy

#62

Post by taude »

mattmanser wrote: post #47
taude wrote: post #35

Earlier quoted context omitted.

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

Haaa....I hate me, too.

Seriously, though, we do it all the time. Successfully. We even write skeleton code, and have other people finish it off, or take the half-baked idea and implement it properly. Sometimes in this sprint, sometimes in the next. We tend not to let these things stagnate though, so if the spec changes, the ideas are usually ripped out along with them. A lot of the cruft eventually comes out during code reviews...

It's definitely an anti-pattern, using one's code base to communicate....but the right team with the right processes, can work for the short-term. (short-term vs long-term is probably the key here)

Re: Ember.js is driving me crazy

#63

Post by mightybyte »

mattmanser wrote: post #47
taude wrote: post #35

Earlier quoted context omitted.

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

This wasn't a half-implemented feature. It was a fully implemented and debugged feature. I was experimentally removing it in favor of a different approach and didn't want to have to go dredging through source control or reinvent and debug it later if I decided we needed it.

Re: Ember.js is driving me crazy

#64

Post by jessep »

thatthatis wrote: post #50
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…

What do you use for routing and models with react?

I haven't handled routing yet, a lot of people seem to use https://github.com/flatiron/director, which I would probably do. This is the one area where I missed something from Ember.

For models, I've just rolled my own so far. I've experimented in one small project with having a global state object that cotnains all application state data, and then just having domain fns that operate on that data. Inspired by the react people's descriptions of "flux" architecture. It felt really nice.

When using Ember, I got really confused by Ember's Ember Data vs. Ember Model vs. whatever conversation. Again, I just didn't really know what to do here, and I attribute it to my own shortcomings.

Re: Ember.js is driving me crazy

#66

Post by ianbicking »

He points back to static typing, but honestly I think UI code is harder to keep organized than service code (which I presume is what the Haskell backend does). Usually it's the UI that has to swallow the biggest chunk of the mismatch between the programming model and the user model – and as you move to smarter clients like you would with Ember.js, you end up pushing nearly all of that to the client. And you have to start interfacing with substantial complicated pieces of code, like the browser, code that every UI has to not just use, but negotiate with. All this complexity can be a way of coping with this system – not just coping with the system of a dynamically typed language, but all the many conflicting constraints in a browser environment implementing a UI for real people.

That said, there are differing opinions on which part you should "simplify" through a framework. Some of them are going to feel more magical than others. And when you come in with preconceptions about what makes a good environment, you're going to think about how the framework and environment lives up to your ideal. Some things you fix, some you leave as they are – and choosing the right battles is incredibly important. But service code and UI code are different sorts of warfare against complexity, I'd be skeptical of intuitions across the two domains. (None of which means Ember.js gets it right either – but if they don't, then I doubt the why is they just need a statically typed language.)

Re: Ember.js is driving me crazy

#67

Post by rxcfc »

I understand the frustration of the author, but it's hard to tell exactly what the source of his issues is. Not enough information is provided in his descriptions to actually understand what is going on. I suspect that either he has run into a bug (which of course should be fixed) or that he's misunderstanding the behavior. It's very possible that he was given some bad explanations for the behavior which has further confused him. I've reached out to him to see if I can get some more insight into the details of the issues.

Re: Ember.js is driving me crazy

#68

Post by ulisesrmzroche »

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.

The bug could have been avoided by using Handlebars comments, rather than using normal html comments.

Re: Ember.js is driving me crazy

#69

Post by ufo »

Can anyone who is more experienced with ember help explain what was going on in those two weird examples in the OP? (Commenting a widget affecting another one and setting the "bar" field also changing the value of "foo" field)

Re: Ember.js is driving me crazy

#70

Post by mattgreenrocks »

thatthatis wrote: post #27
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 was expecting an ember vs angular holy war in the comments, not a when-to-comment-out-vs-delete holy war.

It's an easier argument than purity-vs-no-purity.
Post reply on HN