" 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…
Ember.js is driving me crazy
11–20 of 113 posts
Re: Ember.js is driving me crazy
#12Convention over configuration achieved with opaque magic can actually harm the dev process more than it helps.
Haskell: favor composition over configuration over convention.
Re: Ember.js is driving me crazy
#13Re: Ember.js is driving me crazy
#14" 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…
Re: Ember.js is driving me crazy
#15Those "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
#16I 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...).
Re: Ember.js is driving me crazy
#17" 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…
Re: Ember.js is driving me crazy
#18I 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
#19The 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…
Re: Ember.js is driving me crazy
#20" 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.
There's also the mental cost of navigating among all that commented code every single time you need to read that piece of source.