Re: Shrinking existing libraries as a goal

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
> >> >
> >> >
> >
> >
>