MooTools

Introduction

If you were doing web development in 2009, MooTools might very well not need an introduction! MooTools was a well-known JavaScript utility library for building “powerful and flexible code with its elegant, well documented, and coherent APIs”. Its core contributing team was made up of a brilliant set of developers, and we’re lucky today to be speaking with three of them:

Formerly core contributors to MooTools, Sebastian Markbåge, Tom Occhinoand Christoph Pojer are active and vibrant contributors to the Reactcommunity today.

Can you tell us a bit about yourselves and how you each got into programming?

Sebastian: My dad used to code games for the Commodore 64, and I would watch him, and tweak them. I was only ten when I really got into programming. I started programming games and doing small lookup databases through Qbasic for MS-DOS.

Tom: When I first got a computer I was running Windows 3.1, and then Windows 95. I became obsessed with re-skinning windows. I wanted my computer to look different, so I figured out how to resource hack, and change the images. I started with MS Paint and made the buttons different colors. Then, there was this program called WindowBlinds that got me into creating my own skins. Eventually, I discovered HTML. It was so much easier, and better.

Christoph: So, I started programming when I was about 12 trying to learn how to make websites. And then, I think when I was 14 or so, when a friend in middle school was playing a game online and I bet him that I could make it, and make it better. After that, I spent basically every day for four weeks building an online game. It was motivating, building small games that a bunch of people played afterwards.

Interviewer: Interesting! Games seem to be the theme here, especially for people who got into programming early.

Tom: Yeah. You had to edit HTML in a Notepad and make a .html file. There was no syntax highlighting or anything like that. I didn’t know what valid markup was until Netscape came out in the 1990s, like 1997.

 

  Sebastian: Yeah, ’93 is when I started. I started withNetscape 2 I think. CSS didn’t exist at all. HTML existed, but JavaScript was not on the scene yet, so you couldn’t actually program much on the client. You had to do everything server-side. Everything was Perl and CGI.

Tom: You’re a dinosaur.

Going back to the origin, do you know why Valerio started MooTools, and how it got started?

Tom: Valerio always gets frustrated when he sees something that can be done better. He was using Prototype, and more specifically, script.aculo.us. There was a common issue where if you created a click event handler to start an animation, and you clicked it twice, it would start the animation over – basically firing off new animations every time without the ability to choose to either resume, enqueue another, or replace.

It actually wasn’t MooTools that he was creating at first. His whole premise for Moo.fx was just to be able to retain this instance, and be able to do something better than what Script.aculo.uswas doing by default. Prototype was pretty big at the time, so he created prototype.lite.js, which was basically just the class system plus a couple of utilities. Eventually, he built Moo.fx on top of that. It must still exist somewhere today, but that’s how it was born. From Moo.fx, there was a foundation for an alternative – Prototype plus Script.aculo.us – which became MooTools.

 

How did each of you start contributing to MooTools?

Tom: I was creating a photo album app for a photography studio, and we needed a way to sort the photos. At the time, MySpace had a top eight grid. They implemented it as a one-off, and we wanted to build better support for that.

Script.aculo.us had something similar built in, but I basically expanded MooTools’ drag and drop library, and created Sortable.js. I showed it to Valerio, and he decided it should be in the core of MooTools.

Interviewer: How old were you? Since there was no Github back then, how did you even get to the repo?

Christoph: We used Trac and Subversion.

Tom: Gaining access to Trac and Subversion was a big deal. When Valerio asked me to contribute, there were no code reviews. You just checked it in.

Christoph: I had a similar experience as Valerio. I didn’t like Prototype and script.aculo.us. I saw Moo.Fx and then MooTools come out. It was in September of 2006 – I was 16 or 17.

 

I was in my prime teenage years and I was kind of a rebel. I wanted my code to be perfect, and MooTools was just written so perfectly. It was so small but did everything I ever wanted. I was very idealistic.

Tom: Do you remember what your first contributions were? I don’t really remember.

