JavaScript Reusability Is A Quagmire | Hacker News Reader

JavaScript Reusability Is A Quagmire

kirindave.tumblr.com

10 pointsabhay7 comments

It's a mistake to lump jQuery in with Prototype and MooTools as "doing things significantly differently and only sorta playing nice with each other". jQuery very deliberately avoids modifying built-in objects to ensure compatibility with other libraries and existing code.

Except that it's really not any better. In any case you're going to have to have another library doing the same damn thing with its own instantiation and calling conventions.

Just because it doesn't deliberately destroy compatiblity doesn't mean that it's really helping the problem.

I'm not sure why this comment was down-modded. You may disagree with the first point, and it's certainly subjective (whether or not grouping the 3 is a mistake), but the second point is 100% correct -- it's one of jQuery's primary goals.

http://docs.jquery.com/Using_jQuery_with_Other_Libraries

And my reaction thus far has been one of shock. “JavaScript: The Good Parts” details four distinct ways to do OO, all of which can be found in the wild. Literally half the book is an apology for the other half, “This is awful, but hey first-class functions are swell!”

I thought the exact same thing when reading "JavaScript: The Good Parts". People often say you shouldn't try emulate classical inheritance with JavaScript, but the fact is every JS library does it to some extent, and each one does it differently. It's hard to keep track of the syntax and semantics for each version.

JavaScript really isn't that bad. It is different to be sure and lost when it comes to OO. But like "The Good Parts" book explains, JavaScript really isn't about OO. Or strong typing. It doesn't need to be. It would be nice if the certain features worked correctly and it worked the same in all browsers, but I'd rather have less features and not more. With closure and first class functions you can get most of what you need once you learn a basic model for building apps.

I feel like this is excuse making. It's not like changing javascript is outside of our capabilities.

Scheme is really similar to JavaScript in that it is an extremely basic set of core functionality, but they've gone to great lengths to make the experience of using it consistent. Part of the problem is that most of schemes are written in scheme, but most javascripts are not written mostly in JavaScript. That means there is no style guide implicit in the source code. If a bunch of code just picked an object instantiation method, then there would be no problem.

"JavaScript really isn't about OO. Or strong typing. It doesn't need to be."

Yet, ECMAScript 4

Reply on news.ycombinator.com