Questions and comments on Knockout, jQuery and agnosticism

[JasonBunting]

-----
NOTE: Continued from an off-topic conversation that took place within
this thread: http://groups.google.com/group/knockoutjs/browse_thread/thread/4b637817193799fb
- relevant details are included here, however, and I would love to
hear from others about this topic.
-----

On Jun 23, 6:02 pm, Mark Bradley <barkmad...@gmail.com> wrote:
>
> On Fri, Jun 24, 2011 at 1:46 AM, JasonBunting <jason.bunt...@gmail.com> wrote:
>
> > Off-topic, I would like to see all of the jQuery-aware code (hopefully
> > it's not aware of others as well, e.g. Dojo) removed from the core of
> > Knockout and moved into, perhaps, a compatibility file. Ditto on the
> > templating, if possible. The more this thing can be cut down the
> > better, right? Tell me I'm smoking crack if any of this sounds
> > crazy... If not, I may even be willing to help work on these things,
> > if needed. I just don't see why it can't be broken out a bit better to
> > make it as lean as possible.
>
> From what I understand of the code base, the only thing requiring
> knockout to use jquery (all the jquery specific code is protected by
> checks for its existence) is the template binding which you don't have
> to use (I also believe someone attempted to get knockout working with
> mustache earlier in the year).
>
> --
> -barkmadley
> sent from an internet enabled device

Partially, it's those checks I am referring to, though there is more -
including the template binding "which [no one has] to use."

I realize I am nitpicking (but sometimes it is worth looking into),
but from a quick calculation, based on knockout-1.2.1.debug.js, the
jQuery-specific stuff amounts to almost 10% of the uncompressed code.
I guess that's not a big deal with regards to size, I'm more
interested in the fact that the code isn't completely agnostic about
jQuery's existence. (What? You mean there are people that don't use
jQuery?!?! Heretics!!!)

Just a few quick examples - the following comments are in the code
base:

// For click events on checkboxes, jQuery interferes with the
event handling in an awkward way:
// it toggles the element checked state *after* the click event
handlers run, whereas native
// click events toggle the checked state *before* the event
handler.
// Fix this by intecepting the handler and applying the correct
checkedness before it runs.

What if Dojo, MochiKit, YUI, etc. "interferes with the event handling
in an awkward way?" Should Knockout provide checks for those as well?
Why not? There are a few other places where jQuery apparently does
things that Knockout is trying to be "pro-active" about working
around, but why? What if I am not using jQuery? Why should I have the
extra baggage of that code?

On the other hand, we have comments like this, too:

// Based on jQuery's "clean" function, but only accounting for
table-related elements.
// If you have referenced jQuery, this won't be used anyway - KO
will use jQuery's "clean" function directly

Apparently, jQuery has some nice utilities/constructs that Knockout
can leverage if available, which means the code that "won't be used
anyway" just became additional baggage. Well, what if other libraries
do the same? Should we have checks for those, as well? Why not?

It seems to me that Knockout can have its cake and eat it, too, if
both of these scenarios are planned for by the code base. At least
with the scenario where an external library may very well have better
abilities than Knockout, it could provide a hook such that a separate
adapter/compatibility layer, of sorts, could be used with each type of
external library, if desired.

[Stacey Thornton]

I get what you are saying - I really do. You feel that it isn't fair
to have to include the jQuery library in your files to use Knockout,
because you want to use MooTools or Dojo.

I think the thing that needs to be examined is whether or not the
optimization from what jQuery provides is big enough to warrant any
investigation. Unless jQuery is colliding with MooTools - which from
my understanding, it shouldn't, due to the nature of how jQuery is
established to be under its own namespace, then you're not really
losing anything except a few KB over the wire.

But I really don't think it is fair to ask the developer to manage a
version of Knockout for every conceivable javascript framework out
there. He chose jQuery, and that is his right.

[Peter S]

I agree with you to an extent. Although I use jQuery in my project
currently, I'm a bit uncomfortable that taking it away may affect
Knockout functionality, I think it would be nicer if ko took a more
agnostic approach to it.
I've found from my own testing that removing jQuery event handling
from Knockout increases its performance significantly, but there were
subtle differences in functionality too. I'm also a bit unclear what
the advantage of utilizing jQuery is; if ko has its own 'clean'
function, what advantage is there of using the jQuery one, are people
not using jQuery missing out? I'd like to see the connection between
ko and jQuery made more explicit and configurable at least.

Having said that jQuery is pretty much ubiquitous these days so if
you're going to use another library, it makes sense for it to be that
one.

On Jun 24, 7:02 pm, JasonBunting <jason.bunt...@gmail.com> wrote:
> -----
> NOTE: Continued from an off-topic conversation that took place within

