Hacker News Reader

I think Ember is great, and agree more people should use it, but it is NOT simple. It is easy, but it is extremely complicated.

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.

>"everything that happens in your Ember app is deeply tangled in Ember internals which are very complex."

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.

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.

If I understand the saying correctly, this idea might be contained in the aphorism, "encapsulation breaks inheritance."

as a service!

Ah, maybe you're right. I think I'm used to convention over configuration setups so it feels a lot more comfortable to me. I think that maybe that's why its so popular with Rails developers because they're used to operating within the bounds of the prescribed architecture and then having to deal with edge cases.

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.

"Ah, maybe you're right. I think I'm used to configuration over convention "

I think you meant the reverse.

You are correct! Edited. Thank you for pointing that out.

I love the promise of Ember too. But if you look at the stats, along with Angular & Backbone it has pretty terrible satisfaction ratings. And in my personal experience, it also has some of the worst word of mouth of any JS frameworks. Which I believe is the reason why so many people haven't tried it yet.

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).

Awh, I'm pretty sad to hear that from an experienced Ember dev. I've heard some pretty bad things about Angular and I've seen some horrible Angular codebases. It's entirely possible that I'm looking at Ember through the eyes of a Rails developer who wants a better front end experience.

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.

Rails dev who likes Ember, here. Well, maybe "likes" is too strong a word. Prefers, maybe?

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.

To each their own. I tried learning Ember many times (due to my admiration/respect for Yehuda Katz), but it was always too confusing for me. Vue.js is what I use now, because it's the only front-end framework I was ever able to learn and use in real-world projects.

Yeah, this was just my personal story with it. I had a very specific goal for my first steps of development:

* 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.

Virtually every JS tool/lib/framework sells itself as "simplifying" something, and they usually do. It's the overhead of constantly simplifying that's murdering our productivity.

I think it depends on how you quantify "simple." If you refer to simplicity as a small framework or library with very little moving parts, e.g react or sinatra, then that's one way to arrive at a definition. However, complexity in a designed problem arises when you need to take a large variety of 'simple' components and mesh them together to solve a problem.

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.

If you are building simple app then it's really easy with Ember but you need to remember that Ember is very opinionated and if you need something that is not exactly standard or creators didn't predicted that someone would use something in certain way then you have problem and you spend time fighting with framework. I've been there, lot of time wasted fighting with Ember in corner cases but if you get this out of the equation Ember is really good and you can be really productive using it.

Yeah, I do like the convention over configuration approach. Sails is somewhat similar. Not fighting against "the Ember way" is valid advice.

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.

We have a pretty large Ember app that consumes a variety of data from many sources (clojure services and middleware). I find I rarely have to "fight" the framework, but often have provide overrides through the various lifecycle hooks. Usually these patterns are well established and documented, but it does mean learning a pretty large API.

I worked on an Ember project once, the first JS framework I ever used. It really frustrated me that I had it had to use Babel to convert the ES6 into ES5. For some reason, on my laptop, that took about 10 seconds, so every time I wanted to check if some new code worked as expected, there was this long delay. There were a lot of other issues I had with it too.

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.

There really is something to be said about simplicity. I love getting Flask/Sinatra/Spark/microframeworkhere and then just rendering a server side template that gets manipulated client side by jQuery. It's hard to move away from that sometimes.

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

That's strange. Both React and Ember projects compile ES6 -> ES5 in very little time on my machine.

The reason is probably that it's closely tied to Rails. I don't want to learn Rails, but I keep seeing Ember and Rails mentioned together. Probably the same community is behind them (too lazy to look up).

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...

Ember has zero ties to Rails. We are using Ember with Java backend. I have seen Ember used with .NET and Go backend. There are even the SANE stack [0].

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

I think that project is still under ember-data?

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

The two are different projects - it's just that they're a popular pairing. I could very well use Ember with Django or Dropwizard or whatever. I picked Rails because the project I'm working on is something that calculates the delta between a Chef implementation and what is in an EC2 environment. Ruby was a natural choice due to a strong library support for both the Chef API (thanks Seth Vargo and friends) and EC2.

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 just started an internal IT tool ...

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.

> "It's allowed to be clunky"

> "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.

Ahhh, sorry, I wasn't meaning to be disrespectful, I just felt like it was an important point to shed light on.

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?

Everything you say makes sense, except for your first sentence. For people that do frontend/JavaScript full time and work on complex long term projects, an easy to learn framework that allows you to hack things together quickly is pretty low on the priority list.

"It's really unfortunate that so many people aren't interested in learning Ember."

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.

Huh? Why should I use Ember instead of React or Polymer? Does it have a better story for cache management or something?

Why the dismissive "huh?" Was there anything I said that was incoherent or not easily understood?

"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.

What did you use to learn Ember? I'm also in the "convention over config" camp and I love that the Ember team sticks to it but also introduces new tech like FastBoot whenever they can.

https://news.ycombinator.com/item?id=12631268

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.

I suspect that we didn't get enough Ember responders, because I do think they have a reasonable sized community. 9k responses is likely not enough to draw a reasonable conclusion that it isn't popular. I wish we could have paired up npm downloads or some other stat besides some of this data...

Ember has a pretty large community—the framework has a few conferences every year that are filled up. Most Ember devs don't seem to participate in a lot of JS community things and are very quiet compared to say, the React community.

Here are some npm download comparisons : http://npmcharts.com/compare/backbone,react,angular,ember-cl...

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...

What kind of was a head scratcher for me was that Ember had such a high rate of "heard of it, not interested" from the responders. Especially when I looked a couple columns over at the Angular 1 data where a lot of people tried it but would never try it again.

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."

Been using ember productively for years; didn't even see the survey link

I think it's because Ember forces you to do everything The Ember Way. Sure they're technically writing JavaScript, but it only works in the context of Ember. Ember makes it extremely painful to use standard JavaScript libraries so it's not surprising that Ember developers don't respond along with the rest of the JavaScript community.

Have you tried riot? Or mithril? Small and simple.

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.

> It's really unfortunate that so many people aren't interested in learning Ember. I just started an internal IT tool in Rails and Ember and I'm really enjoying the simplicity of it.

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.

Hah, that'd do it. I did notice that it can be a pain to generate a data structure that feeds into ember data. If the structure doesn't match what ember expects, then you don't get an error that spits out the structure that was sent and the structure that is expected.

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.

We think Ember is great. If you want a framework (or any FOSS solution) for the long haul (years, not months) then back a horse that isn't ran by a company who is going to change their strategy every 6 months.