backbone-ember-back-and-forth-transcript.sh

#!/bin/sh

# on osx lion, this is a great way to listen to this in the background. make sure to download and
# install sangeeta and tom and karen in system preferences. feel free to change the voices to your
# suiting, but sangeeta is a fave of mine for almost everything.

say -v Sangeeta "hey"
say -v Sangeeta "I'm sorry"
say -v Sangeeta "how would you like me to describe backbone?"
say -v Sangeeta "let's work this out for once and for all :)"
say -v Sangeeta "I'm definitely not intentionally saying incorrect things about backbone"
say -v Tom "don't worry about it too much -- I'm just not terribly pleased with backbone being continued to be used as the strawman..."
say -v Sangeeta "I am worried about it a lot"
say -v Sangeeta "what particularly am I saying that is unfair?"
say -v Tom "If we're going to continue making intentionally slanted direct comparisons, then perhaps we should just add \"Why Ember and not Backbone\" and \"Why Backbone and not Ember\" sections to our respective sites ... so folks can at least read both sides."
say -v Karen "do something like this: http://jqueryvsmootools.com/"
say -v Tom "I'll have to listen to it again, if you'd like me to find all the specific bits -- and can't at the moment."
say -v Tom "Perhaps later this afternoon."
say -v Sangeeta "I did not enjoy that site :p"
say -v Tom "The main point is that all of the specific bits that you call out as limitations of Backbone, that Ember tries to address -- are all there willfully (at least the ones you mentioned in the podcast)."
say -v Karen "-1 on a backbone vs ember site imo"
say -v Sangeeta "of course that's true"
say -v Sangeeta "that doesn't make them not limitations, right?"
say -v Tom "It's Backbone's take that Ember's more complex data binding model, intermediate controllers, run loop etc. ... are all interesting approaches, but are *not* actually helpful in building a real site."
say -v Tom "What's the the points of view diverge."
say -v Tom "sorry."
say -v Tom "That's where..."
say -v Karen "TBH, I don't think that each framework needs to make an argument why this than that on their respective site. Other developers will blog about it when they need to make that decision. I've seen at least three different articles comparing js mvc frameworks."
say -v Sangeeta "I find it difficult for backbone developers who have not tried Ember to make that argument, when many Ember developers who come from previous attempts at backbone disagree"
say -v Karen "my favorite comparison was Addy Osmani's github repo with a Todo app built in each framework"
say -v Tom "And if you present it in that way, I think it's fair to draw direct comparisons.. but that's not the way I hear you presenting it."
say -v Sangeeta "in other words \"*not* actually helpful in building a real site\" is something that people who used both backbone and ember disagree with"
say -v Karen "it's how you present the limitations.... for backbone.js they are philosophies"
say -v Tom "and I find quite the opposite -- self-selecting sample pools, as you'd expect."
say -v Sangeeta "you have a lot of people who wrote entire apps in Ember, then went to backbone and say that Ember's approach was completely useless and superfluous?"
say -v Sangeeta "obviously, people who dabbled in one or the other aren't useful in answering the question"
say -v Karen "backbone.js' philosophies are more inline with the philosophies in the node.js community than in the rails community."
say -v Tom "yes. I don't know of a *lot* of people who have tried both in anger."
say -v Tom "but the ones who have."
say -v Sangeeta "so then it's fair to say that for *some* people, Ember's approach is overkill"
say -v Sangeeta "and those are the people you know"
say -v Sangeeta "but you're saying it like an absolute"
say -v Sangeeta "it's ALWAYS overkill"
say -v Tom "likewise, people who just drink the @wycats kool-aid aren't useful in answering the question, as tasty as it may be ;)"
say -v Sangeeta "trolololololol"
say -v Sangeeta "backbone is 600 lines of code"
say -v Sangeeta "the idea that there are things missing in it that are common should not be controversial"
say -v Tom "Ah -- but I don't ever say that, especially not in interviews ... and definitely not without mentioning the couterpoint view."
say -v Karen "Yeah i think that jashkenas's point was that you're picking on a group that self-selects, and he could do the same equally."
say -v Sangeeta "JS Jabber is not an interview"
say -v Tom "podcast."
say -v Sangeeta "my point is that since our arguments are different, his position requires 100% and mine doesn't"
say -v Sangeeta "podcasts are basically jabbering"
say -v Sangeeta "harder to stay in control of everything you say week in and week out"
say -v Sangeeta "anyway"
say -v Sangeeta "my argument is:"
say -v Tom "anyhow, gotta run to a meeting. back in a bit."
say -v Sangeeta "\"in some complex cases, Ember's approach will pay dividends\""
say -v Karen "I haven't used ember.js myself, but I think the best explanation for people is drawing upon comparisons with past frameworks. \"If you like how rails works, you'll probably like how ember.js works. If you find that convention over configuration gets in your way, you'll like how backbone.js works\""
say -v Sangeeta "your argument is"
say -v Sangeeta "\"it is never useful\""
say -v Karen "i.e. present it from the point of view of a \"developer value system\" instead of comparing features"
say -v Sangeeta "so you finding a few people who find it as overkill is less useful than me finding a few people who find it useful"
say -v Sangeeta "I think that's fair"
say -v Sangeeta "I doubt that Rails/Backbone evangelists would agree with that argument"
say -v Karen "that doesn't sound quite like the case you're making incidentally.  There's a difference between saying \"you should use ember over backbone because ember has advanced bindings\" and saying \"If you find backbone's facilities for bindings inadequate, you should use ember\""
say -v Sangeeta "I would argue that they are often inadequate"
say -v Sangeeta "and often error-prone"
say -v Sangeeta "not that they are ALWAYS inadequate"
say -v Sangeeta "jQuery is often not inadequate"
say -v Karen "It's really all about values. Occasionally I get frustrated by things backbone.js doesn't do and occasionally I get frustrated by things rails does that are hard to undo. My personal preference is to have a framework not do something and implement it myself than have a framework do something and figure out how to do the opposite. That's me. I know people who feel differently"
say -v Sangeeta "jQuery has evented facilities"
say -v Karen "save all this for the conference!"
say -v Karen "thunderdome :D"
say -v Sangeeta "nah… gotta figure out what jashkenas is comfortable with so I don't make an enemy accidentally :P"
say -v Karen "unless you're a dog person i don't see that happening"
say -v Karen "gonna be at backboneconf? :)"
say -v Sangeeta "speaking, yeah"
say -v Karen "THERE CAN BE ONLY ONE"
say -v Karen "nice."
say -v Karen "I don't see why would they disagree with that. Philosophically the development of rails and backbone.js has been very different"
say -v Karen "anything wrong with dogs?"
say -v Karen "backbone.js development has been cautious about including what isn't code (like node.js development) and rails development has been an eager adopter of new ways of doing things (e.g. sass and coffeescript inclusion by default)"
say -v Sangeeta "lots of people who love Rails have drunk the jashkenas cool-aid (BAM)"
say -v Tom "ok -- meeting postponed briefly."
say -v Karen "i don't dispute that, but you do see that the design philosophies are very different"
say -v Tom "in terms of not getting my goat, the main thing is just to put in a preface while you talk about it ..."
say -v Sangeeta "I doubt Rails/backbone adherents would be willing to accept that Backbone differs philosophically from Rails"
say -v Karen "to wit, pre-asset pipeline IMO jammit is by far the best solution"
say -v Sangeeta "\"if you like Rails, you'll like Ember\" is not something Backbone folks in Rails would agree with, and I'm not even sure Jeremy would"
say -v Tom "feel free to say backbone is always or often as inadequate as you like ... just mention that the backbone opinion is that its that way for good reasons, and have similar critiques of ember."
say -v Sangeeta "sure… no problem"
say -v Sangeeta "my style is to make my position as strongly as I can, and let someone with the opposite position argue back -- unfortunately, there is nobody willing to take the strong Backbone position on JS Jabber"
say -v Karen "i didn't mean \"if you like rails, you'll like ember\"... I meant \"if you like the convention over configuration way that rails handles things, you'll like ember\""
say -v Sangeeta "now you're just parsing words, no?"
say -v Sangeeta "people like Rails because of CoC"
say -v Karen "backbone.js isn't convention over configuration"
say -v Sangeeta "end result: my normal style makes me look like I'm steamrolling Backbone"
say -v Tom "right -- which is a fine style as long as you make that clear. I think that in many circles (Ruby at least, less so with JS) wycats' words are taken as gospel."
say -v Sangeeta "then if you like CoC, which Rails people do, you should be disappointed in backbone"
say -v Sangeeta "that is obviously not the case ;)"
say -v Sangeeta "or serializers would be in Rails"
say -v Tom "oh, did they get blocked?"
say -v Sangeeta "yeps"
say -v Tom "on what grounds?"
say -v Karen "wat"
say -v Sangeeta "he prefers the jbuilder API"
say -v Sangeeta "DHH"
say -v Tom "ah, interesting."
say -v Tom "real meeting now."
say -v Sangeeta "my argument is that consistency is important when talking to clients"
say -v Sangeeta "and that hand-crafting JSON is not a win, especially in the CoC world of Rails"
say -v Sangeeta "anyway, DHH gets to win"
say -v Karen "that's interesting"
say -v Sangeeta "but if there were as many kool-aid drinkers as you think, it would be in"
say -v Karen "cause we spend a lot of time working with presenters these days, but it always feels silly hand-crafting JSON"
say -v Sangeeta "confirm"
say -v Sangeeta "serializers are basically presenters for your JSON"
say -v Sangeeta "with conventional rules"
say -v Sangeeta "you can specify in your ApplicationSerializer what rules should exist"
say -v Karen "in the CoC world I agree, but if you are not doing basic CRUD, then you want handcrafted JSON."
say -v Sangeeta "not necessarily"
say -v Sangeeta "serializers map onto REST, not CRUD"
say -v Sangeeta "if you have a REST client, consistency is still important"
say -v Karen "is this what you're referring to? https://github.com/josevalim/active_model_serializers"
say -v Sangeeta "for Livingsocial, our Ember models map directly on Rails *resources*, which may or many not be backed by Rails *models*"
say -v Sangeeta "yessir"
say -v Karen "ya, we've ended up re-implementing something similar, +1 for getting in rails >_<"
say -v Sangeeta "documentation could be better"
say -v Karen "awesome, thanks"
say -v Karen "yeah serializers ftw"
say -v Sangeeta "the main reason I ended up wanting this was that the easy ember pattern is: { posts: [ { id: 1, comments: [ 1,2,3 ] }, … ], comments: [ { id: 1, … }, … ] }"
say -v Sangeeta "and doing that in Rails is annoying"
say -v Karen "I didn't know you were consulting for livingsocial, I know a couple folks here at their boulder office"
say -v Sangeeta "especially when auth is involved"
say -v Sangeeta "I wanted a separate object to control it"
say -v Karen "I am curious on your all's opinion of this way of using views: https://gist.github.com/1731369"
say -v Karen "I would prefer a way for the top level element of my template to become the `el` property of the view when it's rendered, but I'm not sure of the downsides of doing this?"
say -v Karen "(thanks for any opinions, comments ;)"
say -v Karen "I'm not that familiar with serializers so I can't really offer an opinion. Personally I started with javascript and moved to rails so I don't know how all the parts work and all the resources that are available."
say -v Sangeeta "no problem"
say -v Karen "I think part of the appeal of backbone.js and the reason it was successful early on is because (1) it's small so the learning curve was small and the investment to get into it was low when all the other options looked riskier; (2) it's still very unclear how the relationship between the server and the client will turn out"
say -v Sangeeta "I don't agree that the learning curve is small"
say -v Sangeeta "the surface area of the API is large"
say -v Sangeeta "I agree on (2)"
say -v Tom "back, if you've got more questions.."
say -v Sangeeta "are you sure you wanted to take the absolutist \"Ember is never useful\" position?"
say -v Tom "no -- I definitely don't take that position. "
say -v Tom "I take the same one you do ;)"
say -v Karen "told you :P"
say -v Tom "usually not useful."
say -v Tom "often not what you're looking for ... ;)"
say -v Tom "will get you in trouble in many places."
say -v Tom "etc."
say -v Sangeeta "here's what you said: \"It's Backbone's take that Ember's more complex data binding model, intermediate controllers, run loop etc. ... are all interesting approaches, but are *not* actually helpful in building a real site\""
say -v Sangeeta "do you want: \"It's Backbone's take that Ember's more complex data binding model, intermediate controllers, run loop etc. ... are all interesting approaches, but are *not* usually helpful in building a real site\""
say -v Tom "sure, that's better."
say -v Karen "maybe the differentiation is \"site\" vs \"web application\"…?"
say -v Sangeeta "seems ok… more reasonable to have an argument on those terms"
say -v Sangeeta "nah"
say -v Sangeeta "backbone apps are apps"
say -v Sangeeta "not sites"
say -v Karen "there are strong and weak claims on both sides."
say -v Sangeeta "sites are brochure sites"
say -v Karen "*nod*"
say -v Tom "yes -- we're both talking about apps here."
say -v Karen "...definitely make that distinction...backbone is for an app, not a site."
say -v Sangeeta "I don't ever make the claim that backbone is useless for simple'ish apps"
say -v Sangeeta "jashkenas definitely does make the claim that ember is useless for complicated'ish apps"
say -v Karen "yeah, i think clarifying by saying \"app\" instead of \"site\" could make a difference in how the statement is taken"
say -v Sangeeta "or at least, way more trouble than it's worth"
say -v Sangeeta "I used to be the guy trying to convince jQuery people to write evented code and use jQuery.data() on plain objects more"
say -v Tom "I don't make that claim when I talk about backbone -- that's my point."
say -v Tom "When I do a backbone talk, I don't usually mention Ember."
say -v Sangeeta "lifestyles of the rich and the famous"
say -v Sangeeta "when you're on top, you don't punch down c/d"
say -v Sangeeta ":P"
say -v Tom "When you do an Ember talk, I've heard you talk about every feature in the context of how backbone is doing it wrong."
say -v Sangeeta "I think you went to one of my Ember talks"
say -v Sangeeta "one of my least prepared Ember talks ever"
say -v Tom "eh, I've heard other folks tweet the same sentiment."
say -v Sangeeta "also, I saw you in the audience and was trolling a bit :P"
say -v Sangeeta "I for sure mention backbone in ember talks"
say -v Sangeeta "just like DHH mentioned JAva"
say -v Sangeeta "Java*"
say -v Sangeeta "early on"
say -v Sangeeta "here's the thing"
say -v Sangeeta "the features you say are \"useless\""
say -v Sangeeta "are actually selling points of ember"
say -v Tom "right, they're why you sell ember as a backbone++, and not as a sproutcore-- ;)"
say -v Sangeeta "so we need to explain where backbone falls short"
say -v Sangeeta "in order to explain why the features that you think are useless matter"
say -v Sangeeta "saying it's backbone++ isn't that far off from saying it's vapor++"
say -v Sangeeta "backbone is 600loc"
say -v Sangeeta "it's basically structure"
say -v Sangeeta "\"here's how you should think about your app structure\""
say -v Karen "you could make a positive case for Ember w/o reference to backbone though couldn't you?"
say -v Tom "or you could just talk about Ember? "
say -v Sangeeta "I will retract my troll"
say -v Sangeeta "maybe"
say -v Sangeeta "but for instance, the problems of dealing with intermediate state during a single event handle are best explained with reference to some simpler system"
say -v Sangeeta "at jQuery Conf last year I did it vs. $().data()"
say -v Sangeeta "I also argue against silent sets often, because backbone is a good point of reference"
say -v Sangeeta "for a while I tried to keep it generic, but then I had to explain the context of what backbone is doing without mentioning backbone"
say -v Sangeeta "hard to do in a 30 minute talk"
say -v Tom "$.data is an abomination ;)"
say -v Tom "It's a great strawman, I understand the temptation."
say -v Tom "It's also an easy target when you don't have a countering voice in the room."
say -v Tom "But that doesn't mean I have to like it."
say -v Karen "hrm i recommend data to find list items in a list"
say -v Sangeeta "lots of backbone people use data"
say -v Sangeeta "search of stackoverflow ;)"
say -v Karen "As much as you may not agree with it, I think it is fair for wycats to make the comparison to backbone.js in his talks, because I imagine that everyone in the audience has the question \"how does ember compare to this backbone.js framework that many people are using\""
say -v Karen "i think the point is they aren't comparable"
say -v Tom "it's totally fair -- I just want him to inform about the differences, not misinform."
say -v Karen "can i use ember to power a subset of my blog in node?"
say -v Karen "no?"
say -v Sangeeta "they are though… ember is saying that what people do with say -v Karen is better done with bindings, computed properties, or whatever"
say -v Karen "Well, they have to be comparable.  The question is whether what's the fair basis for comparison, or if there is one."
say -v Sangeeta "you can absolutely use ember-runtime in node"
say -v Karen "if that's what the audience wants to hear it's fair to at least touch upon the subject (but probably not make the whole talk or most of the talk about it)"
say -v Karen "slick, for some reason i was under the impression it was browser only"
say -v Karen "my bad"
say -v Sangeeta "I'm never like \"here's why you should use ember instead of backbone\" -- it's more like \"here's why this feature in ember exists vs. the way you would do it in backbone\""
say -v Karen "one counter down!"
say -v Sangeeta "you should be more explicit in telling me where you think I am misinforming -- I am happy to remove or clarify incorrect things from future talks"
say -v Karen "i like how walmart used backbone to create thorax on top of it.  i have no opinion of the quality of thorax, but its neat how this library can be built upon"
say -v Karen "bones is another framework that achieves a specific goal"
say -v Karen "that i don't think ember would really be a fit for"
say -v Karen "it seems ember wants to be end-to-end"
say -v Sangeeta "not surprised that people can build things on top of backbone :)"
say -v Tom "ok ... to be specific."
say -v Karen "well right, but i see that as an excellent feature"
say -v Karen "coders be coding"
say -v Sangeeta "ember is an end-to-end framework built on top of more modular components"
say -v Karen "yeah"
say -v Tom "(although I think we've discussed these things before in person)"
say -v Sangeeta "for instance, ebryn wrote a titanium app and built ember-titanium"
say -v Karen "putting myself in the audience's shoes, I imagine one of two scenarios: (1) I don't use any framework and I want to know if ember.js is right for my needs, in which case you'd address when ember.js is the right tool for the job, or (2) I am already using ember.js and want to know more about it."
say -v Sangeeta "\"when ember.js is the right tool for the job\" is never how my talks go -- I talk about features that ember.js has, and why they need to exist"
say -v Sangeeta "I can either compare them to a hypothetical framework that looks like backbone (or spine, or whatever)"
say -v Sangeeta "or something concrete"
say -v Sangeeta "lately I've been going with concrete to save time"
say -v Tom "the ember/SC run loop is touted as a feature, but the backbone perspective is that it's an anti-pattern: synchronicity-by-default is an important feature in client-side updates, not to be given up lightly. You can always defer if you want to defer."
say -v Karen "most people view ember.js through the lens of backbone"
say -v Sangeeta "specifically, rendering synchronicity?"
say -v Karen "I think getting into how ember.js vs how backbone.js is great for people implementing frameworks, but for end-users it's the why that matters"
say -v Karen "I'd say it comes up in 95% of conversations I have with people"
say -v Karen "yeah i can def agree with that"
say -v Karen "doesn't mean its right :)"
say -v Sangeeta "Ember tends to use the run loop much less often than SC1"
say -v Sangeeta "I don't think it's a moral question ;)"
say -v Tom "so you're admitting it! ;)"
say -v Sangeeta "there are different cases -- we defer rendering"
say -v Tom "ember bindings for events are great, but computed properties are overkill."
say -v Sangeeta "we defer destroying objects"
say -v Tom "simple functions work better most of the time."
say -v Sangeeta "computed properties are important if you propagate changes"
say -v Tom "if you want to precompute a value, that's not hard to do."
say -v Sangeeta "simple functions can't know whether to propagate the changes"
say -v Tom "the firstName, lastName example is a toy."
say -v Karen "totally agree. most conversations are probably \"I want to give my users a better experience. I'm thinking of using backbone.js but want to know more about ember.js. when is ember.js the right tool for the job\""
say -v Tom "that's correct -- you listen for changes to the source data"
say -v Tom "and render computed values."
say -v Tom "not hard."
say -v Sangeeta "yes… a pattern that happens sufficiently often that it's good to abstract"
say -v Sangeeta "not hard, but tedious"
say -v Karen "discussing the features should be framed by the question \"under what use cases will these features be the right tool for the job\""
say -v Karen "exactly"
say -v Karen "if I may quote from the backbone 0.9.0 change log:"
say -v Karen "Two new properties on views: $el — a cached jQuery (or Zepto) reference to the view's element, and setElement, which should be used instead of manually setting a view's el"
say -v Sangeeta "computed properties are abstracting \"listen for these three properties, and if any of them change, tell anyone listening to me that they have changed\""
say -v Tom "no -- tedious in Ember -- where you have to specify dependencies."
say -v Karen "no feature ever needs to exist but they might be very desirable for certain jobs"
say -v Karen "you know, if you had computed properties, you wouldn't make users think about the distinction here"
say -v Tom "in the source"
say -v Sangeeta "you have to do the same thing in backbone"
say -v Sangeeta "but ad hoc"
say -v Sangeeta "you can skip the dependencies in Ember if you don't care about invalidation"
say -v Sangeeta "but that is basically never the case"
say -v Karen ":P"
say -v Sangeeta "do you disagree that the pattern \"listen for these properties, and when any of them changes, trigger observers\" is very common?"
say -v Sangeeta "and that those observers often render"
say -v Sangeeta "or trigger more observers?"
say -v Tom "yes -- and you want to listen to *real* properties."
say -v Tom "computed properties are fake properties that you can listen to, but can't set."
say -v Sangeeta "you can set them"
say -v Tom "if you define a setter function?"
say -v Sangeeta "you can implement setting inside a computed property"
say -v Sangeeta "it's in the todos tutorial :P"
say -v Tom "a whole level of complexity that you totally don't need."
say -v Sangeeta "in most cases, they're abstracting the observer pattern so you don't need a setter"
say -v Tom "anyhow, moving on."
say -v Tom "forcing your users to use logic-less templates is *incredibly* constraining."
say -v Tom "necessary for embers goals -- for sure."
say -v Karen "ember supports any templating language you'd like"
say -v Tom "But not an advantage for most apps."
say -v Karen "you just don't get auto-updating"
say -v Tom "right, exactly."
say -v Sangeeta "what % of backbone apps use mustache, handlebars, dust, etc.?"
say -v Karen "we very specifically designed the views to be template engine agnostic"
say -v Tom "it's all over the place, template wise, as you'd expect."
say -v Sangeeta "yes, but you say \"not an advantage\""
say -v Tom "what % of ember apps don't use handlebars?"
say -v Sangeeta "many of your users disagree with you"
say -v Karen "hey knowtheory can i ask you a question in a pm as to not distract from this"
say -v Karen "all of ebryn's titanium stuff, for example"
say -v Sangeeta "I would guess most of your users disagree with you"
say -v Tom "the majority of 'em don't ... and both can be served equally well."
say -v Tom "no, not the majority."
say -v Sangeeta "you have done a census?"
say -v Sangeeta "mine was a guess -- you seem pretty sure"
say -v Tom "just from memory."
say -v Sangeeta "ok"
say -v Tom "but it would be good to do."
say -v Karen "i think it's all over the place and that's a good thing... everyone chooses what is best for them."
say -v Sangeeta "what do you use?"
say -v Sangeeta "anyway, the built-in templating is very explicitly a design choice… I don't think I ever bash backbone for supporting multiple template engines"
say -v Sangeeta "Ember's templating support is about as integrated as ERB in Rails"
say -v Karen "used _ templates first but was forced to switch to handlebars because of problems with Rails asset pipeline and the erb gem"
say -v Karen "I'm gonna write my own framework… with blackjack, and hookers."
say -v Karen "--Bender"
say -v Sangeeta "seems good"
say -v Tom "finally, and perhaps most importantly, embers tight coupling of handlebars-ui-with-very-specific-bindings-to-ember-models is trouble, performance-wise. You can't build the really intensive parts of your UI with that level of binding / dom tweaking."
say -v Sangeeta "exposing the performance question to the user is trouble"
say -v Tom "So backbone makes it easy to zoom in and out from granular updates to bulk-y ones, from aggregate views to very specific ones..."
say -v Tom "Making it possible for backbone to be helpful in even high-performance JS UIs."
say -v Sangeeta "over the long haul Ember will be able to heuristically decide how bulky to update"
say -v Tom "sufficiently smart compiler, eh?"
say -v Sangeeta ":P"
say -v Sangeeta "I feel like the sufficiently smart compiler argument has actually won"
say -v Sangeeta "not sure why people make fun of it ;)"
say -v Tom "so -- those are some of the specific comparisons from my point of view."
say -v Karen "On one hand I find mustache to be more restricting, but on the other hand i like the handlebars helpers. so i consider the switch to be net neutral"
say -v Sangeeta "but anyway, we can easily have support for bulky updates"
say -v Karen "oops i mean handlebars not mustache"
say -v Tom "And the kind of thing that I'd say if we were both in the room..."
say -v Sangeeta "I think 0.9.5 or 0.9.6 will have that"
say -v Tom "I'm not asking you to say any of that..."
say -v Tom "But at least mention that an opposing point of view does exist."
say -v Sangeeta "no problem -- I always assume people just know that :P"
say -v Sangeeta "but sure"
say -v Sangeeta "I can be more explicit"
say -v Tom "Thanks -- much appreciated."
say -v Sangeeta "I have no interest in antagonism"
say -v Tom "Earlier today, I was tempted to add some of those critiques to backbonejs.org -- would you like to have that happen, or would you prefer me to leave the comparisons alone?"
say -v Sangeeta "I think it's fair for people to make strong versions of their arguments, but I'm not interesed in pissing people off"
say -v Sangeeta "go for it"
say -v Sangeeta "we can add responses"
say -v Tom "hah."
say -v Sangeeta "it's a high-wire act"
say -v Sangeeta "I think it was good for DHH to throw a few bombs Java's way"
say -v Karen "that's a hard assumption except when people have some level of familiarity with the different options being discussed"
say -v Sangeeta "and I don't think he needed to say \"of course, Java disagrees with me here\" all the time :P"
say -v Karen "fwiw I have much respect for backbone"
say -v Sangeeta "same"
say -v Karen "you guys did what we could never do with sprout core 1"
say -v Tom "well, what's good politics, and what's good engineering don't often align ;)"
say -v Tom "I'd rather not play politician."
say -v Karen "you're viewed as a authority on the subject (which you are) so people assume you're giving a completely balanced view"
say -v Tom "andrewdeandrade++"
say -v Sangeeta "seems weird, since I'm explicitly advocating a position"
say -v Sangeeta "Obama is an authority on foreign policy, but nobody things everything he says is unanimously agreed to"
say -v Sangeeta "experts almost by definition take controversial positions"
say -v Sangeeta "anyway, I have no problem adding more caveats to what I sad"
say -v Sangeeta "say"
say -v Tom "much appreciated. "
say -v Karen "I've only seen one of your talks, the RailsConf BR talk about a year ago and i think that the subject is so new to a lot of people that the newness of the topic at hand overwhelms most people in the audience that they don't get the impression that it's a particluar viewpoint"
say -v Sangeeta "I don't like playing politician, but I find that when I don't, other people smash me"
say -v Sangeeta "hm"
say -v Karen "it's hard to perceive advocacy for one side or the other if you still are unsure about what the sides are"
say -v Sangeeta "I think bocoup's advocacy has a similar flavor to what you're saying"
say -v Tom "I think you've got a pretty solid record at winning code-politics debates."
say -v Karen "imagine watching a talk at the republican national convention when you don't know what republicans and democrats are or know very little about them."
say -v Tom "agreed -- I'd like bocoup to tone it down as well."
say -v Sangeeta "I'm persistent"
say -v Karen "when you know both sides exist and have cursory knowledge and even an opinion on both, advocacy is obvious. but when you don't, you tend to assume authority not advocacy"
say -v Tom "hey -- for what it's worth, I asked them to not name it \"backboneconf\" before the announcement ... but to pick a more inclusive name."
say -v Tom "and invite all the client-side-js-app folks."
say -v Sangeeta "yeah"
say -v Sangeeta "they invited me :)"
say -v Sangeeta "I was confused"
say -v Sangeeta "backbone == client side MVC?"
say -v Sangeeta "seems weird bro"
say -v Tom "amen."