I hear very distinct echos of Rich Hickey's talk, Simple Made Easy.
In that talk, "easy" is defined as being nearby, familiar, or otherwise "at hand" to the person who is involved.
This is different than "simple", which is presented as an orthogonal concept meaning roughly "one operation" not tangled or interleaved with neighboring concepts.
This is a clear and useful way to think about simplicity in software (1). I think it's fair to say that the "do one thing well" aspect of the UNIX philosophy is a pretty good match to Hickeysian (?) simplicity. I haven't worked with Ember, but I think it's safe to say that Rails makes things "easy" that actually introduce significant interleaving to your app. The two examples I can think of are both about ActiveRecord: extending AR gives your classes an enormous protocol, and AR hooks deeply braid persistence to something whatever else it is that you're doing.
1) If you wanted to talk about simplicity as it relates to, say, product design you might be way off. When we talk about a product being simple, what we usually mean is that it integrates (folds together) many complex dimensions such as ergonomics, manufacturing, aesthetics, cultural signs, etc. into a single solution.
> When we talk about a product being simple, what we usually mean is that it integrates (folds together) many complex dimensions such as ergonomics, manufacturing, aesthetics, cultural signs, etc. into a single solution.
I would argue that in order for that to happen, the design and internals of the product need to follow principles of simplicity and separation of concerns. You can't just wrap a pretty layer around a snarl of insanity and get a usable product.
For example, a common design mistake is to use several visual indicators for one piece of information: this warning text is bold, a different color, and placed inside a box. Once you've done that, you have used up three visual "slots" that can't be used as effectively for other information.
Great design like you describe requires thinking about single uses for single mechanics. It requires thinking about how things fit together while remaining functionally distinct, rather than just adding more and more complexity to solve problems that come up.
and
>"it's fundamentally at odds with what I would consider the Node Ethos, which is small packages that do one thing cleanly."
You could substitute "Ember" with "Microsoft Windows" and "Node" with "UNIX" and be just as correct.
I wonder how frequently this design/philosophy decision comes up.