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

Hi.

I think it's an interesting idea!
This is a fact, that many pages use(kinda waste) new requisitions to the
same scripts.

cheers.



On Thu, Aug 8, 2013 at 6:47 PM, 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<http://ajax.googleapis.com/ajax/libs/jquery/1.10.2/jquery.min.js>and
> http://codeorigin.jquery.com/**jquery-1.10.2.min.js<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<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.
>
>
>


-- 
*Felipe N. Moura*
Senior Web Developer

Website:  http://felipenmoura.org
 Twitter:    @felipenmoura <http://twitter.com/felipenmoura>
LinkedIn: http://goo.gl/qGmq

Meet some of my projects:
BrazilJS Conference <http://braziljs.com.br/>  |  BrazilJS
Foundation<http://braziljs.org>
|  Power Polygon <http://github.com/braziljs/power-polygon>  |
TheWebMind<http://thewebmind.org/>  |
PHPDevBar<https://addons.mozilla.org/pt-BR/firefox/addon/php-developer-toolbar/>
---------------------------------
LinuxUser #508332
*Changing  the  world*  is the least I expect from  myself!