Live data from Hacker News

Ember.js is driving me crazy

softwaresimply.blogspot.com

71–80 of 113 posts

Re: Ember.js is driving me crazy

#71
post #36

Earlier quoted context omitted.

It works well for JS, too. Favor function composition & higher order functions for code reuse over complicated prototype hierarchies.

function composition in js can be tricky to visually parse the "types" (especially if curried).

It depends on the return value, yes. I usually try to keep modules small and use some kind of threading (needle + thread analogy, not os threads/web workers) strategy when building functions -- pulling out common patterns into globally visible utility functions that work with common types (e.g. jQuery events/objects).

It's not ideal, but in the absence of a true type system, it's all about mitigating potential problem areas.

Re: Ember.js is driving me crazy

#73
post #15

The things that are frustrating about writing an Ember app are the things that are frustrating about Javascript in general. Those "set" and "get" calls are a great example: they're an unfortunately necessary workaround for Javascript's lack of real dynamic message dispatching (like Ruby's method_missing). We all look forward to ES6 fixing this. The run loop is another example. It's a gross hack that wouldn't be neces…

I don't mind those explicit set calls as much. I prefer when `obj.foo = 10` is a side-effect-free operation that only affects `obj` instead of something that triggers bunch of layout updates and got knows what other changes as well.

I do agree on the callback thing though and I find it kind of sad that not many people use CPS compilers for JS even though things like Cofeescript and SASS are pretty common.

Re: Ember.js is driving me crazy

#74
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…

OTOH, finding removed code in your history is still a pain in the ass, unless commit messages are well and clearly crafted (which they usually aren't, and even then the keywords you search for may not be those you committed under).

VCS may need to grow a "full history" blame, which displays all hunks removed from the file.

Re: Ember.js is driving me crazy

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

Spontaneously Changing Values: What was the key that you were trying to set? On what type of object (Route, View, Controller, etc.)? There are indeed some special values and it might be something that Ember can warn you of in the console as well as be documented. I'll be glad to make some documentation changes that make this issue easier to catch if you can provide me reproduction.

Godlike Refactoring: I work on a team with a widely distributed level of skills. One of my favorite features of Ember (which both has and will continue to save me hundreds of hours) is the fact that even if you make a mess of something you can generally come back and clean it up one piece at a time. My metaphorical description of this is that "all of the crap is in nice neat little piles instead of spread on the walls."

JavaScript.next: In the next/current version of JS both of these warts should be possible to resolve using Modules and Object.defineProperties(). I firmly believe that your complaints are not centered around Ember (which I honestly believe is insulating you from the worst of it) but instead from flaws in a language that was literally designed and built in an incredibly short time (my recollection is "a week" but I can't find a source).

(Edited for clarity based upon mixonic's reply.)

Re: Ember.js is driving me crazy

#76
post #51
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…

Where did those discussions lead? "EmberJS merges with ReactJS" seems like a pretty exciting headline.

Re: Ember.js is driving me crazy

#79

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

I've actually wondered some of this myself. I think the answer is that it's some combination of both inherent complexity in UI code AND problems that you get with weak and/or dynamic languages. In any case, we're probably going to switch all of our front-end code to Haskell, so I should be able to make a comparison at some point in the future.

Re: Ember.js is driving me crazy

#80
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…

Funny talk on this subject: http://www.youtube.com/watch?v=Oj4vXMRenFo
Post reply on HN