Re: [Feature Proposal] New attributes "library" and "version" on script tags

Yes, I would love to hear a browser vendor's take on this as well.

Admittedly, browser vendors would have the job of determining what 
libraries and versions to ship with, but the benefit to this is that, if 
a vendor doesn't ship a particular version of a particular library, the 
browser would fall back to downloading the script identified in the src 
attribute. The worst case is essentially exactly the performance we have 
today. Browser vendors will have to weight the drawbacks of additional 
install heft against the benefits of greater performance. Javascript 
libraries do have the benefit of being small compared to the install 
size of a browser, though, and are highly compressible, meaning that the 
heft of adding numerous versions of numerous libraries could still 
equate to less than a megabyte of additional install size.

As to determining the library name, there would have to be coordination. 
Perhaps the easiest way to coordinate naming is to have the name come 
from the script authors. This way, the script authors themselves would 
ensure (and would be motivated to ensure) that their script can be 
called consistently across web browsers. I don't think there should be 
some master list created by a standards body, since the web can be fluid 
and fickle: today's favorite could be tomorrow's so-last-week. A 
standards body might have a hard time keeping up. Browser vendors may 
even be able to point to having a larger or newer library of 
pre-installed libraries as a competitive advantage that puts no 
additional lock-in into the web because of this lower formality.

-Chris.

On 08/10/2013 03:24 AM, Steve Fenton wrote:
> It would be interested to hear a browser vendor take on this. They would have to ship a browser with how many versions of how many libraries? They would also have to add new versions as they became available. There might not be much implementor support for this kind of thing.
>
> Also, the library name would need some kind of control to avoid two browsers coming up with a different name for the same library, for example if one implementor called something jquery.ui and another jqueryui.
>
> That isn't to say the attributes suggestion is good or bad.
>
> Steve
>
> On 8 Aug 2013, at 22:47, Chris <chris@cbojar.net> wrote:
>
>> Hello everyone,
>>
>> I would humbly like to propose a new feature that has been rolling around in my head recently: new attributes "library" and "version" on script tags.
>>
>> Javascript libraries have proliferated like rabbits in recent years, but a few notable examples have risen to the top, earning a place in the head tags of many websites. These libraries are powerful, but often hefty. This effect is most noticeable on mobile devices and/or slow connections, but are still able to be felt even on the fastest downlinks. They also can be fragmented, different versions spread across different CDNs or websites, all pointing to essentially the same library, but no way to know whether http://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js and http://codeorigin.jquery.com/jquery-1.10.2.min.js are the same library without downloading them.
>>
>> I would then suggest adding the library and version attributes to the script tag to alleviate some of these problems. First and for clarity's sake, they would be of the following form:
>>
>>     <script library="jQuery" version="1.10.2" src="http://codeorigin.jquery.com/jquery-1.10.2.min.js"></script>
>>
>> Such a form provides a two-fold benefit. First, there is now a semantic metadata associated with the script. We can see directly which library and version are being used, and can associate the specific src URL with an abstract library. That is nice, but there is a second benefit that can be derived from such data: a browser may come installed with a pre-determined set of popular libraries, and, if it recognizes a library and version as pre-installed, may use that in place rather than needing to issue a new request, download, and cache a new file, even if it may already be cached from a different location. Thus, such as in the example given above, a browser may recognize this script reference as a pre-installed library, and call it from local storage /on the very first visit/ rather than across the network. Of course, if the library is not recognized, the script would be downloaded as normal.
>>
>> Older browsers appear to ignore what they consider extraneous attributes in the script tag, and thus would treat this as a normal script tag and download accordingly, meaning there should not be any backwards-compatibility issues.
>>
>> Here are the caveats I've considered already:
>>     The library tag should be interpreted without regard to case. In the real world, people will use all kinds of combinations, but jQuery, jquery, Jquery, and JQuery should all be interpreted to be the same.
>>
>>     The version tag to do best greatest matching to what is available locally. A version="1" in the example above should call the latest 1.x version of the script available (in this case at the present time, 1.10.2). A version="1.9" should call the latest 1.9.x version of the script available (in this case at the present time, 1.9.2). If the version tag is omitted completely, the library used will default to the latest locally available version. It is the responsibility of developers to ensure that their script can interoperate properly down the version line if they use this.
>>
>>     The version tag may be used without the library tag (though with obviously diminished usefulness). Sometimes developers may want to version their own internal libraries. Browsers should just ignore the attribute in this case.
>>
>>     Browsers with pre-installed versions of libraries can no only improve performance by saving RTT, but may also improve performance by compressing, optimizing and tuning for the particular environment, removing unnecessary cross-browser compatibilities, and precompiling (if applicable). They would only need to maintain API compatibility, but could reimplement internals if they so chose.
>>
>>
>> If you got all the way here, thanks for reading and let me know what you think (or what I'm missing).
>>
>> Regards,
>> -Chris.
>>
>>

Received on Saturday, 10 August 2013 17:25:21 UTC