Live data from Hacker News

Ember.js is driving me crazy

softwaresimply.blogspot.com

11–20 of 113 posts

Re: Ember.js is driving me crazy

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

Exactly. If you're committing large sections of code that are commented out you're doing it wrong.

Re: Ember.js is driving me crazy

#12
post #3
post #2

Convention over configuration achieved with opaque magic can actually harm the dev process more than it helps.

Haskell: favor composition over configuration over convention.

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

Re: Ember.js is driving me crazy

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

Re: Ember.js is driving me crazy

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

Re: Ember.js is driving me crazy

#16
post #4

I write a lot of ember. It can, occasionally, be frustrating (for example run loop craziness), but in my opinion it's no more frustrating than working with any other stateful front end framework (WPF, backbone etc...).

I've done quite a bit of Ember as well, and lately I'm kind of liking React's approach much better. It composes well with many routing/model solutions, and keeps the 'run loop' isolated in the view layer.

Re: Ember.js is driving me crazy

#17
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 can't even fathom this mindset. Deleting the code and relying on source control removes the issue from top of mind. Also, it will require more work to bring back later. Both of these are very good reasons to temporarily keep commented code around.

Re: Ember.js is driving me crazy

#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 interfaces easier to develop, lets you build your interface by composing parts together, lets you write view functions that are as smart as you are (no crippled templates like Ember/Ng). It is basically a simple low level building block that makes a lot of other stuff easier.

Anyway, as a non-genius developer who nonetheless has written a lot of javascript, React is my strong preference. Their approach is beautiful and simple.

Re: Ember.js is driving me crazy

#19
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 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?

Re: Ember.js is driving me crazy

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

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.

Post reply on HN