Christoph: I started using it in early 2006 for games. I literally built a German version of Facebook for my friends, even though I didn’t know what Facebook or MySpace were. Then I built some other games with it. I wasn’t contributing much.

I didn’t know English very well, but was trying to learn. I became a core contributor in 2009, almost at the exact time Tom was hired by Facebook. He basically told us to take over after that. That’s when I started contributing to the core, and then we started doing a hack-a-thon in London, where we met up once a year. That was pretty cool.

Sebastian: I came in around the same time as Christoph, but my experience was different. It happened during my second pass into JavaScript. I started with JavaScript in the late ’90s, when it was pretty much useless. Then it had a resurgence around 2005 and I started moving back to the client after having spent five years on the server only. I was looking at all the frameworks, and I needed more help. I wanted to understand more, and MooTools helped me learn how the language worked. It was written in a very clean way, you could study the code base itself, but I was frustrated with some of the details. Unlike these guys, I was actually building pretty complex apps at the time. I was building this complex WYSIWYG editor.

Tom: I was building a CMS. It wasn’t that trivial, come on.

Sebastian: I made a rant on the public mailing list. There were two mailing lists – a private internal list, only for developers, and the public one. On the public list, there was the guy named Aaron Newton, and he was kind of the dad of MooTools. He was the adult because he was actually building startups at the time, and was trying to create a community because he understood the value in that. He spent a lot of time in the public forums helping newcomers, and bringing them into the inner circle. I made these long rants on the public mailing list, and he invited me into the closed circle.

Tom: I think we all started out on the forums. The first step was getting moderator rights on forums – to be able to close topics and answer questions authoritatively. We had little icons next to our names indicating we were moderators. My first contact with Valerio was when he reached out to thank me for helping out with the forums. From that point on, I started contributing to the code.

Christoph: That’s funny because I still have that email. My first interaction with Valerio was not actually about MooTools itself. He had built this bundler or compression thing that I really needed, and there wasn’t really anything else like it. We used to just ship like 30 JavaScript files, and this MooTools website had this bundler where you could concat your files together.

The MooTools builder. So before its time.

Tom: So before its time, man, the MooTools builder. So before its time. You selected the things you wanted, and it created a customized script for you. You would just save the file and put it on your web server. It was amazing.

Sebastian: It was ingenious because there was no common JS.

Tom: There was no nothing. It was all globals.

Sebastian: There was no way to tell from anyone’s code base what modules were required, so you had to check it yourself, but because it was just a website, you could do that easily without trying to get a standard around it.

MooTools has such a distinct and memorable brand around it. What were some of its core values that made it stand out initially, and why do you think people remember it so positively today?

Sebastian: We valued the readability of the code base a lot, because that’s how we learned.

We saw jQuery as the opposite, where everything was inline. There were no reusable abstractions, and they tried to support every use case there was. Ultimately that made the code more difficult to understand and maintain. That’s why we chose not to support as many use cases.

Christoph: It was interesting because we were all very like-minded. We were building something great, but we didn’t do any outreach. We attended maybe 3–5 conferences over the course of seven years. We didn’t really build it for other people. We were trying to build the perfect framework, something that we could use. It might not be the best way to grow an open source project, but we were just our own little community trying to build something perfect.

Sebastian: There was also the chaining. The chaining was very explicit, and everything was designed around readability and grammar – the chaining should mimic an English sentence.

Tom: We constantly iterated to refine and improve the API. One of the guiding principles was that code built on top of MooTools should be readable, easy to understand and easy to extend. We had a very strict style guide in our heads that we all followed. It was almost academic in a sense.

Christoph: I think academic is a really good description. We were so focused on the API design, rather than building something that people could actually use and adopt.

What do you think was the most impactful or important thing that you learned while working on MooTools?

Collaboration, like we said, is really important to create a very tight team – one that shares the same values in terms of how you write code and what you should prioritize. That’s one thing we mastered that allowed us to move forward.

