Mozilla & LABjs… part 2

This post is the immediate “part 2″ follow-up to Mozilla & LABjs: the story unfolds. Definitely read that before proceeding to read here.

As I mentioned at the beginning of that previous post, I am writing to address the points raised in the comment by the Mozilla developer who was responsible for the change in script-load-order behavior. I already responded in part 1 to the overal condescending (in my opinion) tone of that comment, but here I will address very specific points made.

Dive in

That’s not a safe data point to draw forward-looking expectations from. IE and WebKit haven’t executed script-inserted external scripts in insertion order. When two browsers do one thing and two other do another thing, it should be no surprise to anyone that when standardization happens, at least two browsers need to change their behavior to comply.

I can’t stress this enough: When you see that one set of browsers do one thing on a given point and another set of browsers does something else on the same point, you shouldn’t assume that these two sets of browser will retain differing behaviors forever.

When you see one set of browsers doing one thing and another doing another, UA sniffing (LABjs doesn’t sniff the UA string but it sniffs “Gecko” from the presence of MozAppearance) is exactly the wrong thing to do.

I addressed this point in the previous post, but let me reiterate: It’s not my fault the browsers have carelessly left these doors wide open. I was not content to sit on the sidelines and wait for years while web performance optimization remained impossible to grasp. So I jumped into the fray and solved the use case based on what we have now.

I’m not so naive as to believe the landscape of browsers and features will never change. That’s not the point of my complaint. The whole point of my complaint with Mozilla (and with ill-conceived/short-sighted standards you’re falling back on) is that if you’re going to change behavior, you have to engage the community actively, especially the community that’s most affected.

LABjs is, I think fair to say, pretty well known at this point, and it’s not unreasonable to think that Mozilla could have done some google searches to see if there were any well-known or widely-used tools that may be affected by the change. Certainly LABjs would have come up somewhere in the first page or two of some of those searches.

I fully expect browsers to change and get better, but what must also happen is that the browsers must engage the community to see what the needs are. Mozilla has a GREAT TRACK RECORD in the community of this in the past. But the handling of this particular issue, I think was not up to that same “standard”.

What I would have hoped for, and what I hope for still, is that Mozilla will proactively try to address the valid and already existent use cases when they make a change to behavior. If you can’t support the behavior any more, give us a way to definitively detect the change (so we can still support backwards in your browser family) and also give us some alternative that still serves the use-case. Callously claiming that the use case is not valid (or even “may not be”) is not a way to endear you to the members of the community.

The right thing to do is to do something that works without browser sniffing in all current browsers. For cross-origin script library loads this means designing the script libraries in such a way that the act of evaluating a given library doesn’t cause the library to call into another library but only makes the API of the script available such that only calling the API potentially causes a cross-library call. (Yes, I’m saying that in the current environment, that LABjs probably shouldn’t have tried to provide cross-origin ordered loading of external scripts given that it couldn’t be provided without either UA-sniffing or making dangerous assumptions about the caching relationship of loads initiated by object/img elements and loads initiated by script elements.)

This is an absurd assertion to make. I don’t consider it a valid option to just say LABjs should never have happened because the browsers and standards didn’t have a solution. Would you say the same thing to Steve’s face: “Steve… stop trying to improve the web performance optimization of scripts loading, because it’s not possible to do so yet.” That’s ludicrous.

Page 1 of 6 | Next page