Re: Shrinking existing libraries as a goal

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
>