MooTools: The Open Source Magic Behind Cloudera Desktop UI | Hacker News Reader

MooTools: The Open Source Magic Behind Cloudera Desktop UI

cloudera.com

11 pointsyarapavan9 comments

Further to what vicaya said, when you are building a huge system like Cloudera, you should invest extra time/$$$ and write your own library.

Crockford wasn't joking when he called javascript the most misunderstood language. A lot of libraries have really bad code- Its a huge risk to take to build an entire system on top of the library, without properly understanding the kind of code you are dealing with. The number of Javascript experts that haven`t gone through the EcmaScript specs is probably upwards of 99% (I only guess, ofcourse, based on the "advanced" code that I have seen).

Seeing as a lot of people prefer jQuery, and not wanting to get into a debate of its usefulness, the point is simply this: When writing a huge system, crank out your own library. 2k-4k lines wont take that long to write. Take a week out, decide what your specific app needs, and then write a library to handle those needs. If its a small site, or one that will run on a specific set of browsers in a contained environment, a library will do fine.

I disagree in full.

There's much more than 2k-4k lines in a good javascript library. You've got years of bug fixing/perfomance improving and months of fixing browser bugs.

For example, try writing your own css selection framework and I guarantee it to be slower ones in prototype/jquery/mootools no matter what. If not in one browser then in another.

You might want to modify your library, but you shouldn't start with bare hands for sure!

Any reasons why they picked MooTools instead of JQuery? MooTools is a Prototype derivative. Prototype derivatives are huge pains, as they litter the global namespace like they own it, which makes sane mashup implementations practically impossible.

I hate Prototype and its ilks with a passion.

http://jqueryvsmootools.com

Well, the facts mentioned in the post just confirms my judgment why MooTools/Prototype are bad: monkey-patching existing objects and polluting global namespace like no tomorrow, all in the name of object-orientation in a perfectly capable language that's prototype based and functional.

Sorry, but we do want to use actual useful objects (including built-in types) no matter what you'd say.

It's viable, it's useful, it's done, it works.

That's a fine reason, as long as you don't care about being friendly for integration/customization/embedding with external sources.

Should I?

If you can't be bothered to author your code using only ONE JavaScript library, then yes, name space "pollution" is not very friendly. But if you write all your code using one framework, then the name space is yours to use, which to me is not pollution. It's only a pain when you want to use several frameworks, and the only reason I can imagine to to do that is to use plugins from more than one. That's laziness if you ask me; rather than ask your users to download two libraries, you should author your own version for your framework of choice.

Reply on news.ycombinator.com