Sebastian: Collaboration, like we said, is really important to create a very tight team – one that shares the same values in terms of how you write code and what you should prioritize. That’s one thing we mastered that allowed us to move forward.

On the other hand, pragmatism is something we didn’t do well, but we’ve since learned.

Christoph: For me, because it was the first open source project I worked on, I learned a lot about being involved in the community and working on open source. That experience can burn you out. People hate on you for making changes to the API that they don’t understand, or you have to deal with people questioning you all the time. But, getting to know the community, meeting people I worked with everyday, that was one of the best things for me.

Tom: For me, learning JavaScript was huge. There was a ton of experimentation, trying to solve problems in a cross-browser way, and I felt like I almost carried too much weight about cross-browser incompatibilities. I feel like I really learned JavaScript and functional programming concepts in a way that I couldn’t in school.

We got hired because we could solve real business problems using JavaScript. JavaScript was looked down on in the beginning, and had stagnated, and had performance problems, but it let us build something productive.

Sebastian: I think that’s a really underestimated point in the last decade. There was a growing community of kids like us with no prior experience, and we got hired because we could solve real business problems using JavaScript. JavaScript was looked down on in the beginning, and had stagnated, and had performance problems, but it let us build something productive.

Meanwhile, there were a lot of academic projects – the common wisdom was that they were going to succeed. That these business tools backed by big enterprises were going to replace JavaScript. But that’s not quite what happened. It goes to show, you have to pay attention to what people are drawn to. They’re drawn to it for a reason.

MooTools was probably one of your first large open source contributions and projects as well. How would you say it impacted your career?

Tom: For me, it was pretty easy, actually. Somebody was organizing a conference in the Netherlands called Fronteers and they used and loved MooTools. So they reached out to Valerio to see if he would speak about MooTools and object-oriented JavaScript. Valerio referred them to me. I was pretty young, in my early 20s, and I had never spoken at a conference. I didn’t really know what I was talking about. I thank my lucky stars everyday that it wasn’t recorded because it was so embarrassing. As a result, though, a recruiter from Facebook contacted me, and said they were trying to do more with JavaScript and asked me to come in for an interview.

Christoph: My story is pretty similar to Tom’s. I also did a public talk. It was really difficult because while I was used to public speaking, I was not used to public speaking in English in a foreign country. I was not as lucky as Tom, my talk is still online. I used to have a really heavy, Austrian, Arnold-Schwarzenegger-like accent.

After the talk, a Facebook recruiter reached out, and I ended up doing an internship at Facebook. Tom was actually my intern manager, so that worked out pretty well. Then, I had to go back to University and finish my degree before I could join Facebook full-time. By the time I came back, there were all these MooTools people like Sebastian working full-time at Facebook.

Sebastian: I was working in Europe. Thomas Aylott was at Cloudera and then worked at Sencha in the Bay Area. He started talking to me about moving out here. At the time, I didn’t wanted to move to California, especially not the Bay Area. But, another MooTools guy referred me to Apple, so I interviewed there. I didn’t really like the attitude of the company. I honestly didn’t think I would move out here at all. Finally, though, Aylott left Sencha and started working for Facebook. After that, he referred me again, so I finally flew out, interviewed, and it had a different vibe. All my MooTools friends were there, so I decided to jump in.

People didn’t understand why I would want to work at Facebook. I had to convince them that we were doing interesting stuff. After a while that was part of what fueled our resurgence into the front-end, open source world. We wanted to share some of the stuff that we were thinking about and working on.

Tom: People didn’t understand why I would want to work at Facebook. I had to convince them that we were doing interesting stuff. After a while that was part of what fueled our resurgence into the front-end, open source world. We wanted to share some of the stuff that we were thinking about and working on. Even after 2011, we were still seen as a PHP company. Hack didn’t come around until 2013.

Christoph: People actually thought we didn’t know JavaScript.

