Re: Shrinking existing libraries as a goal

To me the biggest abomination of all is the XMLHttpRequest object:

   - the spec is probably one of the most complex I've seen
   - yet, vast portions are left to interpretations or even not specified
   at all:
      - the local filesystem comes to mind,
      - also every browser has its own specific way of notifying
      non-applicative errors (like network errors):
         - specific status,
         - unhandleable asychronously thrown exception,
         - exception thrown when accessing a field,
         - etc...

And that's just the tip of the iceberg. It's got to a point where the
almighty xhr bleeds through abstractions and makes it impossible to design
proper API (at least not if you want to leak memory like crazy).

Finally, fixing xhr issues always seem like low priority items in browser
bug trackers because there's always some kind of workaround, that libraries
like jQuery have to put in their code (provided it can be feature tested
which it cannot most of the time).

I've been meaning to do a test suite to help provide guidance to
implementors (something I figure would be much more useful than yet another
round of specs) but I admit I haven't got to it yet.

Dunno how people feel about this, but I think providing test suites that
browsers could test against as a way to prevent regressions and
inconsistencies could help a lot as a starting point.


2012/5/18 Yehuda Katz <wycats@gmail.com>

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