Hacker News new | past | comments | ask | show | jobs | submit login
"Getting started with Ember.Js is easy." - No it isn't (emberjs.com)
391 points by floydpink on March 20, 2013 | hide | past | favorite | 245 comments

Trek is making a huge mistake IMHO.

As a developer I can think of nothing more helpful than to get a "steam-of-consciousness" excerpt from our users. This is something no analytics package can tell you, if you want to make your "product" easy to use then this is the exact feedback you need. Delverworld was outlining the various pitfalls of getting started with ember.js and a core contributor shrugs it off because he didn't like the guys attitude?

No one likes having their shortcomings pointed out but it would have made much more sense for Trek to admit that getting started could be made easier and that the Ember.js team would look into ways to make it easier. Ignoring the issue like he is "above it" is pretty fucking pretentious if you ask me.

No one likes having their shortcomings pointed out but it would have made much more sense for Trek to admit that getting started could be made easier and that the Ember.js team would look into ways to make it easier

Agreed. I recently had a new user point out in quite spectacularly a direct fashion how unfriendly the "Getting Started" section of one of my apps is. It made painful reading, but I would happily pay for users to get in touch like that.

Same here, I used to be much more of a "hot-head" when it came to things like this (I'm still not perfect, far from it) but I try not to take things as personally, at the end of the day if it makes my product better then I should shut up and be happy.

It's not the first time. I've been in their IRC. They are friendly and helpful. Especially Yehuda, but there seems to be this idea that if you "don't" get it, you might just be stupid...


I got this tweet and I constantly look at it before deciding against giving Ember another try.

So far I'v done Backbone, Angular and Batman and I've had no problems with either of them!

I decided to go with Batman.js unless I need extreme performance, then I'd go with Angular.

Embers concept of iOS seems broken. I'm an iOS developer. They don't follow the same pattern. The best they could have done would be to use the same API structure. But no...

"@Seivanheidari @ahazem we'd love to know the root cause of your difficulty. Most people seem to be successful with guides + api docs now."

I came to a conclusion some years ago: if too many users are wrong, it's probably your fault. There's not some conspiracy by a bunch of unrelated users to all trip over the same things. It probably represents an actual problem. I learned this myself with a dumb little proxy instruction web page. http://rachelbythebay.com/w/2011/07/15/ui/

As someone developing a Javascript library, this a thousand times.

At some point I thought my library was easy to use and reasonably well documented for a very early stage library. Then I sat down at a little hack day with people trying to use it answering question over question about all those details that I had just assumed people would magically know, at the same time I though about for each of those questions there could have been hundreds of those that tried to use the library without me sitting next to them and gave up.

If I could get this type of feedback from every use, it would be amazing.

Writing this I remember at some point for an old startup I used http://feedbackarmy.com/ to have people run through the getting started tutorial for my app.

When I get to release and am happy with the state of the documentation I will likely try the same thing.

I'm studying interaction design in Sweden at the moment. This is exactly the point they're drilling into our arrogant heads: you're not a genius, listen to your users. And then you actually have to convince your clients that they are not geniuses, that being an expert can also make you blind to things, and that they need to listen to their users.


True story.

I've seen 2 extremes in my career:

1. The "product makers" think they know everything and force the users to do it the way they want.

This often results in a bad to use product.

2. The "product makers" think the user knows best and do everything the users say.

This often results in a too specific/unflexible product.

Oh, absolutely. It basiclly comes down to having a proper dialogue instead of one party dictating to the other what to do. It's just that in practice nr 1 seems more common.

I'd add to your point #2 - It can also result in a product that is way too broad and not particularly good at any one thing. i.e., the Homermobile.

Where in Sweden are you at?

You're absolutely right. I have seen this sort of attitude from quite a few domain experts - if you didn't get it, you aren't smart enough and "don't deserve to be in our group".

It's very sad because this is exactly the perfect feedback to know what the heck is wrong with your approach. We collect feedback for the tools that we put up on the web - these are usually non-technical people but people around me always dismisses it as "they aren't smart enough to get it" which annoys the hell out of me. Making things easy to understand and easy to use is what drives adoption rates. It's what made Apple the dominant. Sometimes handholding is necessary until knowledge has been successfully transferred over.

Yes, I agree. Just a couple of days ago I had a similar interaction with the mercurial folks, where I posted a (slightly overly annoyed) e-mail saying that their page about GUIs was awful.

In that case I got a nice reply, and they clearly took the suggestions on board and have massively improved the page. It gave me an excellent impression of the developers of mercurial.

Knowing Trek, I think his frustration here is in large part with himself. He cares very deeply about giving users a good experience with Ember and knows that we aren't achieving that as well as we'd like. We've been planning and working on an improved Getting Started story for a while now but, because all of us on the Core Team are very busy with our day jobs, it's been slower going that we would have liked.

To have more people point out your shortcomings when you're already well aware of them is very frustrating. I think this is what we're seeing in Trek's response. Now that doesn't mean that I think his response is helpful - it's not. But I do want it to be clear that we do care about these issues and sometimes maybe too much.

When our new Getting Started Guide is finally released, I promise that we will do our best to address all of the different comments and complaints we receive from our users.

-Peter Wagenet, Ember Core Team Member

If he cares that deeply, I'd suggest walk instead of talk and fix the problems now instead of hand waving. The Emberjs documentation problems have been there since the beginning.

Instead of commenting on #HN how awful ungrateful sarcastic users are, write a new "Getting started" page.

I don't think trek called anyone ungrateful. He's just tired. Also he already is working on a new getting started page. A few days ago he posted to the forum outlining his plan and asking for feedback. http://discuss.emberjs.com/t/todomvc-based-getting-started-g...

Peter, I get this, I get this 100x over. When I put my time/effort into something I try to do my very best. A user telling me it's wrong/broken/sucks makes me feel like my best isn't good enough. My point was that publicly a response like this hurts far more than the satisfaction you get from posting it. Trust me, I have been burned by this before and I had to learn from it. I have never used Ember.js but I plan to, I think it looks cool and have seen a few projects that use it to do really cool things. A response like this makes the community look un-inviting, the whole "Figure it out yourself"/"It's not worth my time to help you" attitude is not productive. I may realize that one developer does not speak for the entire project but not everyone will and there will be people turned off by such a response. I would hate to see Ember.js suffer because one developer found it against his "rules" to respond AND took the time to make sure everyone knew how he felt.

Why was the Getting Started Guide not at (or near) the top of your priority list for documentation?

Actually, let me clarify: why wasn't a Getting Started Guide/Quickguide/"Hello World" equivalent/etc one of the first written pieces of official Ember.js documentation?

It didn't come earlier because some of the core patterns were still solidifying. It would have been premature to put together something that was likely to change a lot. Now that we've hit RC the API is stable so it makes much more sense.

I have admitted that, publicly, very often, in other topics on discuss.emberjs.com, on websites, on twitter, on videos, and elsewhere. It's no secret I'd like to improve the documentation for Ember.js and I'm already well aware of the places that people are facing difficulty right now.

There's work, if people spent a moment reading the top topics in the forum, on a getting started guide with a direct call for feedback http://discuss.emberjs.com/t/todomvc-based-getting-started-g...

I've been extremely vocal in soliciting actionable feedback on that. I'd like to help!

Discourse isn't for making places like hackernews, where a playful, sometimes discouraging culture of dickitude is acceptable and encouraged. The goal of Discourse (a "Civilized Discourse Construction Kit") and our use of it is to create a place where civil discussion can take place to improve Ember.js as a framework.

Delvarworld's tone strayed into territory I don't think remains civil because of his use of sarcasm:

"are you serious?"

"oh god this is going to be fun, isn't it?"

"by the awful grace of god"

"3 more results linking to the first dead article! FANTASTIC!"

And so I signaled that I empathize with his frustrations (because I do) but I can't participate in that discussion because it violates community norms I'd like to uphold. If he'd like to rephrase his topic, I'd be glad to help.

Ego and pretension have nothing to do with it. Contributing to OSS is something I make a personal decision to do with my time. I wish I had an infinite amount of time, but I don't. Most people associate me with Ember.js, but I'm very active elsewhere. Did you know I regularly run through all the TodoMVC examples looking for bugs https://twitter.com/trek/status/313015370728501248 ? Most people don't, because it's just something I quietly do. Less quietly now, I suppose.

In addition to working on OSS, I'd love to maybe find a nice boy to date (https://github.com/trek/lonely_coder), see my friends, visit my aging, ailing parents more often, maybe catch a moving once in a while, or eat a meal I'd don't grab on the go running from one obligation to another.

Like most OSS contributors, this isn't my job. It doesn't pay my bills or put food in my belly. I do it because I'd like to improve the tools I work with and share those improvements with the larger tech community. In the finite time I can offer, I have to make decisions about where to expend energy. I choose to do that in places where I can have the most impact. I don't feel that I can be helpful when people approach with sarcasm. Rather than remaining silent, I let people know I'm happy to engage when we trend towards civility.

You got feedback from a frustrated user, and I'm sure you didn't just dismiss it internally, so why did you dismiss it externally?

Listen, I'd love to be able to write what I want, teach what I want, and do what I want without getting sarcastic reviews. But unfortunately people get frustrated and that's how they respond. "Oh, a tmux book? Who needs that?"

"You suck" is very, very different from "the thing you built sucks."

Customer service 101: Go punch a punching bag, have a cry, have a scream, have a drink, whatever. then reply with

"Thank you for your detailed feedback. It's most welcome. We've already started taking appropriate steps to build better guides and tutorials. We'll roll your feedback into those. We're always working on improving Ember's documentation and every bit of feedback helps."

And then go do those things you want to do for a while.

No disrespect, but this guy gave some pretty valuable feedback that I love to get when I'm working on a book. He told you exactly where the holes are, and those are so easy to miss when you're too close to the subject matter.

In any other venue, I would 100% agree and would not have responded this way. Delvarworld's tone is totally mild and in keeping with typical internet culture.

But Discourse's goal is to raise the bar. Significantly. They blog rather eloquently about it http://blog.discourse.org/2013/03/the-universal-rules-of-civ...

And new topic posters are asked to keep that high standard in mind when posting. I'm sure his sarcasm was meant lightly, but it still deviates from the high quality of discussion I'd like to have, and rather than simply ignore a discussion where I was specifically invited, I opted to publicly explain why I wouldn't be participating.

What I failed to do, and this shows my failing to keep that high bar, is explain what we could change to make the discussion civil.

I can't help but feel that you're doing an excellent job of proving that a single short, civil post can do more damage to the community than any amount of slight sarcasm. If "absolute civility at all costs" is the basis for Discourse, I'd much rather try to have high quality discussions elsewhere.

Edit: The link you provided has "responding to a post’s tone instead of its actual content" as part of a list of things to avoid.

That rule/principle seems a quick route to Wikipedia's meta-drama. Where things are not about what is true, but what is verifiable, and what is verifiable is about someone's arbitrary standards. Where an argument can be "rebutted" with "WP:NOT WP:SOMETHING WP:NORLY".

Demanding that other people (ahem) discourse with you in a way espoused by the philosophy of your forum software seems, at best, counterproductive, and at worst, openly hostile.

One wonders, would the result have been the same if such "sarcasm" had been used in praise of the library? Would it have been ignored due to "tone", and "not meeting Discourse's goal"?

Speaking of which, what? If I sign up for a support forum, I'm signing up for that. If FormumSoft 1.1's backend engine and developers are all about 'increasing awareness of mung beans', am I somehow at fault because OtherSoftwareDeveloperCo decides to use their engine, whilst I personally have disdain for mung beans?

Which is why I opted to say "I'm sorry, I cannot respond".

You chose to respond to the tone of the post while ignoring the content, while simultaneously claiming that you aren't actually responding. That's both annoyingly passive-aggressive and exactly the opposite of what the Discourse guidelines encourage.

Can't you see that that, in itself, is a response?

To not respond would be to not post at all.

Edit: After reading the FAQ you linked elsewhere, your response is explicitly tone-based and unhelpful. I believe that violates the polite discourse rule more than anything the original poster said.

As the saying goes: "You can't not communicate."

Not responding is also communication. So I responded.

Privately, to the poster, with a long explanation of the kind of conversation on this topic I'd love to share, and publicly explaining why I wasn't going to chime in after having been asked to.

Most people are assuming my only response to him is the one they can see. They're mistaken.

I'm one of those people that has found Ember intriguing and have also found the getting started/documentation lacking and can understand people's frustrations in the original thread and in this HN thread.

It's strange to me that you're trying so hard and making so many posts to basically fight and counter anyone and everyone in this thread (including the original forum post)..

Try being a little more positive and view the feedback not as an attack against you but as suggestions for improvement from people who are legitimately trying to help. Spend your energy saying less "no one understands me, he was rude to me in the forum post, you guys are all misunderstanding me, etc" and more "I/We will get this done".

Look at wycats' post about what documentation is available and how he is looking to improve it as opposed to your posts. His post is helpful and constructive and makes me want to one day give Ember another go (when documentation improves). Your posts are all "No no no. He doesn't speak like a perfect gentleman when addressing me and I wish to challenge him to a duel".

I'm sorry to be blunt, but You're Doing It Wrong. You are not the arbiter of how to have a good conversation, but the nominal go-to person for Ember.js documentation. From a cold reading (ie not being an Ember.js user and not knowing any of the participants in the discussion), my reading of Delvarworld's commentary is that s/he worked to soften the blow of his/her criticisms by couching them in gentle humor, and describing systematically the thought process and frustration encoutnered in trying to get to grips with this tool. A lot of people would have just said 'this sucks/is stupid' or something worse.

Slapping the poster down in public without any attempt at a substantive response, and then sending a long private explanation of how you should be communicated is a major dick move.* You are arbitrarily setting yourself up as a superior being and deflecting wholly valid criticism by making such public pronouncements. Following up with a private message is not much better, because it prevents the recipient from having the issue out with you without breaking the implicit confidentiality of email.

* Since you referred upthread to 'dickitide' I am presuming the term 'dick move' is not going to be offensive to you.

Your role as a community member is not to lecture other people in how they may address you (within reason, there's no reason you should have to tolerate outright abuse), but to exemplify the standards you wish to propagate. If you use community standards as a shield to deflect substantive criticisms of your work, voluntary or not, then you are undermining those very standards by using them for exclusionary purposes. The fact that you are in a distinct minority in this discussion and are defending your position by arguing that dickitude is the norm and you are the exception ought to serve as a red flag for you.

My advice is to apologize to the original poster (ie Delvarworld) for your dismissive reaction and then engage with that poster's substantive criticisms. If you truly feel unable to engage with someone who is engaged in the mildest kind of personal expression, then perhaps being in a liaison position is not for you.

In the meantime, I urge you to revisit the Discourse blog article you linked to (where you cited the 'don't be a dick' principle) and keep reading to (at least) the section titled 'Be reasonable, even when you disagree,' which includes a plea to avoid 'responding to a post’s tone instead of its actual content.'

And yet of course you could have responded. You could in fact have simultaneously pointed out that you find the tone of the original post unfortunate and then also addressed the substantive issues raised therein. "I can't respond" is ludicrous bad faith. Nothing is stopping you.

So what you're basically attempting is the Discourse equivalent of a StackOverflow "This question is offtopic" thread-close. Good job.

What you're attempting is amateur anger management. It doesn't work like that. Your approach is almost classically designed to escalate tensions, not defuse them.

It's probably relevant to note that we haven't heard from delvarworld, who I reached out to personally explaining in greater detail why I was opting not to reply and what we could do to create a discussion we'd both want to participate in.

You're only seeing the brief, public acknowledgement that I wouldn't participate despite being called out with an @ reply.

The tension only escalated when people from HN decided to chime in.

It's entirely possible that you haven't heard from delvarworld because that person felt hurt and humiliated by your public response, which may also have colored the impression made by your follow-up private communication.

It's also disingenuous to say you were called out; a third party (locks) mentioned that you were the appropriate point of contact for suggestions like this. In no way could this be construed as a challenge or mockery of you personally.

I don't wish to belabor the point so I will not comment further about it. I just urge you to take a step back and try to consider the whole conversation from the perspective of a neutral third party.

"I'm sure his sarcasm was meant lightly, but it still deviates from the high quality of discussion I'd like to have"

Sarcasm and quality of discussion are orthogonal. It's very easy to have 100% "civil" discourse that is of absolutely no quality, and the only difficulty in having high-quality sarcastic discourse is the difficulty inherent in having high-quality discourse sans phrase.

Civility is a purely formal virtue (the virtue, in fact, of specious op-ed pages, where the only discursive sin is an uncivil tone), and it's far too common (one sees this in political discourse especially) for "lack of civility" or "uncivil tone" to be used to exclude people who are, often justifiably, frustrated or passionate about the topic at hand. It is of course possible for someone to be so relentlessly rude that there's no point in further (nb further!) engagement with them, but that clearly isn't the case here. It looks, to be honest, as if you're indulging in the first plausible excuse to avoid engaging with the problem the poster raised---and, what's worse, pretending, as you do so, that your hands are tied.

There is really no reason why all complaints or issues raised should be couched in a hands-off, disinterested tone. (Or rather, the only reason that all complaints or issues should be so couched is that normatively bad but instrumentally unfortunately good reason that otherwise people will take your tone as an excuse not to engage.) You're doing yourself no favors by getting on this particular high horse.

> But Discourse's goal is to raise the bar. Significantly.

Well then it's probably not the right place for ember, because programmers don't behave that way, and your response has been to lock down all forms of criticism, even things you find to be in keeping with internet and programmer culture.

That's criticism you need - criticism you say is in keeping with the culture, and that you say you've been actively soliciting.


> "[the sarcasm] still deviates from the high quality of discussion I'd like to have"

I think what you might be missing is that nobody else is reading it that way except you. Most of us are trying to tell you "guy, you're being way over-sensitive, and you aren't rising on your own to the standards you set for others."


> "I opted to publicly explain why I wouldn't be participating."

And the response you got was "you're lowering the bar; stop it."

And you have dug your heels in to insist you're doing the right thing.

We disagree.


> "What I failed to do, and this shows my failing to keep that high bar, is explain what we could change to make the discussion civil."

What you could have done is responded to the actual legitimate criticism, which you pay lip service to being appropriate in typical internet culture.

Dancing around it then shutting the topic off is not a form of keeping a high bar, sir. It is my opinion that this phrasing is self congratulatory, so that you don't have to face the nature of what you're actually doing.

Have you considered that your behavior here is doing serious damage to the reputation of the ember community?

It doesn't really matter if you agree with yourself; the rest of us don't. Repeating yourself, "clarifying" yourself; these things don't matter.

In reality, someone joked around, told you what they needed; you paniced, and yelled at them for giving you what you pretend you want. Then you told everyone "oh this is totally appropriate, but Discourse wants something else."

Except Discourse didn't do this. You did.

Please understand, sir, that to the rest of us, you just appear to be back-pedalling and blame shifting.

To the rest of us, it looks like you barked at someone because you didn't want to know that your role as documentation maintainer had not been well fulfilled.

And "explaining" won't change that that's how this is being interpreted, because if that's what really was going on, someone would respond by "explaining."

Civil discussion doesn't mean discussion you like, and it doesn't actually exclude sarcasm, either. What civil discussion is is factually based discussion which does not make personal attacks.

He didn't make personal attacks. You did, extensively, in three places that I'm aware of.

If you find him to be uncivil, get a mirror.

Thank you for that Tmux book. I found it very helpful.

You're most welcome. I'm glad it helped.

Thank you for your Web Design book. As a programmer, it gave me the confidence to explore the design world.

That's really, really cool to hear. Thank you so much.

Thanks for the Tmux book from here too.

Thank you as well.

So, here's the challenge: if you're going to develop systems software (which is to say, software that is consumed by a fellow software engineer), you're going to find that you're much more likely to hear about how the software doesn't work than how it does. This is frustrating because you -- like every other human -- react much better to praise than to scorn. But here's the leap you need to make: when you have someone taking the time to criticize you in depth, it's because THEY WANT YOU TO SUCCEED. (If they didn't want you to succeed, they wouldn't bother reporting their experiences to you, because they wouldn't actually want you to fix them!)

So as hard as they can be to read sometimes, experiences like the one you replied to are actually essential to you and your project: it is someone who wants you to succeed explaining in detail how you fall short. The proper reply is to thank them for the time they took, apologize for any inconvenience -- and then try to figure out forward progress on the problem that they've identified (which in this case seems as simple as pointing Delvarworld to the nascent "Getting Started" guide). No, this isn't always easy (and you can take solace in the fact that it's hard for the rest of us too) -- but it's essential if you want to develop systems software.

I object to one thing you said. Criticism is often NOT because the critic wants you to succeed. If more than a few people know about your tool, some of them will hate your project and want it to be rejected and die. And they won't necessarily play fair. There are so many ways and so many reasons why an open source tool will be attacked, many of which are not constructive at all, not even honest, just intended to make your project look terrible in public so that they can "win" somehow. This is a social reality of writing tools for other people to use for free.

When I fail to learn a new technology, I prefer to say the technology sucks than to say I'm too stupid to learn it. In this case, I do not really want them to success...

Sorry, but that's just ridiculous. You get some very detailed actionable feedback and flat out refuse to engage with it because it contains some mild sarcasm?

No, obviously you would not like to help unless it's 100% on your terms, and you're not even telling which terms they are. Which is not very helpful at all and, in fact, showing a considerable degree of dickitude.

I'm on your side here but I still have to defend trek on this one. This sort of feedback is not all that uncommon and at this point the Ember team has to be deaf, dumb, and blind not to know about it. Trek even says he knows about this and that they're working on it. And he's right that HN can sometimes be a place where people come to talk down to other people and rant like entitled assholes about asinine topics and the community can sometimes get so wrapped up in it that we almost truly believe we're the center of the universe (myself included). So I can understand his "dickitude" remark.

I think what this really comes down to is a few very simple reasons he doesn't need to respond to this:

- He and the Ember team have heard it before and many times said they're working on this (I know I've seen that stated publicly many times)

- There are only so many people you can respond to. Again, the team knows, they're on it, no response required

- A front page HN post does not automatically mean the project maintainers need to respond.

- This is OSS. Like Trek says, there's only so much time he can devote to this stuff especially for free.

I think we need to give him a break here.

The problem is that he did respond, to tell the user that they were too uncivil to deserve a more helpful response. Not responding at all would've been completely understandable, for all the reasons you gave.

> This sort of feedback is not all that uncommon and at this point the Ember team has to be deaf, dumb, and blind not to know about it.

The kind of feedback that has a point?

I have been following the ember.js community for awhile and also trek.

It's this attitude that makes me never want to use ember.js. If you check out his twitter account, you can see countless battles with new people just getting into ember.

If you want someone to use your framework, it shouldn't be a verbal battle of passive aggressiveness and other childish antics.

He is doing a disservice to the community and the framework.

"It's this attitude that makes me never want to use ember.js." Agreed. In fact, I suspect I'll never end up using it, now.

I'm sympathetic. There is nothing you can do in open source which will not result in a political response.

Before, I had no interest in ember.js. Today I am willing to give it the benefit of the doubt. Because so many people are trying to bury it, for some reason which has nothing to do with technical concerns.

I couldn't agree more. Thanks but no thanks. I hope that was a civil response.

While I totally agree that developers actions can be a turn off for using a library/framework/whatever, it also reminds me of political scandals. Just because person A cheated on his wife (or something similar) doesn't mean that his policies were not good.

The problem is that the community is a big part of a framework/language/library these days. If I have an issue and I need some help, I will first go to the community if I can't figure it out myself.

If I feel like it's just going to be met with someone personally attacking me because I don't agree with their practices, I will just find another community (and framework/library).

It's funny because I've seen some of the same sort of issues with the Ruby community...and Trek is part of that community too.

I don't see nearly as much of this in other communities and I often wonder if it's because of the leadership/certain type of culture that the community is built upon.

I see what you're saying, and it is a fair attitude. The problem is that I think others disagree on your definition of civility; for example I am of the opinion that the post was perfectly civil, and I think others would tend to agree.

You are of course free to set your own standards in your own community, however I think it would serve you well to recognize that the implied standards you are setting are extremely, extremely high. In my opinion they are so high that they are counter productive, and I posit that the fact that this article is now at the top of hacker news suggests that many people agree with me on this point.

I think it just shows that HN likes controversy. Which is news to no one :)

Nailed it.

That's your opinion and you're entitled to it. My opinion is that your deference to such a strict definition of civility is really a hindrance to civil discourse. There is nothing really insulting in his comments. It is obvious that the guy was frustrated when he wrote it. It is also obvious that there are many helpful comments or advice that could be given to help alleviate the source of the user's frustration. Your isn't helpful, and it wouldn't do anything to defuse a real civility crisis any more than it has this imagined one. It reminds me of the prototypical aggravating DMV person sending a client to the back of a long line ostensibly because of some triviality such as an easily corrected typo on a form but really because they enjoy using their ability to annoy people.

> create a place where civil discussion can take place to improve Ember.js as a framework. ... Delvarworld's tone strayed into territory I don't think remains civil because of his use of sarcasm: "are you serious?"; "oh god this is going to be fun, isn't it?"; "3 more results linking to the first dead article! FANTASTIC!" ... I don't feel that I can be helpful when people approach with sarcasm. Rather than remaining silent, I let people know I'm happy to engage when we trend towards civility.

@trek, let's check your comment about backbone.js in your excellent "Advice on & Instruction in the Use Of Ember.js"[1]:

“Ever run into zombie events in a Backbone application? No? You've either not used it for anything big, have Rain Man-like ability to craft software, or are fucking shitting me.” -- trek

Your "fucking shitting me" seems somewhat less civil than Delvarworld's "are you serious?" and "FANTASTIC!", but maybe that's just me.

Or maybe it's okay to use that language because it's about Backbone and not about Ember?

PS. I've been actively trying to influence a group to adopt ember.js. Your responses here aren't helping, though your sarcastic and expletive laden advice article was.

1. https://github.com/trek/trek.github.com/blob/4bc36e47a9017be...

People can, and do, write in that tone on their personal blogs all the time. I have no issue with it and often in engage in hyperbole for effect in that arena.

The context you're probably missing is that my comment about the expected level of discussion isn't abrupt or coming from nowhere. In this particular venue you are specifically asked to keep the level of discourse higher than is typical on the web at large.

You're asked to do this when you first join and reminded with a summary before you are allowed to create your first two topics: http://discuss.emberjs.com/faq

I reminded the poster that his tone put him below the level of discussion the community has agreed to engage in within this particular space.

Posters can, and do, ignore this all the time and I often go around trying to prod people back towards civility and correct places for types of discussions:

http://discuss.emberjs.com/t/todomvc-based-getting-started-g... http://discuss.emberjs.com/t/ember-computed-halp/388/5 http://discuss.emberjs.com/t/ember-vs-angular/374/5 http://discuss.emberjs.com/t/best-way-to-handle-mongo-couch-...

> The context you're probably missing

I don't believe I'm missing context. You keep explaining what you did, why you did it, where you did it, but I believe readers here see all that. Many still think you were mistaken. We don't see this as prodding anyone towards civility, we see changing the subject from legitimate issues to an individual's tone.

> I reminded the poster that his tone put him below the level of discussion

So you are above him and he is below you. You are his patron, reminding him of his place. This is not civility. This is the literal definition of condescension.

Civility doesn't mean avoiding hyperbole or other effective rhetoric. Civility means keeping a debate about the subject rather than the individuals discussing. You failed to do that.

From "Civility in Public Discourse"[1]:

Clearly, civility has to mean something more that mere politeness. The movement will have accomplished little if all it does is get people to say, "excuse me please", while they (figuratively) stab you in the back. Civility also cannot mean "roll over and play dead." People need to be able to raise tough questions and present their cases when they feel their vital interests are being threatened. A civil society cannot avoid tough but important issues, simply because they are unpleasant to address.

You avoided the tough questions, and changed the subject from the identified issues.

Constructive debate needs to focus on solutions which are most likely to be successful, and not upon personal attacks leveled by adversaries against one another.

He used hyperbole for effect, about the process of using the tool, not about the interlocutor. That didn't undermine civility by this canonical definition. You attacked his tone, personalizing the discussion. That did undermine civility.

Constructive civil debate, therefore, requires that the parties work together to resolve factual disagreements wherever possible.

He spent time walking through a process, factually. You ignored the facts, and replied about civility instead. That was not working together.

The most destructive confrontation process, escalation, arises when accidental or intentional provocations beget greater counter-provocations in an intensifying cycle that transforms a substantive debate characterized by honest problem solving into one in which mutual hatred becomes the primary motive. De-escalation and escalation avoidance strategies are needed to limit this problem.

His post was effective at highlighting the real user story about trying to get started with the platform.

And though you yourself use sarcasm about other products like backbone.js in a piece presented as a canonical getting started reference, your dismissive line escalated the situation into a Streisand effect turning off countless potential users of the framework.

You could have at least not replied at all, as a more civil response than what you wrote.

One crucial element of civility is recognition by conflicting parties that it is possible that they are wrong and that the policies advocated by their opponents are actually better. This entails an obligation to seriously consider the persuasive arguments made by opponents.

You did not seriously consider the persuasive arguments made by the OP, you attacked his tone instead.

Here on HN, you've demonstrated unwillingness to acknowledge, even by a single phrase, that you might have been wrong and policies around civil discourse suggested by others here might have been preferable in this instance. Elsewhere you've jumped on people trying to get into the framework, so this personalizing criticism of the framework isn't new.

Thankfully, a careful reading of this HN thread suggests contributors to ember.js disagree with you, and have suggested your response was a tired mistake. So perhaps readers here can still agree not just with the philosophy of ember.js itself, but with the philosophy of its contributors. That's important, and missing that point can cost a project dearly.


By most of your replies here, it seems you've confused pleasantries with the real meaning of "civil discourse" which can be quite spirited or contentious but remains focused on framing the identified issues in ways which transform win-lose confrontations into win-win opportunities.

1. http://www.colorado.edu/conflict/civility.htm

I truly believe that you had good intentions posting that, but what you said makes it look like you're prioritizing being the civility police higher than helping a frustrated user.

Being in the same boat (re: OSS contributor, not my day job), I can totally empathize with your initial reaction to his post, but honestly nothing you quoted is incivility. It's genuine frustration from a new user caused by your documentation with complete steps on how to reproduce the problem. If you printed the average open source user's feedback out on gold foil using platinum ink, this guy's feedback would still be more valuable.

Just wanted to say that i love your stuff! You've saved my life multiple times

Thank you!

> And so I signaled that I empathize with his frustrations (because I do) but I can't participate in that discussion because it violates community norms I'd like to uphold.

I wanted to post this to your original comment there, but couldn't be bothered to make an account: "Get over yourself".

The guy was just (quite rightfully) venting about his frustration trying to get Ember to work, and the venting itself was still relatively tame. Besides, it wasn't a personal attack against you.

Pretending you're somehow above the discussion because of "the tone" is just lame, especially when there was nothing wrong with it. So much discussion is suppressed all over the world because people insist on latching on to how something was said, instead of whether there was any merit to it.

Where I think you went wrong is the homepage. When you see it, you get that warm, fuzzy feeling that you're about to use one of those projects that "just works", the kind that delights you with how easy it is to get up and running and makes you wonder why all software doesn't work that way.

There's a promise that getting started is "easy", and a short code snippet that gives a false sense of confidence. It just shouldn't be there if it isn't true.

No response would have been better, at least until you are in a lighter mood. That's a rule I try to follow.

I agree.

This is obviously oversimplifying, but there are two common approaches to how to respond.

The first is "You're my customer" (figuratively speaking), which means you try to be helpful in spite of the tone of the person asking for help. Sometimes empathy goes a long way -- instead of thinking "This guy's being a such dick", ask yourself "Why is this guy being such a dick?". On the other hand, if the tone is a little too belligerent, it's also important to note that some "customers" aren't worth having, and you get rid of them.

The second is "I'm doing you a favour, you should appreciate it". Usually taking this perspective starts with "if you don't like it, go elsewhere" and it rarely ends well.

I typically try to treat everyone in my dealings (employers, employees I manage, and my peers, etc.) like customers unless they force me to not to, but they always get the benefit of the doubt the first few times around.

What I typically find with people who are extremely frustrated who are looking for help is that they become extremely thankful and contrite once you've helped them, especially if you showed them a little empathy in helping them.

The thing is ... if it had been sarcasm in the name of snark, I think I'd agree. But it really didn't sound like that, it sounded like sarcasm as a means to distract your attention from the quiet, soft sound of heartbreak that heralds the shattering of a dream.

That's what, I think, led to such negative responses. You read snark; we read a cry for help from the darkness and imagined a child who'd trusted your site on the verge of tears over a broken promise.

Anguish, anger and assholery can all sound very similar, and I'm sympathetic to your definition of that level of sarcasm as uncivil, but I suspect that the perception gap here is why most of this conversation seems to involve people talking past each other.

Or maybe I'm misinterpreting it completely; conversation's fun like that ...

"sometimes discouraging culture of dickitude is acceptable and encouraged"

Being honest, I believe that you're being a lot more severe than the person to whom you're responding. He made no personal accusations, he didn't talk about people's nature, whose job what is, the demeanor of other communities, et cetera.

It was not, in short, a complaining post.

What he did was document the steps he went through, why he thought the way the library was presented wasn't accurate, and said "may I please have XYZ." He didn't talk about ego or pretense, he didn't talk about his dating situation, he didn't talk about his food schedule.

He said "could I get a quick start guide please?"

Look how you've responded.

With respect, sir, he isn't the problem here.

That's actually a very decent answer. You should've expanded your reasoning a bit on the ember thread. Although to be honest, I thought the tone was more funny than sarcastic, but I'm emotionnally detached from the subject. With your explanations, your reaction makes sense. Sarcasm is a slippery slope.

I am envious that you are able to remain emotionally detached from this subject.

I have experienced this kind of thing many times over the course of my life. There's no way I could remain emotionally detached.

You're reply and hand waving here is worse then your comment there.


I do understand what you are saying and I don't want for a minute to imply that you are required to help, I understand that you are a volunteer. That said my point is that while you might not have liked the way he phrased his post, writing him off because of it is not what I would have done. I will be the first to admit that I can be a VERY sarcastic person if I put my mind to it and so maybe my opinion is biased to agree with the style and even enjoy reading things written in this style. Reading Delvarworld's post brought back many memories on trying new software/code (not ember specifically) and the irritation felt when something has such a high learning curve. However, I believe that it makes more sense to simply agree that the documentation could be better and possibly even invite Delvarworld to jump on IRC or discuss on the forums ways he thought the docs could be improved instead of ignoring him.

In my mind I saw it as someone explaining the steps they took to try something and outlining the various ways they failed in that endeavor and then you, a core contributor, coming down to essentially tell him to fuck off, it wasn't worth your time. I know that's not what you wrote and I don't think that's how you felt but it is what I got out of it. I think bphogan makes a great point with "I'm sure you didn't just dismiss it internally, so why did you dismiss it externally?". I don't know you, I have actually never heard of you , this was the first thing (to my knowledge) that I have ever read of yours and what I took away from it was that you simply didn't care. Like I said I don't think you don't care, it's just how it came across, at least to me.

"discouraging culture of dickitude", nailed it.

We have to moderate the kinds of communities we want to see and participate in. You don't have to put up with people's shit.

We might choose to, but we don't "have to". It's about tradeoffs. A polite question might have been politely answered in the thread. A sarcastic rant like this results in a 110-response story at the top of HN with multiple apologetic posts from the developers.

I think I know which strategy is more likely to result in better documentation.

Your reply on the ember forum seemed packed with frustration, hence the response so far I guess.

Wouldn't it be better to include a brief note on the homepage to highlight that docs are WIP and point to other getting started resources? Just to avoid further frustrated newcomers?

Anyway, your reply here paints a more complete picture and just wanted to say thanks for your contribution to OSS.

Looking forward to the updated emberjs docs.

> I don't feel that I can be helpful when people approach with sarcasm

In general, I agree with this sentiment. But this post, which appeared (to me, at least) to contain extremely mild, non-personal-attack sarcasm, used to highlight areas of particular frustration, seems to be a shining example of how being 95% civil can result in much more effective communication than 100% civility.

If I were moderating that forum and wanted it to be a happy friendly constructive place, I'd let his post slide as a one-off, but give you a warning for being a condescending dick, since I find that kind of attitude in a community far more off-putting >_>

> Delvarworld's tone strayed into territory I don't think remains civil

> violates community norms I'd like to uphold

> I don't feel that I can be helpful when people approach with sarcasm

> places like hackernews, where a playful, sometimes discouraging culture of dickitude is acceptable and encouraged

You definitely have the most ridiculously uptight worldview of anyone I've ever met. If you're expecting any more than a tiny fraction of the people who adopt Discourse to come anywhere near your norms of "civilized discourse," then you must not be very familiar with the interwebs.

I don't think many would disagree with this principle, but I don't think his response qualifies as out-of-limit discourse.

I just read it as honest and accurate. He's not being a dick just for the sake of it. His thoughts sound exactly like what I would be thinking in his shoes. Knowing an actual user's moment-by-moment thoughts as he uses your product is invaluable. You shouldn't be encouraging him to bowdlerize that because it puts you off.

I'm in the minority here, but I 100% agree with you. I could see myself posting the exact same response.

Just don't let it get to you. You seem like a proud person, which can be a great thing in itself, but this is not an attack on you personally. You've done great things. Acknowledge him and quietly move on.

Ultimately, the Discourse OP just wants a better guide. Would someone with a Discourse account be willing to rephrase the OP's issue with less sarcasm?

Did you read the whole forum thread? We are planning to address his complaints.

Sometimes I miss the good old days of RTFM.

Although he's already replied to you, I wanted to point out that a refusal to respond to a post in no way indicates whether or not the communication has been received. In other words, he's not ignoring the feedback, he's just refusing to engage in discourse which he sees as already unproductive.

Quite the opposite, he sympathizes with the OP to begin with, and so he most likely read it. He just doesn't want to engage in what could easily turn into a flamefest.

With all due respect I don't think that this is what happened here. That's fine if he felt no need to help, to problem is when you go out of your way to let someone, someone who is trying to learn, that you think they aren't worth your time due to the tone of their post. I understand where the OP is coming from, the frustration at trying to learn something and constantly hitting roadblocks. Was he a little sarcastic? Yes, however I would be too if I couldn't find any help. This situation was escalated by the fact that his cry for help was met with a core contributor taking the time to tell him he wasn't going to help. I would compare that to going up to a homeless man and telling him you weren't going to give him any money. There just wasn't a good reason to post something like that.

Good points, and you're probably correct.

However, to your last point, I can see how it'd be challenging to convey your stance that you won't allow uncivil discourse other than how he did so. If you go ahead and respond normally, you're just reinforcing the bad behavior, ergo it makes the "discourse must be civil" an empty promise/threat. Perhaps he could have replied, with a caveat that further uncivil posts would be ignored, but I can also see getting tired of that sort of behavior (and as a former forum mod, continually having to 'remind' people of the rules that they've already agreed to wears out really quickly).