Tom: It’s funny because all of the problems we were solving back then, became the top of our minds two, three years later. Systems like Bootloader and Primer. Primer was the precursor to progressive web apps, and Bootloader was a precursor to bundle splitting. People were solving very different problems than what we were solving at that time.

Can you talk about MooTools 2?

Christoph: Oh, man.

Sebastian: MooTools 2 was a rewrite that was supposed to be even cleaner.

Sebastian: I think the problem it created was that it tried to be so clean that everything had an abstraction associated with it. I think that influenced my JSConf EU talk about avoiding abstraction. Eventually it reaches a point where nobody can understand it.

Tom: In hindsight, it seems so not practical.

Christoph: It’s funny you refer to it as MooTools 2. That was actually something that was never attainable. It was always a hypothetical, aspirational goal – the actual, perfect, end-state of MooTools. MooTools 2 was basically shipped as 1.2, which broke everything.

Sebastian: That’s how we learned the importance of upgrade paths.

Incidentally, we were just idealists building a framework in a vacuum. We learned a lot from that, and we applied a lot of what we learned to React development.

Tom: That’s actually why React today is so incremental, and why every single release provides steps detailing how you got from the last one to this one. Create React App has instructions for upgrading from a previous version, because we didn’t provide a set back then, and it was a nightmare for everyone that used the framework. Incidentally, we were just idealists building a framework in a vacuum. We learned a lot from that, and we applied a lot of what we learned to React development.

Christoph: That’s maybe the takeaway. MooTools definitely taught us a ton of lessons that now help us with projects like React or whatever else we work on in open source.

Do you think that your learnings from MooTools is one of the reasons why open source has been so successful at Facebook?

Tom: Yeah, I started this project called Project Perception. I wanted to change the perception of Facebook in the front-end community, by talking more openly about what we were doing. James Pearce joined Facebook around that time, and started managing an open source team to work on it. We’ve been collaborating ever since.

Then, Jordan Walke handed us React. It was the solution to our problem. It was a very different way of building web apps.

Open source also helps you be intellectually honest with yourself. If you’re putting ideas out there, people will find flaws, they will have other ideas. You can’t just say there are better solutions internally. You can compare it to other solutions in the ecosystem. It forces you to be honest with yourself, and it helps the company as well.

Sebastian: Open source also helps you be intellectually honest with yourself. If you’re putting ideas out there, people will find flaws, they will have other ideas. You can’t just say there are better solutions internally. You can compare it to other solutions in the ecosystem. It forces you to be honest with yourself, and it helps the company as well.

For some reason like twenty years ago games went one way with immediate mode rendering and functional programming, and apps went the other way with imperative, object oriented programming. Then we were starting to see, like with React, a shift back to the direction of declarative, asynchronous, functional programming

Tom: There was actually a lot of push back against open sourcing React. Many could enumerate the costs, but they didn’t really understand the benefits. Even if we tried to sell recruiting as a benefit, it was always an intangible, immeasurable thing. I don’t think we took into account that we would have the ability to push the entire industry forward – to watch the ideas and concepts from React bleed into other frameworks.

I don’t think React was directly competing with any other JavaScript library at the time. I think it was competing with a traditional way of building user interfaces. For some reason like twenty years ago games went one way with immediate mode rendering and functional programming, and apps went the other way with imperative, object oriented programming. Then we were starting to see, like with React, a shift back to the direction of declarative, asynchronous, functional programming, and now, every framework, every view system on every platform has taken these ideas into account. I think we’ll start to see that more and more, over time.

Christoph: It’s also tied back to MooTools, it was something we learned the hard way. The downfall of MooTools if you want to call it that, was because we didn’t collaborate with many people outside of our team. In jQuery they adopted some of our animation code, and we were actually offended by it. Even though it was open source, we thought we knew how to build the perfect system by ourselves. I think the benefit of open sourcing a project, is that it starts with a level of competition, and eventually leads to collaboration.

Compared to MooTools, or just your experience with open source initially compared to today, what’s changed?

