- From: Scott Miles <sjmiles@google.com>
- Date: Mon, 25 Feb 2013 11:43:02 -0800
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: public-webapps <public-webapps@w3.org>
- Message-ID: <CAHbmOLZ72t-nvDtTSnrDiyubOcNPdNeNpOWkhmsJSp1-TQqA3g@mail.gmail.com>
On Mon, Feb 25, 2013 at 11:30 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 2/25/13 1:52 PM, Scott Miles wrote: > >> Given Boris' arguments, Big Marketshare can simply always mess up his >> project and blame me and it's my fault. >> > > Scott, > > That's how it often works in the court of public opinion, yes. > > Your employer is not immune to this behavior. > > > I don't accept it. >> > > That's nice. So what? > > > Btw, If Big Marketshare is so powerful, why haven't we already fixed >> whatever thing he is monkey patching? >> > > Because he hasn't bothered to tell us about it; just monkeypatched and > shipped (not least because he didn't want to wait for us to fix it). Again, > your employer is not immune to this behavior. > > The good part is that in this forum I get to argue my own opinion, which I would say is that of a (single) web developer. > > Also, Optimizely, et al, doesn't simply appear at random. >> > > Sure. They get included by the page, but the page may not realize what > all they then go and mess with. > > > Again, seems >> like your argument is that some developer or user may take wanton stet X >> to break my stuff, and I must prevent it or it's my fault. >> > > I think you're trying to paint this black-or-white in a way that seems > more about arguing strawmen than addressing the problem. > > When something breaks in app A due to a change in component B, the problem > could be fixed in B, in A, neither, or both. > > What happens in practice typically depends on the specifics of the change > an the specifics of who A and B are, what contracts they have signed, and > how much market power they have. > > You may not like this. _I_ don't like it. But it's reality. Ironically, I was trying to argue that these things are on a spectrum and that it is in fact not black and white. Often the argument is, "with isolation, maintenance is free!" and the alternative is chaos. Seems like we both agree this is not true. > > > re: "forced depend on where they got their tomatoes from" and "You >> cannot accidentally stumble into ShadowDOM" >> >> The reason the latter keeps being mentioned is because of statements >> like the former. Nobody is forcing anybody to break encapsulation. Seems >> to me the demarcation is very clear. >> > > My point is that people will break encapsulation without being forced to. > A lot. At least that's what my implementation experience with XBL leads > me to believe. This is the moral hazard argument, which is completely worth discussing. Because it's about human nature, I believe there is no objective right answer, but my position as a developer is that I'm annoyed when tools prevent me from doing something I need to do because somebody else might hurt themselves doing it. > > Lastly, my point about upgrade statistics is only that the intersection >> of the two sets is generally going to be smaller than the union of them. >> > > Sure. > > -Boris >
Received on Monday, 25 February 2013 19:43:31 UTC