Services: A Rumination on Introducing a New Role into the Ember Programming Model

I think the difference between this proposal and the Ember.Control/Ember.Component evolution is that “service” seems to me to be a general bucket for everything that doesn’t fit Ember’s currently defined roles. Without a philosophy about what a service’s role is, it is hard to say that labeling it will drive simplicity or better architectures, as opposed to just creating a name for a dumping ground.

Maybe if we can define what isn’t a service that is also not a controller, route, view, template or model, we can start to hone in on something with more utility.

Or is the idea that there is value in having an “everything else” bucket?

10 Likes