I totally agree that our getting started story could be much better. In fact, it's our primary focus as we move towards 1.0.


* We're actively working on a Getting Started Guide with live examples that walks the user through building a new application from scratch.

* We're continuing to improve our guides to talk through areas that might be confusing for new developers, like the naming conventions[1] we use in Ember

* Ember 1.0 will feature the return of the Starter Kit[2], which directly addresses the concerns by the OP. We removed it temporarily to bring it up to date with the most recent idioms, but it will be coming back very soon[2]. This was a hard decision that sucked, but leaving around an out of date starter kit seemed worse than removing it.

I take this concern very seriously, and hope that people will continue to give us a look as we improve the experience for new users.

[1] http://emberjs.com/guides/concepts/naming-conventions/ [2] https://github.com/emberjs/starter-kit

One thing I'm a big fan of is when projects have an always updated always working "Hello World" sample included with their project. This is something I've found to be common with iOS libraries and I think it would be helpful for you guys.

It's nice to be able to take a look at something that works and is simple enough to read through in one glance and go "Ah hah!"

If only Apple did the same for OSX, its getting better, but theres still tons of examples that dont compile w/o several warnings, and usually haven't been converted to ARC.

This is the response that should have been made on OP's original thread in the first place (and I do see you've xposted it there now).

Totally agree. The OP posted at 4:05 a.m., when I was very much asleep. I've been a little bit less responsive this week in general as I've been participating in TAG[1] this week. I'm very sorry that our project came across as uncaring.

