Would any one recommend Ember for a console only application? Maybe this sound like a very dump idea. But I would like to know if anybody already tried it?
1 Like
Hey, you’re probably gonna want to provide a bit more detail of what you mean by console only. Could you describe a bit more?
Yes of course 
I’m currently working on a node.js console app which does some heavy logic. Now I try to find a way to handle different views. For example one view displays errors for wrong arguments, another displays a kind of summary and another should display the progress while running the core logic.
For now I just use some methods which contain some console.log statements, but they are tightly coupled with the logic. My idea is to extract the control flow in controllers and console output into views. But I’m not sure if it’s a good idea to do that with Ember.
Does Ember need a DOM to work with? Also routing could be a problem as there are no URLs.
My hunch is that if you’re not using URLs to manage state and you’re not using the DOM, ember probably isn’t the right choice. Maybe there’s a node-specific framework that will do what you want?
Yeah, I’m with @kylecoberly on that one. It doesn’t sound like a good use case for Ember. Having said that, I’m sure there are ways of making things work, but it wouldn’t be easy to find examples and support I think.
Ok, thank you guys
It does have a lot of useful primitives though, you can use stuff like Ember.Object, computed properties, etc, when you download the ember-runtime. npm install -g ember-runtime You could extend them to form your own controllers or use ember ones if you want to do it that way.
e: I forgot to mention its outdated.
@marcel_me: I dare you to try it.
(and report back here with what you’ve built)
I don’t know about all of that. I think it would be counterproductive to try and get embers router/view setup adapted to control the display of your console app.
However I am quite fond of Ember’s object model, that is to say the Mixin system, computed properties, the cp macros etc…
It’s possible to get enough of ember running to take advantage of this relatively easily.
Get a non-minified build, and remove all the code once you start seeing the ember-views package.
I think it’s rare to straight up share code between client and server, but I do find it valuable to keep the same general style/ecosystem when developing on both sides. A nodejs backend with the above stripped down ember is a very comfortable context switch from working on EmberJS UI code.