Hacker News Reader

Comment by polysaturate | Hacker News Reader

Wow, really surprised to see Ember so low on the FE framework graph.

After using it for over a year (and switching out) I"m not. Its got a ton of good features. But most days I'd find myself pouring over the documentation trying to figure out how to do something I already knew how to do in Javascript. My colleague and I used to have a joke that went something like "Yeah I can do it in Javascript, but how do you do it in Ember-script?" There's a lot from Ember that I miss and a ton I think they got right. I do sometimes wonder if they'd adopted React for their view layer early on and sold themselves as the "everything else" framework if they'd done better. Idk how feasible that is, but my unqualified bias makes me think they'd be much more well known and popular.

Meteor did that (adopted React) and while it's not dead by any means it still hasn't reached the amount of popularity it was supposed to. Might be because of Mongo though.

I agree with that sentiment(especially the know it in JS, but WTF in Ember), and I am definitely not shilling Ember or anything, I just figured it was a little more popular in HN/YC.

> After using it for over a year (and switching out) I"m not. Its got a ton of good features. But most days I'd find myself pouring over the documentation trying to figure out how to do something I already knew how to do in Javascript

You probably don't have enough experience with Ember (if you are still pouring over docs) or aren't working on something of large enough scale to really benefit from Ember. (I'd say the analogy would be Rails vs. Sinatra, Ember really does a lot of stuff, but takes longer to get comfortable with).

> I do sometimes wonder if they'd adopted React for their view layer early on and sold themselves as the "everything else" framework if they'd done better.

Really? I think the React model of inlining HTML in your Javascript is atrocious compared to HTMLbars. An Ember code-base is just so much nicer to read.

Ember is sometimes painful in ways that jQuery wouldn't be (e.g. what I don't have access to the children components of my component!) On the other-hand if you have a large code-base with complicated computed logic, Ember really, really works by forcing you to do this the Ember way - where everything else would have dissolved into a complete mess. That said the upgrade path to 2.0 has been very painful. Never the less I would 100% choose Ember over React for a new project today.

> You probably don't have enough experience with Ember (if you are still pouring over docs) or aren't working on something of large enough scale to really benefit from Ember.

For context, the app was well over 10k loc, and was a socket connected video chat (+ contacts) application. I had enough experience with Ember to upgrade the app from 1.3 to 2.x stopping regularly along the way. I do expect knowing Ember more thoroughly would have helped but that was always my problem: I felt like I had to be intimate with every aspect of the docs to get the simplest things done. Towards then end I was spending a great deal of time which felt antithetical to the entire point of using Ember.

> Really? I think the React model of inlining HTML in your Javascript is atrocious

I suspect there will always be a segment that would prefer not to use JSX / inline templating, and that's totally ok.

> Ember is sometimes painful in ways that jQuery wouldn't be (e.g. what I don't have access to the children components of my component!)

This is exactly the type of thing using React for the view layer would address. I always found myself making extra components and 4-6 files then contriving ways to communicate between them. I'm quite sure there's a reasonable way to handle this in Ember, but when I do similar things in React, I don't have to look anything up. I just write javascript and things behave the way I think they should.

> This is exactly the type of thing using React for the view layer would address. I always found myself making extra components and 4-6 files then contriving ways to communicate between them. I'm quite sure there's a reasonable way to handle this in Ember, but when I do similar things in React, I don't have to look anything up. I just write javascript and things behave the way I think they should.

Ember is really not-friendly if you fight the 'ember way of doing things' (e.g. shared-state computes down, events bubble-up). There are a few edge-cases I've had where a parent really needed access to it's child and I am personally not a huge fan that Ember is so opinionated about not doing it, but I would say this is akin to the GoLang's kind of opinionated, it might hurt a few times but it generally standardizes the code-base which is very important when multiple people might be touching related code.

I'm not surprised, but I do think Ember is an excellent framework that probably doesn't get as much attention as it deserves.

Ember sadly never got its "big break", maybe because it doesn't have a big company backing it and promoting it. It's sad, but the framework and very awesome community have kept chugging along nicely for like five years now, so not to worried there.

Interestingly, this article[1] was posted months before the whole "JS fatigue" meme started (usually associated with React. I've found it quite true.

[1] http://brewhouse.io/blog/2015/05/13/emberjs-an-antidote-to-y...

there was a lot of money put into angular, and I suspect the same may be true of React.

I know a bunch of people that have tried or used ember in the past, but none that still do. I also get the feeling that if you're not using React you're leaving a bunch of money on the table. Branding yourself as a React developer === $$$.

Reply on news.ycombinator.com