MooTools: The Open Source Magic Behind Cloudera Desktop UI
1–10 of 10 posts
Re: MooTools: The Open Source Magic Behind Cloudera Desktop UI
#2Any 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.
Re: MooTools: The Open Source Magic Behind Cloudera Desktop UI
#3Any 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.
Re: MooTools: The Open Source Magic Behind Cloudera Desktop UI
#4Any 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.
Re: MooTools: The Open Source Magic Behind Cloudera Desktop UI
#5Further 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.
Re: MooTools: The Open Source Magic Behind Cloudera Desktop UI
#6Further 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 o…
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!
Re: MooTools: The Open Source Magic Behind Cloudera Desktop UI
#7Earlier quoted context omitted.
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.
Re: MooTools: The Open Source Magic Behind Cloudera Desktop UI
#8Earlier quoted context omitted.
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.
Re: MooTools: The Open Source Magic Behind Cloudera Desktop UI
#9Earlier quoted context omitted.
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.
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.
Re: MooTools: The Open Source Magic Behind Cloudera Desktop UI
#10Earlier quoted context omitted.
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?