Ember follows in the Rails tradition of "convention over configuration". This means common activities can be done with a simple command, creating a file, or adding a flag in the right place.

This comes at a price: everything that happens in your Ember app is deeply tangled in Ember internals which are very complex.

This means adding behavior leads one of two places: It Just Works, or you have no idea what is happening or what to even ask.

When you are an Ember beginner this second state can last for days or weeks of frustration. As you learn about Ember internals, it happens less often and you move through it quicker, but expect this to take months or years.

The Ember team has taken steps to mitigate this difficulty: adding great error messages, and adding great documentation. But it a fundamental downside to the architecture they have chosen. And it's fundamentally at odds with what I would consider the Node Ethos, which is small packages that do one thing cleanly.

I would recommend Ember to professional developers who have the time to really learn about its internals and can afford to lose a week here and there to tricky debugging challenges.

I would not recommend it to developers working on small projects with tight deadlines.

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.

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.

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.

as a service!

I think, for me, I feel comfortable debugging as long as I understand the idea that is trying to be communicated. I think "weeks of frustration" is a bit of hyperbole but that's just my opinion. I can see days lost... but I think that's true of any technology stack that you're trying to acclimate to.

I also don't know about the last sentence about not recommending it to developers working on small projects. I don't have tight deadline but I find that it's working for my small project. As long as I'm not doing anything too far outside of CRUD operations translating into a view then I'm fine.

I don't think I would power a company with Ember. Though, granted, I don't have the experience to really make a call like that... but I would relay my personal experiences to a single developer looking for advice and suggest it for them if they're used to Rails or Django or some other massive convention over configuration back end framework.

I think you meant the reverse.

Most former Ember devs I know have moved onto React. When I mention Ember to them, I often get the response "you're STILL using ember?"

I could spend an hour explaining on all the issues with Ember's execution (it's been blogged about before, many times). I have no problems with "The Framework Approach", but when the happy path tends to always end up in the same bad destination, the community has to stop and think if they're on the right ship.

Source: I'm a full-time EmberJS dev for past 3yrs, dabbler for a couple years before that. If you'd like to discuss exactly what issues I run into daily with Ember, just contact me (my email is on my profile).

There is a good chance that I'll run into Ember's warts later on but just how easy it was to get started made me so happy. If I do come to the conclusion that it's something to hate, then I hope something comes along to replace it. I've heard great things about Vue.

I couldn't find anything well written and long about Ember from the ten minutes that I googled. Everything mostly seemed to be hot debates in comment sections. I think that as far as full time JavaScript developers, it's a good idea to aim for a React dominant ecosystem. But as a filthy and uncouth back end programmer, I really just want something easy to hook up. I'm not building something super complex and Ember, while it is probably terrible in sections, solves what I need it to do.

Paging data results to increase performance is what I'm working on right now. I want to feed it into a table.

Getting jQuery stuff like datatables working can be annoying and has led me to look at ember addons.

Basically, you're right on the money. I like Ember CLI because it's the closest thing to replicating the ease of Rails development in the Javascript world that I've seen thus far. I'm keeping a keen eye on Angular CLI, but it's not ready for primetime yet.

* Collect instance metadata from EC2 and store it in postgres.

* Collect Chef node data from a Chef API endpoint and store it in postgres.

* Return those collections to Ember to graph/put in a table/whatever.

I followed this guide for Rails 5 and Ember: https://emberigniter.com/modern-bridge-ember-and-rails-5-wit...

I had to pick and choose what it was showing since I wasn't building a book app.

It took some finagling to get everything working. One thing that confused me is that Ember resources get their own route and that wasn't explicitly stated (or maybe it was and I missed the text). So I kept trying to get `/instances` to render a table of instances but I would only get json back. I was super tired and up late at night but it didn't click that that route was bound to my resource and what was used to serve data. Whoopsy daisies.

In this context, I'm defining simplicity as low barrier to entry and/or easy to understand ideas. I think of myself as a fairly average developer; that I'm not wholly intelligent or skilled. I want a framework that bosses me around and tells me what to do.