Sebastian: I’ve been on the outskirts of a couple of open source communities, and I think there’s a lot of varied management structures. With React, we foster certain people we can trust to stick around by working closely with them. It’s mainly driven by a core team rather than RFCs for example.

But, it’s a process we’re constantly evaluating, like looking at how Ember does it with RFCs.

Tom: I think we all really like Ember’s RFC process. We talk about it internally all the time, and we’ve applied it to the GraphQL project and a few other projects.

Christoph: Yarn as well.

Tom: Also, for MooTools, funding was handled on our own. With React it’s different because Facebook is relying heavily on React. We have something like 36,000 React components checked into our code base, and we’re supporting dozens of existing app in production. We can’t just make huge, sweeping changes like MooTools 2. We have to think about things incrementally. We have to think about upgrade paths.

You can be somewhat assured that if React continues to work well for us, it will continue to work well for you. We have to upgrade ourselves at the same time as you. If we stop using it, if we stop investing in it, you’re going to know early on, and we’re going to have to have a path forward. It’s a bit of a security blanket.

So I think now, we’re hesitant of being a fork in the ecosystem. We see it over and over in open source, everyone has to work together because otherwise you create a much smaller, bifurcating ecosystem.

Sebastian: With MooTools, a lot of big companies relied on it, but we weren’t working for them. People kept contributing to the older versions because they couldn’t upgrade – there was no sane upgrade path at the time. So I think now, we’re hesitant of being a fork in the ecosystem. We see it over and over in open source, everyone has to work together because otherwise you create a much smaller, bifurcating ecosystem.

What about from the contributor point of view? Do you feel it’s any easier or more difficult?

There is still, for every project, one person associated with it. The creator. On Twitter, they always refer to that one person. I feel like that’s what burns people out. The only reason these projects are so great is because there’s a whole team of people contributing to it, not just one person.

Christoph: There is still, for every project, one person associated with it. The creator. On Twitter, they always refer to that one person. I feel like that’s what burns people out. The only reason these projects are so great is because there’s a whole team of people contributing to it, not just one person. As the one person though, there are still a lot of people who will attack you, or create issues that are difficult if not impossible to deal with. I feel like that hasn’t changed. I honestly also just wish people were nicer in general. That’s something that is difficult to deal with. Maybe that’s just me putting so much of my heart into this open source project.

…you can’t take the emotion out of open source because open source, and this community, is driven by passion, it is a lot of emotion.

Sebastian: I think Dan Abramov put it best when he said, you can’t take the emotion out of open source because open source, and this community, is driven by passion, it is a lot of emotion. My biggest recommendation to those just starting out in open source is to not be tricked by the founder status. Start out by making yourself replaceable. You’re building an ecosystem, it should be able to function without you, otherwise you’ll burn out. That’s one thing John Resig did really well. He was able to grow jQuery to the point where he wasn’t contributing much.

My biggest recommendation to those just starting out in open source is to not be tricked by the founder status. Start out by making yourself replaceable.

Tom: jQuery, in my opinion, did significantly better than MooTools in this regard, and better than React is currently doing. There were so many core contributors to jQuery that all could have taken it in the right direction for the long haul. That’s why I think it’s still so prevalent. Most websites still have jQuery, and it’s still the go-to for all the cross-browser issues.

As far as the emotional side, you have to be able to separate yourself. Separate yourself from the feedback, and from the community, so you can actually do the work. Dan Abramov does this the best. Any time there is any angst, or anger, or negativity, he just combats it with vicious niceness. He’s just so overwhelmingly nice that he wants to get to the root of why you feel a certain way. He has thicker skin than most, certainly thicker than mine.

Separate yourself from the feedback, and from the community, so you can actually do the work.

Christoph: This has totally turned into a group therapy session. Thank you for that.

For someone who is maybe a year into programming, or two years into programming, and they’re just getting into open source today, what is one piece of advice you’d give to them?

