Re: Shrinking existing libraries as a goal

On Thu, May 17, 2012 at 9:31 AM, Scott González <scott.gonzalez@gmail.com>wrote:

> I'm sure Yehuda can speak more to the status of scriptlib, but the way I
> see it is:
>
> There was a some buzz about scriptlib and the W3C being excited about
> developers participating via CGs.
> Very few developers joined. 33 scriptlib members compared to 287
> jquery-standards[1] members.
> There were 0 meaningful posts. 4 total messages (including hello world)
> compared to 138 messages for jquery-standards.
> Nothing came out of scriptlib, compared to 19 issues[2] in jquery-standards
>
> AFAICT, there are two explanations for this: First, developers at large
> don't find CGs very inviting. Second, everyone on scriptlib is highly
> experienced and very interested in standards; to the point where they'll
> just go to the appropriate non-CG list to discuss things.
>
> With that being said, It's good to see W3C pointing to CGs for input :-)
>
> [1] https://groups.google.com/group/jquery-standards
> [2] https://github.com/jquery/standards/issues
>
>
>
> On Thu, May 17, 2012 at 7:17 AM, Arthur Barstow <art.barstow@nokia.com>wrote:
>
>> FYI, a Script Library Community Group (Cc'ed) was formed some time ago
>> and it may have some similar interest(s) <http://www.w3.org/community/**
>> scriptlib/ <http://www.w3.org/community/scriptlib/>> (although their
>> mail list archive indicates the CG isn't very active).
>>
>> Perhaps someone in that CG has some comments on Yehuda' email.
>>
>> -AB
>>
>> P.S. Yehuda's email archive is <http://lists.w3.org/Archives/**
>> Public/public-webapps/**2012AprJun/0762.html<http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0762.html>
>> >
>>
>>
>> On 5/16/12 10:13 PM, ext Ojan Vafai wrote:
>>
>>> In principle, I agree with this as a valid goal. It's one among many
>>> though, so the devil is in the details of each specific proposal to balance
>>> out this goal with others (e.g. keeping the platform consistent). I'd love
>>> to see your list of proposals of what it would take to considerably shrink
>>> jQuery.
>>>
>>> On Tue, May 15, 2012 at 9:32 PM, Yehuda Katz <wycats@gmail.com <mailto:
>>> wycats@gmail.com>> wrote:
>>>
>>>    In the past year or so, I've participated in a number of threads
>>>    that were implicitly about adding features to browsers that would
>>>    shrink the size of existing libraries.
>>>
>>>    Inevitably, those discussions end up litigating whether making it
>>>    easier for jQuery (or some other library) to do the task is a good
>>>    idea in the first place.
>>>
>>>    While those discussions are extremely useful, I feel it would be
>>>    useful for a group to focus on proposals that would shrink the
>>>    size of existing libraries with the implicit assumption that it
>>>    was a good idea.
>>>
>>>    From some basic experimentation I've personally done with the
>>>    jQuery codebase, I feel that such a group could rather quickly
>>>    identify enough areas to make a much smaller version of jQuery
>>>    that ran on modern browsers plausible. I also think that having
>>>    data to support or refute that assertion would be useful, as it's
>>>    often made casually in meta-discussions.
>>>
>>>    If there is a strong reason that people feel that a focused effort
>>>    to identify ways to shrink existing popular libraries in new
>>>    browsers would be a bad idea, I'd be very interested to hear it.
>>>
>>>    Thanks so much for your consideration,
>>>
>>>    Yehuda Katz
>>>    jQuery Foundation
>>>    (ph) 718.877.1325 <tel:718.877.1325>
>>>
>>>
>>>
>>
>
Mike Taylor and I tried to ignite scriptlib interest at JSConf with a track
B presentation to raise awareness. It's just not happening.


I fully support Yehuda's proposed goals. DOM APIs are being designed by
non-web developers and non-JavaScript programmers that simply "don't get
it" and when confronted, the response is frequently "library authors will
fix this" - which in turns makes libraries bigger, instead of smaller.


Even more important then considering library size is to simply consider
motivating factors for library adoption. Take the following API evolution...


What standards bodies did:

    element.onclick = ...

        ↓

    element.addEventListener( "click", ..., boolean );


What we did in the trenches:

    element.onclick = ...

        ↓

    element.addEventListener( "click", ..., boolean );

        ↓

    element.observe( "click", ....

        ↓

    [elements].on( "click", ...


Why isn't this being standardized? There is concrete evidence that supports
this as a preferred API.


Even more problematic is event object target creation: JavaScript programs
that run in browsers are asynchronous event systems, but libraries have to
create their own systems because in 2012, we still can't inherit from
EventTarget [1] - and even if I could, the API is an overlong wind-bag.
Compare the IDL definition for EventTarget to a very popular, generic,
reusable Event system API: http://nodejs.org/docs/v0.7.8/api/events.html


Consider the cowpath metaphor - web developers have made highways out of
sticks, grass and mud - what we need is someone to pour the concrete.


Rick


[1] http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventTarget