MooTools: The Open Source Magic Behind Cloudera Desktop UI(cloudera.com)
cloudera.com
MooTools: The Open Source Magic Behind Cloudera Desktop UI
http://www.cloudera.com/blog/2009/10/19/cloudera-desktop-and-mootools/
2 comments
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!
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.
I hate Prototype and its ilks with a passion.
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.
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.
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.
It's viable, it's useful, it's done, it works.
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.