Accomplishing simple tasks like mapping JSON returned from Rails to Ember routes and rendering that data into a table was very easy for me to understand and do. The simplicity I'm talking about was the setup, generation, and mechanics of the process. Ember, as another commenter pointed out, is not simple internally. It is glued together using evil magicks as far as I'm concerned. But I'm happy about that because when something does break, it means that I'm doing something that is going against convention or that something is truly broken.

As far as the former, then I need to learn the convention. For the latter, then I need to post questions in forums, hit up IRC, etc. But the positive aspect about the second process is that my project is already fully set up and I'm comfortable with my framework enough that I don't feel completely out of water.

However, I see this advice everywhere. When I'm googling "how do I do this in Ember" I usually get a good set of practices.

What's interesting, is there is another thread on HN about a WalmartLabs platform release that bundles React and a bunch of other boilerplate libraries a la Facebook's "create react app" and it looks really cool.

I love working with straight Javascript (ES5), jQuery and template engines like handlebars. I can design things in a way that works for the project and can quickly just refresh the browser to check my changes.

As far as conversion, I don't notice transcompilation times. I'm at Ember 2.8 and whatever other versions that were setup.

I don't really know where I have this preconception from, but probably it's not just me. http://discuss.emberjs.com/t/are-developers-creating-ember-a...

The only possible tie that Ember with Rails is that it used to bundle ActiveRecordAdapter with Ember data. It is now separated into another project possibly due to this exact reason.

[0]: http://sanestack.com

https://github.com/ember-data/active-model-adapter

It was on a whim that I chose Ember. I have heard of it before and how the project took stability a bit more seriously than other JavaScript frameworks so I went for it and was pretty pleased. It was super, super easy to integrate.

I think another similar pairing is Vue.js and Laravel and that actually makes me want to learn PHP.

I used to do a lot of Code for America work before I got distracted by my career and a desire to move out of my state. When I get back to it, I'll probably choose Rails and Ember just because of how happy I am.

Now, if I decided to stop doing operations/systems/devops work... I'd probably take React and other frameworks more seriously.

I think a lot of your ease of use comes from it being an internal IT tool. It's allowed to be clunky, you probably don't have many eyes from marketing/design/product on it-- and if they have seen it, they don't care too much.

Design & product want to be able to do some crazy stuff sometimes. And they're justified in that wish, our frameworks should work with anything that is possible in a browser. Your protests of: "oh well, that's not exactly how the Ember/Rails framework works.." will be met by glazed-over eyes. I really just agree with `erikpukinskis` here, but I think it's an important note that I think you'd have a really bad time if this app was consumer/client-facing.

> "that I think you'd have a really bad time if this app was consumer/client-facing"

Gee, thanks.

Now, ignoring the fact that you're immensely disrespectful, you're missing the point of what I'm trying to say. There is nothing wrong with having a small problem that is solved by a simple solution and I'm sharing how I'm solving my problem. I'm not going to choose an engineering solution that's more complex than what I need.

That being said... there are a decent amount of companies that have used Ember to build easy to use and fluid interfaces. I think the very first interface I saw built using Ember was the interface for the Riak data store - which is incredibly slick. Netflix uses it for internal services, Groupon uses it for its website, and so does LinkedIn and Heroku. Actually, technically speaking, Google uses it as well because of their acquisition of Nest - unless they rewrote the Nest store into Angular or something.

If I thought that rendering searchable tables and embedding graphs was more than Ember could handle and would result in a sluggish application then I wouldn't use it regardless of how easy it is to setup. If I thought that it wouldn't allow me to apply basic CSS and buttons and layout principles to my interface so that it's pleasant to use then I wouldn't have used Ember.

And if you think that you can deliver a better web dashboard than what's facing the users of Heroku then I suggest you knock on their door and tell them how to do so.

I was listening to Joe Rogan's interview of Adam Greenfield (a bowhunter) yesterday, and Adam said something like: "look, if you're looking to get into bowhunting but you don't have the cash to get the best equipment, that's fine. You can still have success with a cheaper bow and without the extra gadgets, but it'll take more time." I'm not saying that you can't build world-class products with Ember, I'm just saying that it probably takes more time if you're getting wrenches thrown at you from design & product.

I also really haven't spent enough time with Ember to really back up my last statement, I'm really just trying to give some perspective from a company-politics / organization-process POV?

