
How MooTools was built - hulkaad
https://betweenthewires.org/between-the-wires-mootools-7ac80d4ca28f#.tsiemucc9
======
herbst
Amazing that it have only been 10 years. I remember when i learned and focused
on mootools because jquery seemed just so far away from actual js while eating
away, then valueable, performance.

~~~
orthecreedence
Agreed, and I still prefer Moo for my own projects because of how it extends
javascript instead of replacing it (like jquery does).

Back when I was learning javascript (2006/2007) it seemed like Mootools was
for people who had a good grasp on the language and wanted more from it. I
appreciated this, and still think it's better at this than jquery.

I wish Moo had gotten more attention over the years. I get why jquery has done
so well, but I don't like its methods.

~~~
kedean
I still maintain that MooTools was the superior system over jQuery.

jQuery won the war, in the end, because it catered to the 'get it up and
running now' crowd over the 'do it right' crowd. It was always easier to
understand off the bat, especially if you aren't a trained developer, while
MooTools makes for a more long lasting, quality codebase.

~~~
dandersh
No jQuery won the war because it fit with what JavaScript does in the browser
while MooTools lost because it was part of the Java/OOP fad of "Well it has a
new keyword so let's extend classes with it!" that has (thankfully) been
rendered to the dustbin of history where it belongs.

------
emehrkay
I still love MooTools. It should be where jQuery is with regard to mindshare.
A lot of people didn't like the fact that it extended globals, but whatever it
works well and you can easily build very complex systems with the class
structure. I made this object pool using MooTools as an example on how to
reuse instantiated objects
[http://jsfiddle.net/XkTPJ/](http://jsfiddle.net/XkTPJ/)

~~~
oelmekki
I told myself recently that it's actually mootools who won. Most cool stuff
mootools does on natives is now standard since ES5/6 - either in the exact
same form or something similar. On the contrary, jQuery is consistently losing
ground in favor of "vanilla js" (that is, babel, really).

Even if most frontend devs didn't use mootools, the way they code nowadays is
very similar to what mootools was pushing for. This biggest difference I see
being that we still don't have animations and requests as objects that can be
reused (but css animations are probably more performant, and fetch +
async/await is cooler).

------
vcarl
I didn't realize that so many of the React team had worked together, let alone
on a project as well known as MooTools. Some of their answers mirror my
perception of React, especially:

    
    
        We were so focused on the API design, rather than building
        something that people could actually use and adopt.
    

It's good that they found more people who shared their ideals and a company
willing to give them the time to implement them.

------
erikrothoff
Gaah this brings me back! Mootools was how I initially learned Javascript. The
Mootools source was so brilliantly written and well structured that it was
breeze to follow. I learned a lot about advanced topics like animations,
events and a lot of functional style programming. Learning jQuery afterwards
was such a disappointment, and just seemed like a big hobbled mess of
procedural style code.

------
alexdoma
I remember the days when MooTools was hot^H^H^H^H useful enough to be bundled
in Joomla.

Learning JavaScript while fiddling with it was really fun in 2009 when I was
about to graduate from high school. Aaron Newton's jqueryvsmootools was an eye
opener when I first read it and David Walsh's blog was really helpful in the
early days.

I still like to follow some of its contributors (mainly Dimitar Christoff and
Chris Pojer).

------
maxpert
Mootools have been my all time fav for really really long time and I always
believed it will beat jQuery somewhere in future (which unfortunately never
happened) but I am glad to see pieces coming together in React and see so many
people from the team working on another project which not only picked up but
swiped away most state of art projects.

------
carise
This brought back a lot of (good) memories for me. I was new to Javascript and
picked up MooTools to help me with my first big project at work. Really glad
to find out that a lot of the MooTools devs work on React now!

------
niftich
Wow, this takes me way back -- but that 'way back' was only 10 years ago. So
much has changed in that span of time, it's mindboggling.

Around the time that MooTools appeared, Prototype and Dojo were the cutting-
edge of DHTML, freshly made cool again by the term 'Ajax'. Prototype was very
much a series of ugly hacks driven by the get-shit-done monkeypatching
mentality of Rails, but it was fantastic. Meanwhile Dojo was fast-sprawling
ecosystem of community and corportate contributions and plugins and whatnot,
backed by a non-profit Foundation, and supported by major companies like IBM
and Sun -- I can't firsthand speak to its quality (some have said it was quite
good), but the contrast was night and day.

Script.aculo.us emerged built on top of Prototype to add tasteful
interactivity (like DOM element dragging), and its branding targeted style-
conscious developer-designers (the sort who'd read CSS Zen Garden but were
tempted by JS). As the MooTools team noted, the weaknesses of Prototype
started to show as its capabilities were pushed -- and it was getting kinda
big. It was into this landscape that jQuery, Moo.fx, and MooTools arrived, and
the rest is now ancient history.

There were many things that set jQuery and MooTools apart, but a notable one
was their differring philosophies on extending native JS objects, or in
contemporary parlance "extending the DOM". jQuery specifically didn't do this,
while MooTools followed in the vein of Prototype and actually extended more
builtins. Over time, this particular debate went from an implementation detail
to a significant issue in the community -- a good example is this blog post
from 2010, and its comment thread [1], to read both supporting and dissenting
attitudes of the time.

I remember these early days of "mainstream Ajax" as being fairly annoying, but
mostly because of browser vendors, and less so because of library authors. But
today, that Ajax JS frameworks have been superseded by MV* JS frameworks, I
actually find fewer substantive articles, blogs, and analyses that talk about
the innards of frameworks and contrasting design decisions than I did back in
those days.

Notwithstanding the issues about framework proliferation, most high-quality
reviews, comparisons, and material is produced by first-parties (especially
the authors of 'underdog' libraries), while very little is produced by the
community. There was a LOT of cargo-culting back in 2007 too -- I know, I was
one of those people -- but there's much more today. Whether this is because
the most engaged people now tend to _contribute_ to projects instead of
blogging about them, or because interest in deeper analysis has declined, I'm
not sure. I miss it sometimes.

[1] [http://perfectionkills.com/whats-wrong-with-extending-the-
do...](http://perfectionkills.com/whats-wrong-with-extending-the-dom/)

------
yellowapple
What's with all the past-tense? MooTools still exists and is going strong.

...right?

------
cmrdporcupine
"Sebastian: My dad used to code C++ games for the Commodore 64,"

Huh?

~~~
sebmarkbage
(I'm "Sebastian".) It meant to read C. It definitely wasn't C++. However, now
I'm curious if I'm confusing it with the later Amiga games. I'll need to look
into this. I was 8 years old at the time. :) Note that this was for hobby
projects many years after the original launch of those products - not
mainstream dev.

~~~
cromwellian
C/C++ was much more common on the Amiga, although even C++ was rare until
later in the Amiga's lifecycle.

