"Getting started with Ember.Js is easy." - No it isn't
discuss.emberjs.com
discuss.emberjs.com
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.
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.
http://twitter.com/trek/status/302811479135092736
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."
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.
When I get to release and am happy with the state of the documentation I will likely try the same thing.
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.
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.
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.
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
Instead of commenting on #HN how awful ungrateful sarcastic users are, write a new "Getting started" page.
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.
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.
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.
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.
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?
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.
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.
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.'
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".
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.
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 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.
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.
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.
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.
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.
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.
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.
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 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 kind of feedback that has a point?
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.
@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...
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-...
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.
TLDR:
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.
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.
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.
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.
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 ...
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.
I have experienced this kind of thing many times over the course of my life. There's no way I could remain emotionally detached.
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.
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.
I think I know which strategy is more likely to result in better documentation.
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.
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 >_>
> 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 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.
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.
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).
Specifically:
* 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
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!"
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).
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.
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.
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?
Unfortunately, both cost money at the moment but I've heard they're worth it.
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".
Try talking like a human or at least a developer and not a marketroid.
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.
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 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.
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.
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.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 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 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.
Hopefully it can be of use!
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 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.
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?
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.
Plenty of very good introduction videos on youtube
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] https://news.ycombinator.com/item?id=5267330 [2] https://news.ycombinator.com/item?id=4034972
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
* - or any other commonly accepted ritual interpretable as "we cool, we cool". The cooler the better.
Fist bump* in return.
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.
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.
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.
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.
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...
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?
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.
All other factors aside, it doesn't sound like the sort of healthy, active project that I like to use.
Precisely this sort of experience with Ember led me to write a Getting Started tutorial: https://github.com/regularfry/website/blob/master/source/gui...
When I gave ember a whirl, the lack of documentation, forums, or just anyone using it -- outside a core group -- was very disturbing.
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.
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'?
Wow, could that response be any more passive aggressive?
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"
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.
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).
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
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.
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.
"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.
I used both a long time ago, not sure if they're still maintained.
I should try a project on Node again at some point, it has been quite a while.
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.
I've largely resigned myself to having to hack support into anything I try.
People expect a lot of documentations, tutorials, good community and comercial support for something that was released a couple months ago...
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.
http://toranbillups.com/blog/archive/2013/03/02/emberjs-rc1-...
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.
It is _THAT_ easy :)
It's not quite the same, I know. I saw your comment and had to respond.
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.
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.
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.
Look at Go.
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.