Is that the sentence? I dunno. I looked at the stats for the first version of Angular and it had a low rate of "heard of it, not interested" and a high rate of "used it, will never use it again" with Ember being the reverse of that. I was just like "awh man, what a pity" because I have really been enjoying my short time with the framework.

"...to hack things together quickly..." That wasn't really what I was getting at. There is a lot of negative connotation around the word "hack." I want something that is easy to setup quickly as well as easy to reason about. With jQuery, I can just point to a CDN and get going. As far as the concept, I can easily understand that I'm just selecting and changing an element of the DOM.

Now, I recognize that jQuery gets super messy and has a lot of inherent limits but the spirit of the approach is something that I admire. Ember, like many front end frameworks, brings organization, conventions for testing, etc... but the concepts are a bit easier for me to grok than some of its competitors and there exists some tooling that removes a barrier to entry for me. That's just my anecdotal experience and others mileage may vary.

"For people that do frontend/JavaScript full time..." Yeah, I dunno. I'm just someone who does front end work for open source projects and when I think it has its role within my regular duties as someone who does more operations work. That being said, I think there are a lot of people out there like me. People who just want to show up at a hackathon and get moving quickly because they have that back end experience but are unsure of themselves when it comes to front end development.

"Does it have a better story for cache management or something?" I think this question shows a misunderstanding of what I'm trying to convey. I can't really offer a set of deep technical answers when contrasting the various JavaScript frameworks. Most of my use cases for front end development comes down to some pretty simple requirements. I just know that I ran a couple commands, changed a few configuration values, and then got going with what I wanted to do.

Ember had a low barrier to entry for me. There are a lot of community resources for how to integrate it with my back ends of choice, it has a rigorous set of conventions that are easy to cognitize, and the practices around Ember haven't changed for a long time.

Take a look at this Reddit /r/programming thread: https://www.reddit.com/r/programming/comments/55okik/how_it_...

The top two comments are about how difficult it is to determine what is an appropriate stack. A lot of programmers solve small problems that benefit from simple solutions. My anecdotal comment was that I found Ember to be a simple, stable, all-in-one solution that worked well with Ruby on Rails - which is the framework and language that best solved the problem that I was addressing.

For a React specific comment, I think Facebook recognizes this problem and it's why they rolled out their React starter CLI tool. WalmartLab's Electrode platform also looks like an admirable attempt to address the "I'm not that great at this so please configure this for me so I can just start learning and being productive" crowd.

I also really like it when a front end framework shows strong preference for and coupling with a back end framework. Vue, for example, has a strong linking to Laravel. The communities for each overlap and it's easy to get going with both. The Laravel generator, for example, sets up a Vue example so it's easier to get started even though Vue is a wholly separate project that can be used with any back end.

That's the comment that listed the article I followed. It's pretty tightly coupled to Rails and ActiveModel but it fit my use case pretty well. I found other resources as I googled around.

I used https://github.com/thoughtbot/ember-cli-rails to hook up Rails and Ember.

I found that I still had to tweak a couple of things like getting generated Rails controller to `render :json` by default but the article was fairly comprehensive.

Trouble is with angular 1 is a lot of people are probably still installing via bower, angular 2 might have a lot of people installing via jspm, elm uses scoped packages which still don't have stats...

I don't know how a sample of 9k maps to the developer community at large but I found it puzzling that so many people were dismissive of Ember. What makes Ember unappealing enough to not warrant being tried out in a side project? Personally, I saw it and thought "boy, a framework that wants to be stable for several years - sign me up."

Regarding react I don't think there is anything in react itself that says that you have to use es6 and an advanced module bundler (like webpack). Just use es5 code, place everything in one file or just concatenate the files before using them in the browser and everything should work. You mainly loses out on how easy it will be to copy from tutorials that are written for es6 code with modules, and that some 3rd party things are written as modules.

What probably killed it for me is when i tried using it a few years ago and i spent a whole weekend on it and ended up with something barely functional and generally being frustrated with a lack of documentation and helpful errors.

I was able to gain understanding by using ember inspector to inspect the store and using jq to inspect the json returned from my Rails endpoints.