Everyone feels intimidated when they first approach a project. […] All you need to do is ask how you can help, and find the project. […] Just stay humble, and start small.

Tom: Everyone feels intimidated when they first approach a project. They don’t know how they can help, but they want to be involved. All you need to do is ask how you can help, and find the project.

Find something that’s a burden for the maintainers. It can be something simple, like closing out duplicate issues, or responding to questions, or helping to prioritize items. Don’t show up wanting to rewrite everything. Just stay humble, and start small.

Sebastian: Don’t get discouraged.

Tom: Yeah, don’t get discouraged.

Always know that maintainers and core teams see almost everything and will remember you. You’re not invisible, so the more you keep contributing, even if they never respond to your issue, they’ll know who you are.

Sebastian: Because there’s often a lot of context, especially on longer-living projects, and not everything is documented.

There may also be very few maintainers to look at issues or port requests. That’s something we’re actively working on. We have metrics tracking that, and are trying to be better, but there are still issues. Always know that maintainers and core teams see almost everything and will remember you. You’re not invisible, so the more you keep contributing, even if they never respond to your issue, they’ll know who you are. When they do need your help, they’ll know what you’ve contributed on, and what context you have. Don’t get discouraged early on.

Christoph: Yeah, I mean I guess people being intimidated goes back to the hero founder status that some people have or perceive. Often it helps to just meet people at conferences. You’ll realize they’re just real people, they’re not the smartest people in the world. They’re just normal people that happened to work on this project. You can start contributing, and get to that point as well.

All of us are here today because we’re very passionate about the web, so we’re curious to hear what keeps you on your toes and excited to keep contributing to making the web better?

I don’t think you should have to learn 3,000 different technologies in order to build a simple app. The web is how I got into software, and I think it’s ultimately how most people could and should get into software.

Tom: For me, I really want to make it easier to build software. I think it’s just extraordinarily difficult to build software in any capacity. I don’t think you should have to learn 3,000 different technologies in order to build a simple app. The web is how I got into software, and I think it’s ultimately how most people could and should get into software. The best thing about web technology is the very low barrier to entry. That feeling of high productivity and rapid iteration with all software development, whether you’re building an image decoder backend service, or you’re building a simple game or app, or a complex VR game. I think the complexities of a particular platform that you want to build for, should be disclosed over time as you encounter them.

Christoph: Yeah, that’s why we are all here, right?

We all know that with too much fragmentation, you can’t do anything, and eventually you end up joining back in. I hope that we’re able to join back in as quickly as possible. We don’t want to lose track of the next layer because technology is fundamentally about building layers, on top of layers, on top of layers of abstraction. We might be focused on the top layer, but someone’s building the next layer, and they can’t do that if our layer is too fragmented. We have to be able to unify, and collaborate.

Sebastian: I’d add that one of the reasons I’m excited about the web in general, is because there’s a tendency for our community to diverge when we have new ideas, but we have to unify at some point. We all know that with too much fragmentation, you can’t do anything, and eventually you end up joining back in. I hope that we’re able to join back in as quickly as possible. We don’t want to lose track of the next layer because technology is fundamentally about building layers, on top of layers, on top of layers of abstraction. We might be focused on the top layer, but someone’s building the next layer, and they can’t too that if our layer is too fragmented. We have to be able to unify, and collaborate.

Christoph: I guess one great thing is that all of this tooling is also written in JavaScript. So, while it’s great that we’re trying to make it easier to build software, the barrier to entry in general is much lower. Everything is written in JavaScript, so whatever you want to work on, you can go and work on that piece and improve it. The prospect that everything could be written in one language is actually really cool. Your React framework, your user code, your test framework, your JavaScript bundler, your package manager – they’re all written in the same language. So, if you have a problem with one, it’s pretty easy to solve. That’s what excites me.

This project is made possible with sponsorships from frontendmasters.com, egghead.io and Microsoft Edge.

This post was originally published on betweenthewires.org