Re: Shrinking existing libraries as a goal

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



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



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