Hacker News Reader

Comment by ef4 | Hacker News Reader

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 necessary in a nicer language that managed its own runloop internally. Javascript developers who are ignorant of other paradigms often make the false claim that all the callback-driven asynchronicity is worth it because of performance, but they fail to realize that you can have exactly the same asynchronous architecture while writing code that reads synchronously.

View on HN

I don't see how this relates to the problems posted in the article. How does the lack of Proxy make the behaviour less confusing? Where does the author mention asynchronous behaviour and JavaScript's run loop?

I was just commiserating and sharing my own experience.

The problems posted in the article are really hard to judge because the author doesn't actually explain what happened.

In the first example, he doesn't try. Fair enough, it's a judgement call on whether to spend time understanding what happened. Personally, I would consider it high priority, because otherwise you have no assurance that the same problem isn't biting you elsewhere.

In the second, he says something that doesn't actually make sense: "Ember's set function has special behavior for values in the content field". I know Ember's source about as a well as anybody not in the core team, and that statement isn't even false. If I had to guess, I'd assume he's really saying something about how ObjectControllers behave as proxies for models.

I don't mean to write off whatever problems he encoutered -- they are clearly real problems, either bugs in Ember or failures of developer ergonomics. If he could point to the specific actual problems I would personally work on a patch to address them. But I don't have enough to go on.

I think you correctly identified the second problem, an example was posted below in a comment: http://softwaresimply.blogspot.com/2014/01/emberjs-is-drivin...

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.

I seriously considered going through a CPS transforming compiler for my major production Javascript application, but it's a risky step to take, relative to using a less invasive transformation like coffeescript.

It comes down to lack of mature tooling and debugability: coffeescript is easy to debug, because it's a very light level of syntactic sugar and dropping into the Javascript is easy. A more aggressive compilation step would require me to put a lot more trust in the maturity of the compiler and associated tools.

Reply on news.ycombinator.com