> this thread:http://groups.google.com/group/knockoutjs/browse_thread/thread/4b6378...

[JasonBunting]

On Jun 25, 8:40 am, Stacey Thornton <stacey.cielia.l...@gmail.com>
wrote:

> I get what you are saying - I really do. You feel that it isn't fair
> to have to include the jQuery library in your files to use Knockout,
> because you want to use MooTools or Dojo.

I don't know if it was the way I wrote my post, but this is not, at
all, what I was getting at. First off, you _don't_ have to include
jQuery to use Knockout - not sure where you picked that idea up,
because that's not the case. "Fair" has nothing to do with any of what
I was saying. I am simply referring to good software engineering
practices - libraries that can, should be completely agnostic about
other libraries; KO can, but isn't.

On Jun 25, 8:40 am, Stacey Thornton <stacey.cielia.l...@gmail.com>
wrote:

> I think the thing that needs to be examined is whether or not the
> optimization from what jQuery provides is big enough to warrant any
> investigation. Unless jQuery is colliding with MooTools - which from
> my understanding, it shouldn't, due to the nature of how jQuery is
> established to be under its own namespace, then you're not really
> losing anything except a few KB over the wire.

Again, this is more than just sending "a few KB over the wire," my
questions/comments/etc. also have to do with the fact that, for those
using libraries other than jQuery, why not provide hooks for the
functions of those libraries to provide similar utility to KO that
jQuery does _when jQuery is also present_. Make sense?

> But I really don't think it is fair to ask the developer to manage a
> version of Knockout for every conceivable javascript framework out
> there. He chose jQuery, and that is his right.

I think you've missed the point and perhaps don't understand that
jQuery, again, _isn't_ required to use KO - in fact, the homepage for
KO states:

* Pure JavaScript — works with any web framework

Thus my question about having _any_ reference within the code of KO to
a specific library. Such references should be separated out. And I
never said the developer needed to manage different versions of KO; in
fact, the developer would need to manage less code once the changes I
suggested are in place, since that would remove any reference to
jQuery from KO's code base.

Jason

[JasonBunting]

On Jun 27, 3:32 am, Peter S <peter.sutcli...@gmail.com> wrote:
<snip/>

> Having said that jQuery is pretty much ubiquitous these days so if
> you're going to use another library, it makes sense for it to be that
> one.

That's a decision that should be made by the consumer of KO, not the
developer - why not make KO's functionality useful for more than just
the jQuery community? Because the developer claims that KO is "Pure
JavaScript," he apparently _wants_ to appeal to more than the jQuery
community, but having references in KO to jQuery makes it less than
"pure."

Just as an example, Sizzle.js, which is the CSS3-compatible selector
engine that now drives jQuery, was created/developed by John Resig
(the original creator/developer of jQuery) - on the website for
Sizzle.js, you can read the following about that library at the very
top of the page:

A pure-JavaScript CSS selector engine designed to be easily
dropped in to a host library.

Sound familiar? However, if you search the source code of Sizzle.js,
you will see absolutely no references to jQuery - not one.

Thanks for the feedback!
Jason

[Andrew Booth]

Hi Jason

I get a feeling that some refactoring and simplification could be coming in the medium term. If an observable.js is separated out, and work is completed on jQuery Templates transitioning to rendering to strings rather than dom elements, perhaps some of the issues you raise will be revisited. 

The key is jQuery is not required. Aside from templating, it's used in select places where cross browser dom and event manipulation can benefit. That's a very pragmatic approach, and particularly works cleanly in a dynamic language like javascript.

Plus it lowers the barrier to entry if there isn't the requirement for a separate ko-jquery-adapter.js type file, it's already in there if jQuery is available. I can remember when using the likes of ExtJs and some WYSIWYG editor libraries a while back. Adapters for the different dom selector libraries, or custom builds, make it harder to get started.

Andy

[Stacey Thornton]

> I don't know if it was the way I wrote my post, but this is not, at
> all, what I was getting at. First off, you _don't_ have to include
> jQuery to use Knockout - not sure where you picked that idea up,
> because that's not the case. "Fair" has nothing to do with any of what
> I was saying. I am simply referring to good software engineering
> practices - libraries that can, should be completely agnostic about
> other libraries; KO can, but isn't.

That's fair. I'm not an expert. I just always run jQuery, I never
really thought about trying to run Knockout without it on the page.

> Again, this is more than just sending "a few KB over the wire," my
> questions/comments/etc. also have to do with the fact that, for those
> using libraries other than jQuery, why not provide hooks for the
> functions of those libraries to provide similar utility to KO that
> jQuery does _when jQuery is also present_. Make sense?