[1] http://www.w3.org/2001/tag/

Should anyone doubt it, wycats & the ember team certainly do care a great deal about their users. The Ember team and Backbone team have differing philosophies about client side development, but wycats, tomdale and the rest of the crew are smart guys trying to do the right thing.

At this point I'm familiar with Ember, but not Backbone. How do their philosophies differ?

If you guys are interested in putting together some usable examples (in the spirit of docs.angularjs.org), I would love to help you integrate live examples with Plunker (http://plnkr.co/edit/).

Bootstrapping an editor session is as simple as POST'ing a simple form targeted at that url.

I would really love to see the Ember.js community get some use out of Plunker. (@filearts on twitter if you'd like to chat).

Does Plunker have an about page? I've been looking for a description of what it does and what it's for but can't seem to find anything.

That sounds like a very good (if not necessary) idea.

You can see a list of features on the development version of the site at: http://beta.plnkr.co/ These include:

* Real-time code collaboration

* Fully-featured, customizable syntax editor

* Live previewing of code changes

* As-you-type code linting

* Transparent translation of intermediate languages like Coffee-Script, Typescript, Sass, etc (with sourcemapping included where available). This means you create 'app.coffee' and ask for 'app.js' in your html and you are served the compiled version of 'app.coffee' as well as its sourcemap.

* Forking, commenting (not done yet) and sharing of Plunks

* Fully open-source on Github under the MIT license

Also, there is both a Google Group (http://plnkr.co/discuss) and github repo (https://github.com/filearts/plunker).

That being said, neither of these properly address your question. I will push out an about page as soon as I can.

It would be really great if there was a well documented example application similar to Discourse's topic list, that had a: a search term populate (populate not filter) the topic list and the ability sort the topics by clicking on the column headers.

I would build it myself, but I personally haven't been able to become proficient enough with Ember (in the admittedly limited amount of time I have tried mastering it) to do so.

I'm very excited to see this naming conventions guide come out. I think you've done a great job here of clearing up in one place a lot of the magic that Ember does for you. Understanding how Ember looks things up is critical to developing nontrivial applications, so thanks!

Another thing that would really help Ember's popularity are screencasts, something like egghead.io, where you'd show off some more advanced stuff. I know that they'd probably be a lot of work to make and to keep up to date, but they are pretty invaluable for getting users up to speed. And the time spent doing these is an investment, you guys would spend less time answering questions and you'd probably have more committers which also saves time (maybe).

Edit: Now that I think about it, aren't DHH's Rails screencasts considered one of the reasons why Rails got as popular as it did?

There are a few Ember screencasts: https://peepcode.com/products/emberjs http://railscasts.com/episodes/408-ember-part-1 http://railscasts.com/episodes/410-ember-part-2

Unfortunately, both cost money at the moment but I've heard they're worth it.

Thanks, I'm aware of those. Nevertheless, three paid screencasts by third parties aimed mostly at beginners are not the same as a long-term effort made by the Ember team to make these videos and keep them up to date. IIRC, the Rails team was putting out like a video every month or so. This might be one of the things that made people aware of Rails since even non-Rails devs were aware of these videos and eventually, some of them were tempted to check out what the commotion was all about and eventually switched. If you show people how much one can do with Ember in say 10 minutes, more people will be interested in the framework.

Edit: Now that I'm rereading my post, it sounds really entitled and arrogant when it was not supposed to. It's more like "if I were on the Ember team, here's what I'd try to do".

Agreed, more screencasts would be wonderful. Unfortunately, we haven't had time for this yet. It's something we'd love to do if/when time permits.

What's needed, and I'm sure it's just a matter of time, is an embercasts.com in the style of railscasts.com. I think Ryan's way too busy to double his workload, so the opportunity is there for someone else to take up this banner.

Certainly iTunes U drove a lot of interest in iOS dev.

it would be great if you could help out more in irc. the noobs are asking pretty fundamental questions and not getting much help. i think it would help shape your guidelines as well to know about some of the problems on the front lines.

> getting started story

Try talking like a human or at least a developer and not a marketroid.

> The tone of this topic is not in line with the civil level of discourse I'd like to maintain here, so I cannot respond.

This sounds like the euphemistic version of "I don't like your attitude, so fuck off." Not exactly the answer I would want to get as a new user who is stumbling over terrible and inconsistent documentation and error messages.

Yes, that immediately turns me off the project. This is great feedback and not at all rude, I wish I could get feedback like this for my projects!

At least it's consistent with his "documentation czar" title. Definitely sounds like a Czar to me.

I agree that Trek's response here is not very helpful. However he has spent countless hours working on Ember's documentation and the fact that it's where it is now is due to his dedication. There's clearly more work to be done and we're all very well aware of that. We've been working on a getting started tutorial but it's been slow going since all of us on the Core Team are very busy with our day jobs. We hope to get something out for everyone as soon as possible.

That may very well be true but it doesn't change the fact that his response was very negative (much more so than the OP's) and for no good reason. The OP did not say "Trek sucks, his attempt at documentation is laughable" in fact I would venture a guess that the OP had no idea who Trek was prior to his posting. This was not an attack against Trek or the work he has done but rather a frustrated programmer explaining his predicament and asking for help and Trek told him he wasn't worth his time. If that's not pouring gas on the fire I don't know what is. If I were the OP I would completely abandoned trying to learn Ember.js after a comment like that, talk about kicking a man when he is already down.

These errors (and this frustrating process) are not at all unusual for Javascript libraries. Though I'm sure they could do some things better, I am afraid ember is taking a little bit of flak for the state of front end development, here.

This is all spot on. And despite the somewhat humorous, but not at all rude tone, this guy did some real leg-work to type this up. Documenting something in that much detail takes a lot of time (he went so far as to find the missing dependencies, and copied in the error messages at each step). Duck-debugging often works because you have to get specific, and logging issues is the same.

I've had this same experience with Node.js (http://nodejs.org/), whose homepage links to API Docs (not at all introductory or even linear). Granted, they don't say 'easy', but good documentation is still nice to have. Compare to Django documentation, which is expansive.

And I understand that these various frameworks are for seasoned developers who don't need HTML closing tags explained to them. But there are so many platforms and tools out there, and they so often take you from 'toy' to 'enterprise-scale' in this sparsely documented way.

>> this guy did some real leg-work to type this up

This is important to note. The guy obviously wants to use Ember. To me that's a signal that if you help the guy out or address his complaints, that he might actually become a huge cheerleader for Ember.

I am guessing that for every guy who takes the time to complain, there are probably ten more people who just visit some library's site, try the demo and cruise the docs, and if it doesn't work, say "this isn't worth more of my time, next."

That this guy stuck around and detailed what needed work really does say something.

Had a similar experience, then tried AngularJS. Couldn't be happier :) http://angularjs.org

Exactly the same here. I really wanted to like Ember, since I liked the documentation and read a bit about how the project started and how it works on a higher level. However, since I couldn't get through the Get Started tutorial, I gave up and went into angular instead, and I haven't looked back.

I'd like to give Ember a second chance, if only so I could be the only person on the internet that has tried both angular and Ember on a deeper level, but right now I'm not sure I'd do any better should I actually try again.

I reviewed both angular and ember for integration with a rails app for my job recently: https://github.com/et/ember_vs_angular To my dismay, we went with angular. In retrospect, after playing with the framework, I'm fairly pleased with the choice.

Same here - well documented although a lot of technical stuff involved but the fact that they use git for tutorials is nice. Loved playing around and being able to revert my changes back to the original state.

Angular is really great, just used it on a project for work. Didn't take long to pick up at all and I had things humming along in a few ours. Their documentation is pretty nice and there are a ton of great tutorials.

Same for me as well, I had previously used Backbone heavily at work (which is still awesome), but wanted to try something new. Angular has good docs, tutorials, screencasts and a very active Google Group with pretty helpful people.

Same here, but let's be honest and admit that angular docs suck even more. Thankfully, there's a number of other resources one can find plenty of help.

I'm interested by this because there is a huge amount of documentation for Angular and it's pretty good, including examples and plunker/jsfiddles to demonstrate it and allow you to play with it. What did you find lacking?

My first and strongest point isn't really the text itself, it's the organization and more "down to earth" examples. Google and it's products have historically poor UX, and Angular is no exception.

When you get to the page, you have 'develop' and 'learn' buttons, which one should I choose, I'm developing and learning at the same time. Okay, being new, let's go with tutorial. It says I should install testacular without any explanation how to organize files and tests in order to be effective. Moving on, okay, the tutorial is pretty basic, but wait, we're building an "app" so there must be some kind of session system, where can I find it? No clue.

What I'm trying to say is that two important things are missing, first a more "global" overview, a story, a use case for the angular itself, not just a number of isolated examples. Second, a nicer design for the docs, look for example this: http://www.chartjs.org/docs/ - It's one dude and he can do better than Google with pretty much unlimited resources?

I know many people compare Ember.js and Angular and while I prefer Angular by a wide margin, Ember's landing page wins hands down - it has soul. Angular has Twitter bootstrap.

I'm getting the feeling that Angular has now become the Haskell of client-side frameworks.

i.e. the one you'll see shamelessly plugged under every single discussion about any other client-side framework as if it is some work of genius, even though lots of users tend to agree that it's just yet another take on the subject that some like better and some don't, with some very lacking and outdated documentation and a much stronger and opinionated take on things that is simply not everyone's cup of tea.

With all due respect to the fantastic project that is Angular, I just wish people would stop flashing it everywhere like it's going to solve world hunger and programmer distress or something...

I don't think the parent post was suggesting anything of the sort. Instead of claiming to solve world hunger, it looks like AngularJS makes it possible to actually get started if you're new to this kind of framework.

I haven't tried Ember nor Angular yet (Ember because of a lack of documentation and Angular because I basically didn't hear much about it till today) but at this point, I'd use Angular simply because their website actually looks like it has a quickstart/tutorial that works.

I think he was making a greater point about how often Angular tends to pop up whenever this topic arises (which i've noticed a lot to my annoyance)

In part, it's relief. the Angular project has relatively minimal functionality and therefore does it quite well. The documentation is adequate (there are a few places where there are 'magic settings' which aren't immediately obvious, plus it pushes you to write tests.

Same here. Just now, working on a project based on angular. Great experience.

Same except we went the Backbone route. Very happy that we didn't stick with Ember.


Look at Batman.js if you ever have time over.

It really is not easy. I really want to like Ember, I really do. But I also gave up after being unable to wrap my head around it.

I read the official documentation, which is well written, but does not cover the big picture needed to tie everything together.

I watched the peepcode screencast, which is great, even if for me the pace could have been a bit faster. After that I was convinced I wanted to give Ember a shot.

I failed very early on, wanting to accomplish two things that I guess should be very common. But neither one is documented anywhere. And while I found a few answers on SO, those usually used functions that were either not documented at all or where the documented said they were meant for something else entirely.

The first thing was integration with server side authentication. The foundation was a pretty standard rails app that handled authentication. I wanted access to the current_user from the Ember App.

The second thing was loading a few models together with the initial page in order to save additional calls to the server. I do not even know where to look for documentation on how to accomplish this.

It probably does not help that Ember Data is a seperate project. Ember without Ember Data is no way near as useful as the combination of both.

Again, I really want to like Ember. I love Yehuda's work on other projects and some Ember features like data binding look awesome.

But trying to use Ember to write a new app from scratch that deviates slightly from basic CRUD gives me a headache.

I've been trying to put together a basic demo project that seems to do most of the things you're asking about: https://github.com/benburton/trakio

Hopefully it can be of use!

Am I making a mistake waiting on Ember-Data? I thought it was still in flux. The reason I have spent so much time recently with 1.0rc1 is that I finally expect Ember.js to be stable. I have just been using AJAx to manually fetch data as required.

This is pretty much why I didn't end up using Ember in a new project. After getting the same errors and figuring out the same solutions, I figured I had better things to do with my time.

It's a real shame, but just like developing web apps, you need to make sure users have a good first experience, otherwise they'll run away.

I tried Ember for over three weeks on an expected-to-be-large project in December/January. It seemed like a perfect fit - instead of using hackey URL/DOM-driven MVC framework on a complex project, Ember would absolve me of dealing with element IDs and $('#menu').bind(). I had done projects using Backbone but it seemed too simple for this project. I needed some structure and Ember would provide that.

I didn't give up in hours like the author and spent days reading through the tutorials on routings (which they changed), layouts (which got replaced), MVC, data-bindings, and everything that could make me proficient. After about 3 days of hacking, I managed to get ember to control a Bootstrap navmenu so that logged in users see something different from guests. I figured initially things would be slow but once I started thinking the 'Ember' way, my development speed would rise. It happened to me with OOP, functional programming, Java, Objective C, and RoR.

I continued working on the project using Ember and my productivity did not go through the roof. I was still trying to figure out the proper way to make Bootstrap Tabs work in Ember. It's views within a single view. Is that CollectionView? But I don't want to lose state when a tab changes. Should I hack my own TabView and TabViewController? I couldn't find others doing anything similar though lots of people were asking online about tabs in Ember. The tutorials were old and applied to deprecated Ember elements/concepts. I tried the Ember-Bootstrap library but it had problems too. There were sorta-ok answers on SO and Ember forums. It just didn't seem 'right'.

After three weeks of trying my best, I said 'ok, let me just try replacing it with Backbone and see how long that would take me.' Took under five hours to replace all of the Ember code with working Backbone code. Took another four hours to accomplish tabs, nested views, and data-bindings. I did more with Backbone in that one day than I could in Ember despite trying my best for 3 weeks. I'm not blaming the framework but I do realize it's not meant for me. I thought it was meant for exactly the kind of project I was working on but I couldn't make it work.

I did my best to grok the tutorials, the design patterns, and the Ember-way. But I still didn't "get" it. I do not understand why some things are Ember.X.create while others are Ember.X.extend. I liked the concept of Ember computed/aggregated properties but could never get them right and two-way data-binding was very difficult. So I switched to Backbone and haven't looked back. Maybe I'll try Ember again some day in the future when there is a single known way of dealing with basic things like TabViews.

Did you find a suitable alternative to Ember?

Did you find a suitable alternative to Ember?

I went with Amber in the end. I can't remember if it was more or less painful initially, but at that point I had spite in my fingers.

Not sure if there's also a lesson in that for startups: will you get lucky with some users just because they've had a bad experience immediately prior to checking you out?

Please talk a bit more about Amber. Easy to work with back end REST services? Easy to deploy?

Please talk a bit more about Amber. Easy to work with back end REST services? Easy to deploy?

I used it to build a very basic Jabber/XMPP client in a little over a day, integrating with an existing system.

That's the only project I've used it in so far, and I'm still very much a beginner user.

All I can say is that it solved a problem with the minimum of fuss and inside quite a strict time budget, so I'm very happy with it.

Check out http://angularjs.org ;)

Plenty of very good introduction videos on youtube

Hmm. I wonder what this emberjs is? I'll just click the home page link and find out. Oh. That just gives me the discussion board, which i'm already on. A bit more looking, a bit more hovering, and.... there isn't one. Close tab.

This seems like a variant of PBSALTPH, a silly initialism I coined when I found myself ranting about product blogs that don't link to product home pages [1].

Generally speaking, any subdomain or isolated "region" of a product web site should always provide a prominent link back to the product's home page. A good option is to use the product's logo as that link. Using the logo to link to anything other than the product home page is a crime against the gods of user experience.

[1] http://tiamat.tsotech.com/pbsaltph

Could not agree more, there was a post on HN about this recently[1] and I also found this[2] one when searching for the first.

[1] https://news.ycombinator.com/item?id=5267330 [2] https://news.ycombinator.com/item?id=4034972

Trek doesn't like this guy's tone, therefore he "can't" respond?

The guy didn't sound "uncivil" to me, he just sounded frustrated. If what he reported is accurate, the frustration seems totally understandable.

He was sarcastic but that's hardly being uncivil. Thing is, his complaint is probably very representative of many beginners so giving the impression that you're ignoring it can have a very negative impact on a project like Ember.js.

It's definitely understandable.

I spent about two weeks forcing my way to a functional Ember application, because the framework seemed to have promise.

In the process I needed to bother the developers on IRC, read a nontrivial fraction of the Ember JS code, and implement missing Ember functionality from scratch (KVO-compliant dictionaries).

Ember doesn't work unless you get everything right, and doesn't provide much in the way of diagnostics, so it was one of the harshest learning curves I've ever run into. They really need to work on their tutorials.

It works really well now, though. :X

trek just convinced me not to use Ember.

Apparently when you need help you're supposed to wait a few hours to cool down before you actually post your question.

Not sure how serious you are, but I hate what you just said. It's like.. YOUR software made me frustrated, don't tell me to just wait it off. The reason I'm talking to you like this is YOUR code. And sure, when it's just raving, that may be right, but the guy genuinely TRIED and went through hoop after hoop.

He was being sarcastic. I'm pretty sure you both agree to the same point.

Fist bump* then.

* - or any other commonly accepted ritual interpretable as "we cool, we cool". The cooler the better.

Hmm, I wasn't exactly thinking of it as sarcasm when I wrote it, more pointing out what trek seemed to be expecting, which seemed unreasonable to me. But I guess doing that amounts to the same thing as sarcasm.

Fist bump* in return.

I heart the love in that thread, guys!

Because, you know, ad hominem claims of lack of civility will always get you around the issue of having to face and talk about the pain points in your software.

(FTR: I think his reaction was deplorable) By din of its presence on the front page of HN he has to say something, but doesn't actually want to engage in what probably would become a massive ember-bashing thread by others who were frustrated with ember, so he acknowledged receipt without giving a formal response.

It's quite simple and sufficient to say something along the lines of "You are right, we are working on this. In the mean time check out some example code here...".

(I fully agree with you and I think the guy's comment was really poor) "You are right" admits that it is not currently easy, and I don't think he wanted to say that outright.

There is nothing wrong with admitting you were wrong or admitting someone else was right. It shows maturity.

That reaction is incredibly smug

he's way too "can't" actually more like cba to respond.

I'm always put off by the "look what can be done in just several lines!" code examples on frameworks front pages, they don't represent anything about the framework and usually the simpler the example, the more complex the framework is because everything is "magic" - try to do something differently and you end up hacking the framework internals.

It's especially offending when, as in this case, the bragging code-snippet omits half of the code that is needed to actually run the demo.

Ember is far from the only project guilty of this.

If you want to brag to me then make sure I can copy/paste your example to a file and it will run. I'll take a honest 50-liner over a dysfunct 10-liner any day.

In my personal opinion, I'd like to present a fair comparison with another similar framework called KnockoutJS.

I challenge anyone on Hackernews to show me better documentation than this one:


Notice how things are explained so well as if they were explained to a child, this is how you should document, IMO.

Also, RP Neimeyer, the creator (EDIT: Committer) of this framework, has dedicated a significant portion of his life to helping out new comers to the framework, by having a separate website (http://knockmeout.net) (apart from the one above) to train and help people understand KnockoutJS. This is the kind of effort every developer should put in, IMO, if they want people to get off the ground with their framework.

I didn't like it. Too much visual overhead. I didn't know where to look.

Also a few things went wrong (don't know what). I was clicking around in code window when the tutorial guide on the left disappeared, then I tried refreshing and everything went blank. So I clicked on url in the navbar and pressed enter. Now the page loaded. But everything was blank inside the boxes.

OSX 10.8.3 with chrome.

Ohh, I found out what went wrong. I tried scrolling in the code window and the browser went back to the last page which it thinks is: http://learn.knockoutjs.com/ and that makes the tutorial disappear.

KO has great how-tos and examples, no doubt, but I would never put it forward as an example of great documentation, for the single and very large fact that it's utterly lacking in API reference documentation. Where, for instance, can I find a list of the ko.utils.* namespace? How do I release bindings when I dispose of a view? The existing documentation gives me nothing. I'm left googling blogs and stackoverflow answers.

Compare that to http://docs.angularjs.org/api .

Real API documentation would do a lot to dispel the myth that KO is only for small to medium projects.

RP Niemeyer did not create Knockout. That was Steve Sanderson. Niemeyer has make but 9 commits to the Knockout codebase¹.

Knockout's tutorials are great. However, the rest of the documentation takes the form of other, slightly less helpful tutorials. The only API documentation is reading the code.

¹ https://github.com/SteveSanderson/knockout/commits?author=rn...

Oh sorry, I didn't know that! But I see only him answering SO questions and writing blog posts 99% of the time, hence the assumption..

Agreed - customer service at its finest and no doubt something we should all aspire to if we want to increase adoption.

I think the OP in that thread wrote a pretty amazing post, in all honesty.

Unlike your typical "it doesn't work" or "this sucks", the frustrated individual still takes care to detail, step by step, exactly what felt wrong or what was missing. In doing so, they demonstrate exactly why it's so frustrating.

There's feedback not only on the quality of the documentation, but the experience of getting an Ember app up and running. While improving the former would make life a bit simpler, the setup seemingly being so involved - requiring you to manually resolve missing dependencies - still diminishes the initial experience.

All of this makes it surprising that someone would totally dismiss it in such an unceremonious manner, and for reasons that are totally at conflict with what doubles up as a support forum. Is that discussion board there as a flagship Discourse site, or for support?

Regardless of the technical difference between Angular and Ember, I have to say that the Angular documentation is one of the best I have ever read for a software library.

I'm not just talking about how it's written (it's English, it's technical, the bar is pretty low) but how they structured it to address exactly what the OP is complaining about: each code listing is shown in a multi-tab pages showing 1) the .html files 2) the .js files and 3) the .css files.

The only thing that could make it even better would be a direct link to a jsfidle (externally or internally hosted) so I can try and tweak all these examples without having to write my own, but it's already excellent as it is.

I hope more libraries follow this documentation model.

Agree with this - I was planning to use Ember on a new project but quickly fell through holes in the documentation and had to give up and return to plain Backbone.

Not a very good way to handle potential users. It is quite the turn off while deciding between different JS frameworks to have someone representing the codebase refusing to respond to a user's troubles.

This was my experience when I tried to use Ember as well. Very frustrating.

What an obvious oversight. It is unbelievable that the developers would allow for a 'getting started' guide with such a poor first impression to exist. I have had a similar experience with jquery. As someone who has been using mootools before jquery I was completely furious with the lack of proper documentation and ambiguity in it. I hated learning jquery. Thank god mootools exists. Confusing, incomplete or ambiguous documentation is the absolute worst obstacle to a positive learning experience. I've not tried Ember, but if the experience is as the author describes, then I shall stick to angularjs. And what a tragic reaction to the criticism from the ember developer. It seems fitting that their documentation would be crappy. I'm sure that ember is a wonderful project and took a lot of hard work to create, but please fix the first experience - is important otherwise all that hard work goes to waste. Good luck.

It's a revealing commentary on the nature of the project and its developer community that this entire conversation seems to be about one dude. Suddenly, the "ember.js" brand collapses and becomes subsumed by the "trek" brand.

All other factors aside, it doesn't sound like the sort of healthy, active project that I like to use.

This sounds... familiar.

Precisely this sort of experience with Ember led me to write a Getting Started tutorial: https://github.com/regularfry/website/blob/master/source/gui...

Since my old stackoverflow answer was referenced in this topic , i've updated it to include a MVP QuickStart Guide. Hopefully this helps delvarworld and others get started with ember. Feedback welcome :-) http://stackoverflow.com/questions/14204674/how-to-architect...

People rave about node.js and kock ruby. People rave about ember and knock backbone. But when it comes to building apps, the tried and true approaches are the best I've found. There is plenty of documentation online and that really helps when you are starting out.

When I gave ember a whirl, the lack of documentation, forums, or just anyone using it -- outside a core group -- was very disturbing.

I just gave Ember a whirl the other day because I wanted to fiddle around with a prototype for an experimental interface. I'd had a little exposure to Ember and related projects before, and generally liked it, but hadn't really set it up entirely from scratch.

It was... amazingly annoying. And I don't just mean the fact that I needed to search around for a box that had an appropriate version of Ruby installed to build the ember-data project from source (heaven forbid that they offer a download of JavaScript, let alone a single package of all the libraries you're going to want to use for your project -- but it's okay, I'll forgive you, you're a release candidate). I mean the stuff where I wanted to load a simple skeletal data structure in JavaScript from JSON with a FixtureAdapter before attaching it to a real backend, and the documentation was all "sure, you can totally use a non-REST store!" -- http://emberjs.com/guides/models/defining-a-store/ -- but wasn't really strong on the How. Fortunately, StackOverflow came to my rescue: http://stackoverflow.com/questions/15301918/how-do-you-set-t...

But it was a negative experience. If I hadn't been exposed to a taste of its power and elegance before, I would have probably given up.

Erm, backbone is not exactly trivial for fresh newbies to learn...

That might be true, but the documentation is fairly comprehensive and well done. The docs were indispensable for me when learning how to use it.

If the new user 'try this out' tutorial is busted, and the core team knows this. why is ember being pushed so hard?

recently there were many articles on HN itself about how great ember is. if it's so great, why is it people get frustrated with the most simple tutorial?

Why was the response 'i refuse to respond' instead of 'this is a known issue, we're working on it as fast as we can'?

With my due respect to guys behind Ember, I don't understand why Ember gets so much attention. It has been in works for 4~5 years now but has not reached its 1.0 status. I've seen many complaints about its learning curve, documentation etc. However, when people talk about Javascript web frameworks to learn, it is often brought up as a candidate. Maybe someone can tell me why people think it will be a serious contender in this fast moving area.

trek: "I definitely feel your frustration. The tone of this topic is not in line with the civil level of discourse I'd like to maintain here, so I cannot respond."

Wow, could that response be any more passive aggressive?

Good point, and very thin-skinned. On the other hand, isn't this how many developers think and act? At least trek is being honest about it.

many or most? I think of most developers as folks who are asked questions "is it possible to do X?" and can't help answering "yes, but..." of course it's possible. And would equally be embarrassed when their code doesn't live up to marketing spin.

I also think any developer worth their salt is going to respond sheepish and apologetic when their code neither adheres to convention of the collective hacker zeitgeist or is documented sufficiently for someone reasonable to get it up and running quickly.

Maybe we need a new acronym: SNAP! "Sensitive new age programmer"

I would like to say "nothing is easy"; a mentor taught me that long ago. Also, when I read on the Ember home page that Ember is for building ambitious web applications, right a way I though I better read all the docs, the source code, and the tests to get to know what Ember does.

Since nothing is easy I would say that the Ember community is totally aware of that and very helpful. I was very impressed by the guides and the api docs. Reading the Ember source and especially the tests has helped me to begin to understand how Ember works.

For me getting started with Ember was not about completing a TODO app or just watching a tutorial video and then pounding out some code. But instead has been about studying existing applications like the Discourse application or the Travis app. I recently say I sweet Emberpress app much like the iOS app "Letterpress" and was amazed at how well the code just makes sense.

Getting started with Ember takes ambition and IMHO is well worth the investment.

About nine months ago, I tried Ember. I'm not a huge javascript guy, but I'm pretty good in Rails and have written a handful of javascript things. But anyway, I just couldn't get the stuff to work. All the tutorials, walkthroughs, getting started guides, git repos.... just tons of cryptic errors, strange behavior and terrible documentation. It seemed cool. I really wanted to like it.

But- I essentially got "the documentation is in the code" as an answer.

I don't know why Javascript programmers can't be bothered to return meaningful errors that actually hint at fixing the problem, especially when they are super common errors that everyone hits (such as the Handlebars version thing that was mentioned here).

With all the time and frustration needed to learn Ember just do it with Backbone

This was pretty much my pathway to developing my current app on Backbone. I think Backbone hits the sweet spot in terms of abstraction needed to structure an application in a maintainable way (and plays pretty nicely with require.js, which buys you a much better ability to break your app apart)

I've had a lot of trouble with learning ember while dealing with all the breaking changes as it's moved towards 1.0. The ember core team have said they're updating docs, and trying to get outdated tutorials marked as such, but until that time it's still a bit of a minefield.

So, if you'd like to chat about ember with other people learning, and not just have a channel full of unanswered questions (i.e. #emberjs), come join me on freenode at #emberjs-chat

I'm going to offer some unsolicited advice. The constructive way to deal with a project that you find interesting but undocumented or otherwise unpolished is to attack. Attack the bugs one by one as you hit them. Go straight to the source and read, read, read.

Ain't nobody got time for that?

Ah, but grasshopper, it seems hugely difficult to you because you lack practice. If you get in the habit of attacking code like this, you will get faster and faster at it. And then the next time a project comes along that's cool, bleeding-edge, and undocumented, you'll just pick it up and be working in no time.

Reading is the secret weapon that turns a mediocre programmer into a great programmer. You need to read a lot of other people's source code. And a situation like the one in this post is ideal: you have a specific problem you're trying to solve, and you have access to all the relevant source code.

If you really don't have time because you need to ship yesterday, then why are you trying to use pre-1.0 software? Go use something boring and proven.

Why not put that effort into learning JS instead of fixing someone else's JS framework?

Your question implies that frameworks are only for people who don't know Javascript. You might want to reconsider that.

I have some sympathy for the author of this comment. I have probably spent 25 hours trying to spin up on Ember.js in the last few weeks, concentrating both on Ember.js itself, and how to work with REST back ends written in Node.js and in Clojure (I have a few simple examples of this in public github repos). Yesterday I struggled getting simple auth working.

I am taking it a bit on faith that this work will pay off, even though my usual development "use cases" are fairly simple web apps where I just use a little AJAX (often pjax). I am assuming that if I master Ember.js then I will build more complex stuff.

I like Ember.js and Node.js - a light weight development kit. A few years ago I was doing GWT/SmartGWT for a customer: produces nice interactive web apps but development feels like running through mud.

Isn't all of this just blown out of proportion? Why not focus on how to help improve ember.js than one person's response? Even if that person contributes to the documentation and to the project. Get over it already.

It's incredibly out of proportion - but people really want to use ember (because it promises all these great things!) and they're frustrated by the docs (because they're not really good for first time users) so this is kind of a flash point.

For those who are finding it difficult to get a hello world up and running, see: http://plnkr.co/edit/gist:5206526?p=preview

I think that a lot of the kurfuffle viz. trek's response is a forum cultural shear. Trek's site is on Discourse, which has its own stricter rules of engagement that supercede those of the broader FOSS community. The rules on Discourse are moreover reasonable and well-advertised, even if you (or I) find them a touch stilted. It is trek's right and freedom to maintain whatever culture he sees fit on his site.

As an addendum, I tried Ember out and found it to be fairly easy. Is it plug and play, so to speak? No. Will it work in about 5 minutes, assuming you're well-versed in client- and server-side Javascript? It should.

"Easy" in this case means for the intended audience. Turning on a computer is "easy," but not if you tasked someone who'd just traveled from 1800 to do it.

Trek must have been a perl monk, back in the day.

Died laughing when I saw this title because it's exactly what I thought about Ember. For speed of development I kept flirting with Ember because of the "positives" I've heard. The oddities of its ecosystem and the rather disgruntled/angered contributors backlash towards negative feedback has really cast a negative shadow on it.

Beyond Ember.js this is a highly constructive approach to any API Library you are developing. Developers tend to disregard User Experience when building out tools for other developers. Put yourself in a first time users perspective like this and try to relate to that stream of consciousness.

Does anyone know of a JS framework which plays nicely with Server Sent Events or WebSockets? I've tried pretty much everything so far, and it's always a colossal hack to implement, as none of them seem to have been built with anything other than CRUD in mind.

SocketStream which is built around RPC (at least it was like that on 0.3 which I tried) and Derby.js which is build around model-view binding.

I used both a long time ago, not sure if they're still maintained.

Ah I quite like those two, but I was hoping for some client-side ones as most of my projects are in Ruby :)

I should try a project on Node again at some point, it has been quite a while.

It seems to me that this isn't feasible in pure client side because the server would have to agree on some kind of protocol.

Server-side is mandatory here. Unfortunately I cannot recommend any since I don't do Ruby :(

Maybe you don't need a framework but just a JSON-RPC[1] library.

[1] http://en.wikipedia.org/wiki/JSON-RPC

I'm really just looking for a model system that allows simple updates of objects in its identity map with data from an arbitrary source. Backbone is the closest I've found to supporting this with the least effort. I'd rather like to use Server Sent Events, as there's decent support in a variety of languages and it's pretty simple; it's just that no current frameworks seem to have been built with those sorts of technologies in mind.

I've largely resigned myself to having to hack support into anything I try.

FYI, Rob Conery just posted a great post that addresses the exact issues the OP had: http://wekeroad.com/2013/03/20/ember-baby-steps

Well damn, that's what you get for choosing something new and Bleeding Edge.

People expect a lot of documentations, tutorials, good community and comercial support for something that was released a couple months ago...

The problem is the fact that the marketing copy on the site + the messaging by the contributors would lead one to assume that Ember is pretty well polished, stable and ready to build big things on top of -today-.

This is a good example of a bad attitude.

This person was someone who had the skills to plow through the frustrations and could have made a contribution by writing that missing tutorial, but instead chose to gripe.

From personal experience in order to get started just checking out the documentation(i had started with the old documentation now called guides) should be fine. Some googling around might be needed but should not take much time. Generally i agree that it is a bit hard to get used to the framework, but if one has the ability to look in the console and figure out errors, should not really have any problems getting started with emberjs. Also just grabbing code from the first page, i don't think is a really good idea. Does this technique work with other popular frameworks like http://nodejs.org/ http://jquery.com/ .... ?

Bad move Trek.

Shoutout to everyone on freenode's #emberjs that has helped me work through these troubles.

Thank you for writing this. That is all I am going to say.

I'm so numb to this kind of pain...

Moved to the correct thread per @kbenson's response

You responded in the wrong order. The important point is that Ember is trying to improve, and values the feedback, right?

Defending another team member that you didn't think represented himself well should be secondary. He's a grown man, and can defend himself if needed (especially from the fallout of his own words). Addressing this first just gives me the impression that Ember is focusing on, and learning the wrong lesson, from this problem.

You're right, this should have specifically been in response to the post that was expressing frustration with Trek.

Love ember!!!

The only truth I've seen is on the first page of http://batmanjs.org

It is _THAT_ easy :)

The all caps headline is a little too much for my taste.

... says the one with the all caps user name.

It's not quite the same, I know. I saw your comment and had to respond.

I'd change it to lowercase if I knew how

I suspect he just copied and pasted the text from the homepage.

Apparently someone likes the all caps version: http://cdn.memegenerator.net/instances/400x/36418027.jpg

Thanks to whoever changed it

Well the "it's easy" is the selling point, no? I suppose the "ease" of using it depends on one's aptitude. 8-)

Well, programming is not always easy.

I felt that kind of frustation when I tried for the first time almost every library/programming language that I'd worked with, either with java, backbone, coldfusion, rails...

Trying and researching things is always part of the process, we can't run away from that.

It's far easier to start from a basic working shell that you can tweak than it is to build something from zero. Plenty of environments manage to pull off that basic working shell just fine. If you make a new app project in Xcode, the result builds and runs out of the box. If you make a new Android app project, the result builds and runs out of the box. I can try out Python code immediately after typing "python" at the command line.

Programming is inherently hard, but there's still a vast gulf between necessary and unnecessary difficulty. The problems here are solidly in the "unnecessary" category.

> Well, programming is not always easy.

Nobody is saying that it is. OP's title was directly in response to the ember.js homepage (where it says "GETTING STARTED WITH EMBER.JS IS EASY."). S/he encountered some (pretty understandable) frustration and pointed out a few major shortfalls in ember's documentation, before asking for assistance; that's not at all running away from "the process".

Waving away legitimate (non-trolling) complaints in a dismissive way is pretty condescending, and not at all helpful to the main issue.

Trying and researching things is always part of the process, we can't run away from that.

You're right: there will always be a learning curve, whatever is being learnt.

I think the problem with Ember is that it makes the opposite claims, and fails to deliver, only because the documentation is lacking.

Yes, I meant that when I start to learn thing like java and rails, everybody said that these product were easier than "x", but I didn't find them that way.

It probably takes a huge amount of work to make something easy to use.

Look at Go.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact