Have `contains` as an alias for `has`

[Raynos]

Have `contains` as an alias for `has`

[rauchg]

Not sure what TJ had in mind but I think by fallback he probably meant using the API internally.

I personally think that shimming DOM APIs is not a good idea as a general rule. They're often awful, which is why Google Dart is exciting as far as starting over with the DOM APIs. It's like shimming getElementsByClassName for IE6.

If you're writing a selector engine, you probably want to leverage the API if it exists for speed reasons, but you don't want to expose it to the user.

Similarly (although not as extreme), I very much prefer to write classes.has() vs classes.contains(). It wouldn't hurt to add an alias, but I certainly wouldn't document it as an alternative.

[Raynos]

The only reason .contains should exist is that it's suprising / confusing that it doesn't exist given that classList was mentioned in the description.

As for shimming the DOM API. I agree it's bad in the sense that classList.js is bad by extending host objects.

Following the DOM API is good for readability and being able to understand a module. Just like matching the database API is a good thing when your writing a database client. Having a one to one mapping means it's obvouis what the module does and it also makes it really easy to find cross browser alternative to what you know exists natively in modern browsers.

Then again this module is either one of two things

• yet another arbitary className abstraction
• a cross browser implementation of classList that does not extend host objects or do anything else unsafe.

As for the Dart comment. Dart has gone too far the other way and has made the mistake of copying the confusing / non-descriptive names from jQuery.

I do agree the DOM is too verbose. But we need both types of libraries, low level cross browser implementations that are spec compliant and whatever high level abstraction your personally like the best.

The main purpose for the former is to allow everyone to write whatever high level abstraction they want without re-inventing the browser support wheel over and over and over.

And if I'm writing a query selector it's going to expose two methods, querySelector and querySelectorAll. If you don't like those names then simply do var yourShortName = require("query-engine").querySelectorAll. I wouldn't get involved in what's the best non-descriptive short name bikesheddery and simply stick to the real name. It has the added benefit of implying it's spec compliant (and it should be if you write it)

[Raynos]

But now that I've actually inspected the source code. It's nowhere near spec compliant, so I should just treat this as yet another className abstraction rather then try and shoe horn it into a cross browser classList implementation.

[rauchg]

Yeah, thankfully it wasn't called classlist cause that would be really confusing haha. To your point of the "surprising / confusing", that's why I suggested an undocumented alias.

[rauchg]

I do agree the DOM is too verbose. But we need both types of libraries, low level cross browser implementations that are spec compliant and whatever high level abstraction your personally like the best.

Yep that's the way to go. We would have a classlist API-compatible component, and then the classes "sugar" component. But it sounds like overkill maybe.

[Raynos]

@guille it's only overkill if no-one ever used classList directly.

In fact I'm writing classList as a module because that's the API I want to personally consume. Being the good open source citizen I am you can build whatever ever classes sugar component you want on my performant cross browser base.

The only downside is that I don't do the whole component.json so I don't know what the current component strategy is for re-using modules from npm.

[rauchg]

Awesome. All it takes is to just add that one file to your module.

[Raynos]

@guille that doesn't work. Because then AMD comes along and says all it takes is this 5 line boilerplate. And them JAM comes along and says all it takes is just one file. And then ender comes along and says all it takes is just one file.

etc, etc, etc.

[tj]

yeah it's definitely not supposed to match the regular .classList api, I'll document that so it's clear. I agree though, packages suck ATM, there's no clear winner, maybe there never will be, I also dislike that issue but at the moment it seems like we have to go with what seems most logical for each of us and ignore the rest of the stuff for now haha. I've rigged component build with a few flags for outputting regular globals that people can use etc, but I'm definitely done writing that code directly

[tj]

I haven't benchmarked, it might make zero sense to even utilize classList when available, I would hope it would be faster but who knows

[Raynos]

@visionmedia classList is slow. If you care about performance don't use it.

have to go with what seems most logical for each of us and ignore the rest of the stuff for now

But that's a pain. I'd really want to use your stuff. It's moving me away from using your stuff because I'd rather invest effort into just doing it myself then figure out how to bridge components and npm.

[tj]

jsperf shows it's several orders of magnitude faster than jquery's

[tj]

well we're not going to be using npm :p sorry!

[jkroso]

@Raynos I actually wrote a bridge for component and npm. The interface I use for it at the moment is bigfile but it sucks and will be replaced with something like folio. The guts of the tool is in the dependency resolver though and that's promising. Actually @visionmedia might be interested too.

[Raynos]

@jkroso nice idea, but not worth the pain. I'd rather just deal with npm instead.

[tj]

likewise but not dealing with npm

[jkroso]

The idea I was trying to push when I wrote Sourcegraph was to use urls or paths in the require calls which would unbind you from any particular package manager (npm and component were just tacked on). This leaves you with verbose paths but I see that as a problem for text editors and IDE's to deal with.

[jkroso]

I should probably explain I mean the visual problem of verbose paths not the typing problem. Which is the problem with npm that the component system was designed to solve I've thought.

[tj]

not sure I follow, what's this about verbose paths? the editor experience with components is pretty much the same as without

[jkroso]

with npm a namespace looks like component-classes. The ultimate verbose namespace is https://github.com/component/classes/master/index.js ( if you don't mind looking at a url as a namespace) which is what I would actually like to use. The main benefit of using component that I see (aside from the build tool) is in the hiding of the namespaces. Otherwise npm looks workable to me.

[jkroso]

Come to think of it component could hide npm namespaces just as easily as it hides github namespaces so I'm obviously on the wrong track.
What was the main reason you built component completely separate from npm?

[Raynos]

Because inventing wheels is fun.

[tj]

@jkroso lots of reasons, most are in the FAQ, npm is not magically some flawless thing, package management is a very simple problem, just because someone else decides to take a different approach doesn't invalidate it. We're trying to get away from it even for node stuff the caching layer has tons of bugs and the code is impossible to contribute to. If you're going out of your way to auto-namespace within npm, why not just get rid of a bunch of npm codesmell like implicit origins (repo prop etc that no one uses) and make the whole thing an overall better experience, nicer search, nicer installs, faster, less magic etc. When you proxy to npm what else do you get? a slower transfer mechanism? no thanks, an extra credential system to go through? no thanks, extra publishing steps? no thanks

[jkroso]

Yea I knew component had advantages but I haven't been able to see why npm modules had to be cut off. I guess they don't right? Are you happy to let the component tool get more complex in order to support npm modules?

[tj]

no I dont want that, it's easy to just use npm's newer support for user/repo syntax and call it a day, future projects have no choice but to use that feature anyway, 99.9999% of reasonable names are taken already

[Raynos]

@visionmedia the name isn't important, it's the version that's important. I don't want to have "name": "visionmedia/classes"

I want "visionmedia/classes": "~0.2.3"

[tj]

sure that's lame too, I'm sure he could adjust that

[Raynos]

@visionmedia that's not the point, I don't care about the name or how ugly it is. You can prefix all your modules with visionmedia/ on npm.

The point is npm is good because it manages versions.

If your package manager doesn't manage versions then it's useless.

[tj]

no that's stupid lol ours does manage versions just fine, I have a few things left to implement but that's besides the point, keep your fanboyism to yourself please. If you're going to "wrap" npm by just auto-prefixing everything else you might as well fix all the other stuff and get rid of the cache headaches etc

[Raynos]

@visionmedia

searching for "version" and "semver" on https://github.com/component/component and https://github.com/component/component/wiki/F.A.Q or any other page I can find returns nothing of value.

Nothing mentions how I can load a module in a semver version range using component

Please document that or people will assume you don't do it.

[tj]

the entire project is only a few months old dont worry, it'll get there

[Raynos]

So it doesn't currently manage versions. Ok, cool.

[tj]

just a limited subset of the semver stuff though honestly I'll probably leave out a lot of npm's stuff I dont find them useful at all beyond 1.x etc, and if we implement ~ we'll do it the correct way

[Raynos]

what's the correct way?

[jkroso]

would you mind pointing me to something about npm's new user/repo syntax; I couldn't find anything.

[Raynos]

@jkroso you tell @isaacs to document this feature better.

[jkroso]

Haha I'd say he probably wants to bury that feature going of one of the old issue threads I read

[tj]

@Raynos it may have been fixed recently im not sure, it was comparing minor not major, and since npm doesn't traverse bundledDependencies we've pretty much written our own in-house npm to get around it haha

@jkroso i dont think so it's pretty new (month or so?)

[isaacs]

What feature needs documentation?

@visionmedia What "cache headaches" are you talking about? Is there a bug you can point to? If not, your comments here smell kinda fuddy to me.

Whats the "correct" way to implement ~?

[jkroso]

@isaacs the one talked about here *edited

[Raynos]

@isaacs Raynos/testem being an alias for git://github.com/Raynos/testem isn't mentioned in https://npmjs.org/doc/install.html

[tj]

@isaacs I mentioned the ~ thing to you before, about how it was comparing minor not major. I mentioned a few of the cache issues bit I remember you couldn't reproduce them, I still need to dive into that deeper to figure out what's going on, we usually just blow the cache each time we change something to avoid all of that. The biggest show stopper for us right now is how it wont traverse bundledDependencies to install their deps, but we've written our own thing on top of npm to hack it in a bit