Bindable without jQuery

[mkitt]

We talked briefly about this yesterday, but it would be super handy to have a version of bindable that works without jQuery using only native JavaScript. The challenge here is storing the registry, which @gvarela has more insight on. Not a high priority, but would be really handy for those projects that only require a little bit of JavaScript and doesn't necessarily need jQuery involved.

[jedschneider]

it would also complicate how we expect to be able to handle @el within the constructor. we probably have a lot of code right now that depends on that acting like a jquery object

Jed Schneider

"I invented the term 'Object-Oriented', and I can tell you I did not have C++ in mind."

• Alan Kay

On Saturday, May 4, 2013 at 5:08 PM, Matthew Kitt wrote:

We talked briefly about this yesterday, but it would be super handy to have a version of bindable that works without jQuery using only native JavaScript. The challenge here is storing the registry, which @gvarela (https://github.com/gvarela) has more insight on. Not a high priority, but would be really handy for those projects that only require a little bit of JavaScript and doesn't necessarily need jQuery involved.

—
Reply to this email directly or view it on GitHub (#2).

[mkitt]

Yep, that's why I think there are two separate files. One with jQuery and one without. It's a decision that's made at the start of a project on which one we are using.

[jayzes]

Theoretically, we could detect the presence of $ and wrap the element if it's present, otherwise don't.

[mkitt]

Okay took an initial stab at this thing including the storage of the instance back on the element.

I'll need to test this with a few browsers first, but I imagine there are some problems with storing the instance back on the @el, mainly with IE. IE (even 10 🐼) doesn't support the dataset property which is where data- attributes typically reside. There is a good article on HTML5 Doctor about the dataset property. I'll test this out some on various browsers and see about alternatives when the dataset property doesn't exist.

@gvarela, I'll defer to you on the instance storage within the @el, since this is your baby.

Also, need to do some trickery around the naming of the instanceKey for this to work right. The regex is pretty basic and probably needs to be tuned a bit.

I wrote it in plain old JavaScript. If we are going to distribute this thing as from the discussion in #1, it's probably a better idea for the distributed source to be native and not just the output from CoffeeScript. Lots of haters out there who'll reject it based on just that notion. Stupid yes. I do think we should have the CoffeeScript examples either right next to them, or in another branch, but I'm cool either way.

[gvarela]

The instance storage is to prevent accidental double binding as well as make it easy to access the instance should you need a reference to manipulate it in some way. As long as the way you implemented it handles those scenarios I would call it good.

[mkitt]

Yeah it's just...

if (!el[this.instanceKey]) {
  el[this.instanceKey] = new _class(el)
}

[gvarela]

Yeah saw that. Since I don't know the modern way to do that I just wanted communicate the intent.

[jedschneider]

I kinda feel like we shouldn't be apologetic about releasing it as coffeescript. I had a chat with a friend of mine that is really into node development and he said the same thing, he stopped writing coffeescript because he couldn't get other node developers to work with him on it. I think that is a really sad reflection of that community. I think we should be more like

> 'our core use case is coffeescript, and that fits into the rails pipeline well but if you want to use it as a vendored library to augment how you write javascript, thats great, heres a file you can use.'  

I dont know, is that too hardline?

Jed Schneider

"I invented the term 'Object-Oriented', and I can tell you I did not have C++ in mind."

• Alan Kay

On Thursday, May 9, 2013 at 11:59 AM, Gabe Varela wrote:

Yeah saw that. Since I don't know the modern way to do that I just wanted communicate the intent.

—
Reply to this email directly or view it on GitHub (#2 (comment)).

[gvarela]

I think for a library this small it should be js. There isn't really an advantage when there is this little code.

[jedschneider]

so, @mkitt I think we are good to close this issue, right?