How MooTools was built | Hacker News Reader

How MooTools was built

betweenthewires.org

102 pointshulkaad23 comments

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.

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.

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.

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.

Agreed. It took me a long time to give up on Mootools because it felt like it made so much more sense. jQuery's tendency for chaining felt particularly gross to me - in retrospect I don't think I was wrong, either.

But the sheer number of plugins that depended on jQuery made it's dominance inevitable. Thankfully we're now coming back out the other side.

'Wrong' often reduces something multi-dimensional to the single dimension of right/wrong.

I think you were 'wrong' in the sense that the most common use case then for jQuery or MooTools was better served by jQuery. As in, you were probably not the most common use case.

But I think you were right, especially considering the current reality, in feeling that MooTools made more sense. Because in 'current-day' web development you can't usually get past understanding the level 'below' jQuery and MooTools (plain javascript/DOM). For example, I've never met a React developer who couldn't use the regular DOM API through vanilla js.

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/

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).

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.

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.

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).

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.

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!

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...

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

...right?

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

Huh?

That was before rust, when people still used c++ to program in assembly or basic.

Nice sarcasm. No one used C++ to program the C64. Even C compilers were rare.

Most C64 code was written in 6502 Assembly directly, some was written in Basic or Blitz basic.

I'm interested aswell. I'm only aware of the "Profi-C" c compiler for the c64. Maybe they are lost in ways google can't find these compilers?

Nowadays cc65 exists: https://cc65.github.io/doc/c64.html

(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.

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

Yeah I kinda wondered if the article author messed something up. :-)

Probably your dad was doing C on the Amiga. C on the C64 wasn't really a thing. Nor was C++ on the Amiga, really.

Reply on news.ycombinator.com