Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

On 2/25/13 1:15 PM, Scott Miles wrote:
> You cannot accidentally stumble into ShadowDOM. You have to actively
> take that step.

Sure.  We all know this.  I'm not sure why this strawman keeps getting 
argued.

> For one thing, I suggest that most of the time, the component code is
> shipping w/your application, you are not depending on some resource that
> will simply be upgraded out from under you.

"your application"?

The problem is when things that are poking at the internals of the 
components aren't part of "your application".

I suggest you have a look at things like Optimizely for examples of the 
sort of invasive monkey-patching going on right now.

> For another thing, if I decide it's necessary to monkey-patch some
> third-party code that's I'm using in my application, I'm generally
> pretty upset if that code is privatized. It makes that unpleasant work
> much harder. I need to ship ASAP, and maintenance concerns are secondary.

Sure.  Is this situation more common than browser extensions or ad 
scripts that monkeypatch things?

> Either way the last thing I'm going to do is wily-nily update that code
> and then blame the developer that my monkey-patch broke. Yes, someone
> could complain in that scenario, but they have no leg to stand on.

I'm sorry, but this is hilarious.  People complain in this scenario all 
the time, and whether they have a leg to stand on is simply a function 
of their market penetration.

> Boris says the above has been a big problem at Mozilla.

With extensions monkey-patching XBL bindings, for example, yes.

> This confuses me. Do developer's not know that monkey-patching clearly private code is
> bad for their maintenance?

No, they don't.  See your comments about "need to ship ASAP" above. 
Most people don't even bother to think about the maintainence problems 
their introduce; they just figure if anything changes they'll shout 
loudly for it to unchange.

For example, a common monkeypatching technique I've seen is grabbing a 
function exported by the component, calling toString on it, doing some 
regexp search/replace on that string and then doing new Function() with 
the result and sticking it back on the component.  And people get 
outraged if this breaks because the toString of the function changed in 
any way.

 > I don't see how this can be the library
> vendor's problem

It becomes the library vendor's problem as soon as the set of things 
that depend on the monkeypatching has enough market share.

> I suppose there is a moral hazard argument: if we make it possible,
> people will overdo it.

Indeed.

> This is probably true, but IMO it's akin to
> saying chefs should only use butter knives because they could cut
> themselves on the sharp kind.

No, more like saying that the kind of knife the chef is using shouldn't 
be forced depend on where they got their tomatoes from, so when the chef 
develops RSI they can use a more ergonomic knife to cut the tomatoes.

> Lastly, only a subset of possible upgrades actually are transparent, not
> affecting public API or behavior. Intersect that set of updates with
> monkey-patchers who can't live without the update, and you are talking
> about a relatively small affected class.

Do you have actual numbers to back this up?  In my experience the 
affected class is actually pretty large, because monkey-patching 
behavior is very common and changing the source of functions, say, 
without changing their public API is not that rare either.

-Boris

Received on Monday, 25 February 2013 18:33:45 UTC