Again, this is a pretty fair rebuttal. I would argue that unless it
is
affecting your own development, it should not matter. jQuery has
provided ways for Knockout to apparently optimize some of what it
does. And unless I am just outright misreading things here, it is
doing a good job at it, and taking that away impacted the performance
for those who tried it. Again, I am an amateur, so perhaps I just do
not grasp the purpose behind this 'agnostic' approach, but it seems
to
me that re-inventing the wheel is what componentization and standards
is all about. jQuery did something right. Knockout used what they did
right for its own purposes. I thought this was our goal as
developers,
to keep building. The only conceivable reason I could see a 'desire'
to unhook it from jQuery is if anyone had a doubt that jQuery would
stay around and continue forward development. But like I said,
perhaps
you just see a much larger picture than me.

> I think you've missed the point and perhaps don't understand that
> jQuery, again, _isn't_ required to use KO - in fact, the homepage for
> KO states:
> * Pure JavaScript — works with any web framework
> Thus my question about having _any_ reference within the code of KO to
> a specific library. Such references should be separated out. And I
> never said the developer needed to manage different versions of KO; in
> fact, the developer would need to manage less code once the changes I
> suggested are in place, since that would remove any reference to
> jQuery from KO's code base.
> Jason

Yeah, again, that's fair. I think I did miss your point. I'll happily
concede to that. I will ask this much though - are the ways that
jQuery is utilized wise implementations of it, or just there because
they are there? I mean, sometimes a cigar is just a cigar. There are
only so many ways to write the same thing over and over, and
predictability breeds familiarity.

You're obviously light years beyond me in terms of Javascript
comprehension and understanding, since you're able to browse the
knockout source code and grasp it. I can't do that. I read
that .debug.js file and my mind turns to chicken nuggets, so I won't
attempt a futile debate about the mechanics in a battle I very
clearly
can't win. But I am a programmer, and I do have my own specific
strengths, and I do know enough to know that re-using a good idea is
not a bad thing.

> Sound familiar? However, if you search the source code of Sizzle.js,
> you will see absolutely no references to jQuery - not one.

I'll agree with you that this is interesting, but I think this is an
unfair comparison. You are comparing two works by the same creator
and
stating inter-operability and compatibility without coupling
dependency. That's great. That's every programmers dream. That's also
much easier to do when you're the founding creator of both projects.

When you have a firm 'say' in how things are made, you can ensure
certain levels of consistency that do not force you to break away
from
the standards you are implementing.

I think a project that wasn't done
by John Resig would be a much more fair comparison.

[Peter S]

> Sound familiar? However, if you search the source code of Sizzle.js,
> you will see absolutely no references to jQuery - not one.

Well of course not because the dependency goes the other way. You
might as well say if you look in the jQuery source code you won't see
any references to Knockout in there. You will find plenty of
references to Sizzle in the jQuery code though because the entire
library (as far as I can tell) has been C&P'd in.

Still, as I'm largely in agreement with you there doesn't seem to be
much point in arguing the point further.

@Stacey
If the point you made about performance was related to what I wrote,
then I found that jQuery makes Knockout slower, not faster.

[JasonBunting]

My point about Sizzle wasn't that it didn't reference jQuery, per se, so much as the fact that it's completely agnostic about any JavaScript framework/toolkit/etc. and as such as more rights to the "pure JavaScript" claim than KO does.

:)

"C&P'd in?" Not familiar with this abbreviation...

[Mark Bradley]

On Thu, Jun 30, 2011 at 1:25 AM, JasonBunting <jason....@gmail.com> wrote:
> My point about Sizzle wasn't that it didn't reference jQuery, per se, so
> much as the fact that it's completely agnostic about any JavaScript
> framework/toolkit/etc. and as such as more rights to the "pure JavaScript"
> claim than KO does.
>
> :)
>
> "C&P'd in?" Not familiar with this abbreviation...

copied and pasted in

>
>
>
> On Tuesday, June 28, 2011 8:54:07 AM UTC-6, Peter S wrote:
>>
>> > Sound familiar? However, if you search the source code of Sizzle.js,
>> > you will see absolutely no references to jQuery - not one.
>>
>> Well of course not because the dependency goes the other way. You
>> might as well say if you look in the jQuery source code you won't see
>> any references to Knockout in there. You will find plenty of
>> references to Sizzle in the jQuery code though because the entire
>> library (as far as I can tell) has been C&P'd in.
>>
>> Still, as I'm largely in agreement with you there doesn't seem to be
>> much point in arguing the point further.
>>
>> @Stacey
>> If the point you made about performance was related to what I wrote,
>> then I found that jQuery makes Knockout slower, not faster.

--

-barkmadley
sent from an internet enabled device

http://barkmadley.com