Re: Shrinking existing libraries as a goal

I am working on it. I was just getting some feedback on the general idea
before I sunk a bunch of time in it.

Keep an eye out :D

Yehuda Katz
(ph) 718.877.1325


On Thu, May 17, 2012 at 3:18 PM, Brian Kardell <bkardell@gmail.com> wrote:

> Has anyone compiled an more general and easy to reference list of the
> stuff jquery has to normalize across browsers new and old?  For example,
> ready, event models in general, query selector differences, etc?
>  On May 17, 2012 3:52 PM, "Rick Waldron" <waldron.rick@gmail.com> wrote:
>
>>
>>
>> On Thu, May 17, 2012 at 3:21 PM, Brian Kardell <bkardell@gmail.com>wrote:
>>
>>> On Thu, May 17, 2012 at 2:47 PM, Rick Waldron <waldron.rick@gmail.com>
>>> wrote:
>>> >
>>> >
>>> > On Thu, May 17, 2012 at 2:35 PM, Brian Kardell <bkardell@gmail.com>
>>> wrote:
>>> >>
>>> >> So, out of curiosity - do you have a list of things?  I'm wondering
>>> >> where some efforts fall in all of this - whether they are good or bad
>>> >> on this scale, etc... For example:  querySelectorAll - it has a few
>>> >> significant differences from jQuery both in terms of what it will
>>> >> return (jquery uses getElementById in the case that someone does #,
>>> >> for example, but querySelectorAll doesn't do that if there are
>>> >> multiple instances of the same id in the tree)
>>> >
>>> >
>>> > Which is an abomination for for developers to deal with, considering
>>> the ID
>>> > attribute value "must be unique amongst all the IDs in the element's
>>> home
>>> > subtree"[1] . qSA should've been spec'ed to enforce the definition of
>>> an ID
>>> > by only returning the first match for an ID selector - devs would've
>>> learned
>>> > quickly how that worked; since it doesn't and since getElementById is
>>> > faster, jQuery must take on the additional code burden, via cover API,
>>> in
>>> > order to make a reasonably usable DOM querying interface. jQuery says
>>> > "you're welcome".
>>> >
>>> >
>>> >
>>> >>
>>> >> and performance (this
>>> >> example illustrates both - since jQuery is doing the simpler thing in
>>> >> all cases, it is actually able to be faster (though technically not
>>> >> correct)
>>> >
>>> >
>>> >
>>> > I'd argue that qSA, in its own contradictory specification, is "not
>>> > correct".
>>>
>>> It has been argued in the past - I'm taking no position here, just
>>> noting.  For posterity (not you specifically, but for the benefit of
>>> those who don't follow so closely), the HTML link also references DOM
>>> Core, which has stated for some time that getElementById should return
>>> the _first_  element with that ID in the document (implying that there
>>> could be more than one) [a] and despite whatever CSS has said since
>>> day one (ids are unique in a doc) [b] a quick check in your favorite
>>> browser will show that CSS doesn't care, it will style all IDs that
>>> match.  So basically - qSA matches CSS, which does kind of make sense
>>> to me... I'd love to see it "corrected" in CSS too (first element with
>>> that ID if there are more than one) but it has been argued that a lot
>>> of stuff (more than we'd like to admit) would break.
>>>
>>> >> in some very difficult ones. Previously, this was something
>>> >> that the browser APIs just didn't offer at all -- now they offer them,
>>> >> but jQuery has mitigation to do in order to use them effectively since
>>> >> they do not have parity.
>>> >
>>> >
>>> > Yes, we're trying to reduce the amount of mitigation that is required
>>> of
>>> > libraries to implement reasonable apis. This is a multi-view
>>> discussion:
>>> > short and long term.
>>> >
>>>
>>> So can someone name specific items?   Would qSA / find been pretty
>>> high on that list?  Is it "better" for jQuery (specifically) that we
>>> have them in their current state or worse?  Just curious.
>>>
>>
>> TBH, the current state can't get any worse, though I'm sure it will.
>> Assuming you're referring to this:
>> http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1454.html
>>
>> ... Yes, APIs like this would be improvements, especially considering the
>> pace of implementation in modern browsers - hypothetically, this could be
>> in wide implementation in less then a year; by then development of a sort
>> of "jQuery 2.0" could happen -- same API, but perhaps modern browser only??
>> This is hypothetical of course.
>>
>>
>>
>> Rick
>>
>>
>>
>>>
>>> [a] -
>>> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-document-getelementbyid
>>> [b] - http://www.w3.org/TR/CSS1/#id-as-selector
>>
>>
>>
>>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> >
>>> > Rick
>>> >
>>> >
>>> > [1]
>>> http://www.whatwg.org/specs/web-apps/current-work/#the-id-attribute
>>> >
>>> >
>>> >>
>>> >>
>>> >> On Thu, May 17, 2012 at 2:16 PM, Yehuda Katz <wycats@gmail.com>
>>> wrote:
>>> >> >
>>> >> > Yehuda Katz
>>> >> > (ph) 718.877.1325
>>> >> >
>>> >> >
>>> >> > On Thu, May 17, 2012 at 10:37 AM, John J Barton
>>> >> > <johnjbarton@johnjbarton.com> wrote:
>>> >> >>
>>> >> >> On Thu, May 17, 2012 at 10:10 AM, Tab Atkins Jr. <
>>> jackalmage@gmail.com>
>>> >> >> wrote:
>>> >> >> > On Thu, May 17, 2012 at 9:56 AM, John J Barton
>>> >> >> > <johnjbarton@johnjbarton.com> wrote:
>>> >> >> >> On Thu, May 17, 2012 at 9:29 AM, Rick Waldron
>>> >> >> >> <waldron.rick@gmail.com>
>>> >> >> >> wrote:
>>> >> >> >>> Consider the cowpath metaphor - web developers have made
>>> highways
>>> >> >> >>> out
>>> >> >> >>> of
>>> >> >> >>> sticks, grass and mud - what we need is someone to pour the
>>> >> >> >>> concrete.
>>> >> >> >>
>>> >> >> >> I'm confused. Is the goal shorter load times (Yehuda) or better
>>> >> >> >> developer ergonomics (Waldron)?
>>> >> >> >>
>>> >> >> >> Of course *some* choices may do both. Some may not.
>>> >> >> >
>>> >> >> > Libraries generally do three things: (1) patch over browser
>>> >> >> > inconsistencies, (2) fix bad ergonomics in APIs, and (3) add new
>>> >> >> > features*.
>>> >> >> >
>>> >> >> > #1 is just background noise; we can't do anything except write
>>> good
>>> >> >> > specs, patch our browsers, and migrate users.
>>> >> >> >
>>> >> >> > #3 is the normal mode of operations here.  I'm sure there are
>>> plenty
>>> >> >> > of features currently done purely in libraries that would benefit
>>> >> >> > from
>>> >> >> > being proposed here, like Promises, but I don't think we need to
>>> push
>>> >> >> > too hard on this case.  It'll open itself up on its own, more or
>>> >> >> > less.
>>> >> >> >  Still, something to pay attention to.
>>> >> >> >
>>> >> >> > #2 is the kicker, and I believe what Yehuda is mostly talking
>>> about.
>>> >> >> > There's a *lot* of code in libraries which offers no new
>>> features,
>>> >> >> > only a vastly more convenient syntax for existing features.
>>>  This is
>>> >> >> > a
>>> >> >> > large part of the reason why jQuery got so popular.  Fixing this
>>> both
>>> >> >> > makes the web easier to program for and reduces library weight.
>>> >> >>
>>> >> >> Yes! Fixing ergonomics of APIs has dramatically improved web
>>> >> >> programming.  I'm convinced that concrete proposals vetted by major
>>> >> >> library developers would be welcomed and have good traction. (Even
>>> >> >> better would be a common shim library demonstrating the impact).
>>> >> >>
>>> >> >> Measuring these changes by the numbers of bytes removed from
>>> downloads
>>> >> >> seems 'nice to have' but should not be the goal IMO.
>>> >> >
>>> >> >
>>> >> > We can use "bytes removed from downloads" as a proxy of developer
>>> >> > ergonomics
>>> >> > because it means that useful, ergonomics-enhancing features from
>>> >> > libraries
>>> >> > are now in the platform.
>>> >> >
>>> >> > Further, shrinking the size of libraries provides more headroom for
>>> >> > higher
>>> >> > level abstractions on resource-constrained devices, instead of
>>> wasting
>>> >> > the
>>> >> > first 35k of downloading and executing on relatively low-level
>>> >> > primitives
>>> >> > provided by jQuery because the primitives provided by the platform
>>> >> > itself
>>> >> > are unwieldy.
>>> >> >
>>> >> >>
>>> >> >>
>>> >> >> jjb
>>> >> >>
>>> >> >> >
>>> >> >> > * Yes, #3 is basically a subset of #2 since libraries aren't
>>> >> >> > rewriting
>>> >> >> > the JS engine, but there's a line you can draw between "here's an
>>> >> >> > existing feature, but with better syntax" and "here's a
>>> fundamentally
>>> >> >> > new idea, which you could do before but only with extreme
>>> >> >> > contortions".
>>> >> >> >
>>> >> >> > ~TJ
>>> >> >
>>> >> >
>>> >
>>> >
>>>
>>
>>