The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or clickhereto continue anyway

Between the Wires | MooTools Between the Wires

Between the Wires |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 were lucky today to be speaking with three of them:

Sebastian Markbge (left), d Christoph Pojer(middle), Tom Occhino(right)

Formerly core contributors to MooTools, Sebastian Markbge, Tom Occhino and Christoph Pojer are active and vibrant contributors to the React community 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 didnt know what valid markup was until Netscape came out in the 1990s, like 1997.

Netscape

Christoph: Exactly! I made websites and someone told me that a website I made didnt work in Firefox. I didnt even know what Firefox was. That was 2001.

Tom: I think it was probably 98 for me if I had to guess because I was 13. It seems like it was earlier.

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

Tom: Youre a dinosaur.

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

MooTools in2007

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 overbasically firing off new animations every time without the ability to choose to either resume, enqueue another, or replace.

It actually wasnt 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.us was 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 thats how it was born. From Moo.fx, there was a foundation for an alternativePrototype plus Script.aculo.uswhich became MooTools.

Tom (left) and Valerio (right), the original author of the MooToolslibrary

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.

MooTools Trac

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 didnt like Prototype and script.aculo.us. I saw Moo.Fx and then MooTools come out. It was in September of 2006I was 16 or 17.

Christoph with dread locks

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 dont 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 didnt know what Facebook or MySpace were. Then I built some other games with it. I wasnt contributing much.

I didnt 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. Thats 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 wasnt that trivial, come on.

Sebastian: I made a rant on the public mailing list. There were two mailing listsa 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 forumsto 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: Thats 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 wasnt 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 itstime.

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 anyones 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 thats 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. Thats 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 didnt do any outreach. We attended maybe 35 conferences over the course of seven years. We didnt 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 grammarthe 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.

MooTools team hackingaway

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 teamone that shares the same values in terms of how you write code and what you should prioritize. Thats one thing we mastered that allowed us to moveforward.

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

On the other hand, pragmatism is something we didnt do well, but weve 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 dont 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 couldnt 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 thats 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 projectsthe common wisdom was that they were going to succeed. That these business tools backed by big enterprises were going to replace JavaScript. But thats not quite what happened. It goes to show, you have to pay attention to what people are drawn to. Theyre 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 yourcareer?

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 didnt really know what I was talking about. I thank my lucky stars everyday that it wasnt 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.

Tom at React.jsConf

Christoph: My story is pretty similar to Toms. 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 didnt wanted to move to California, especially not the Bay Area. But, another MooTools guy referred me to Apple, so I interviewed there. I didnt really like the attitude of the company. I honestly didnt 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 didnt 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 workingon.

Tom: People didnt 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 didnt come around until 2013.

Christoph: People actually thought we didnt know JavaScript.

Tom: Its 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 MooTools2?

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: Its funny you refer to it as MooTools 2. That was actually something that was never attainable. It was always a hypothetical, aspirational goalthe actual, perfect, end-state of MooTools. MooTools 2 was basically shipped as 1.2, which broke everything.

Sebastian: Thats 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: Thats 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 didnt 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: Thats 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. Weve 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 youre putting ideas out there, people will find flaws, they will have other ideas. You cant 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 aswell.

Sebastian: Open source also helps you be intellectually honest with yourself. If youre putting ideas out there, people will find flaws, they will have other ideas. You cant 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 didnt really understand the benefits. Even if we tried to sell recruiting as a benefit, it was always an intangible, immeasurable thing. I dont think we took into account that we would have the ability to push the entire industry forwardto watch the ideas and concepts from React bleed into other frameworks.

I dont 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 well start to see that more and more, over time.

Christoph: Its 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 didnt 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, whatschanged?

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

But, its a process were constantly evaluating, like looking at how Ember does it with RFCs.

Tom: I think we all really like Embers RFC process. We talk about it internally all the time, and weve 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 its different because Facebook is relying heavily on React. We have something like 36,000 React components checked into our code base, and were supporting dozens of existing app in production. We cant 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, youre going to know early on, and were going to have to have a path forward. Its a bit of a security blanket.

So I think now, were 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 werent working for them. People kept contributing to the older versions because they couldnt upgradethere was no sane upgrade path at the time. So I think now, were 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 its 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 thats what burns people out. The only reason these projects are so great is because theres a whole team of people contributing to it, not just oneperson.

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 thats what burns people out. The only reason these projects are so great is because theres 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 hasnt changed. I honestly also just wish people were nicer in general. Thats something that is difficult to deal with. Maybe thats just me putting so much of my heart into this open source project.

you cant take the emotion out of open source because open source, and this community, is driven by passion, it is a lot ofemotion.

Sebastian: I think Dan Abramov put it best when he said, you cant 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. Youre building an ecosystem, it should be able to function without you, otherwise youll burn out. Thats one thing John Resig did really well. He was able to grow jQuery to the point where he wasnt 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. Thats why I think its still so prevalent. Most websites still have jQuery, and its 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. Hes 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 thework.

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 theyre just getting into open source today, what is one piece of advice youd give tothem?

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

Tom: Everyone feels intimidated when they first approach a project. They dont 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 thats a burden for the maintainers. It can be something simple, like closing out duplicate issues, or responding to questions, or helping to prioritize items. Dont show up wanting to rewrite everything. Just stay humble, and start small.

Sebastian: Dont get discouraged.

Tom: Yeah, dont get discouraged.

Always know that maintainers and core teams see almost everything and will remember you. Youre not invisible, so the more you keep contributing, even if they never respond to your issue, theyll know who youare.

Sebastian: Because theres 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. Thats something were 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. Youre not invisible, so the more you keep contributing, even if they never respond to your issue, theyll know who you are. When they do need your help, theyll know what youve contributed on, and what context you have. Dont 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. Youll realize theyre just real people, theyre not the smartest people in the world. Theyre 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 were very passionate about the web, so were curious to hear what keeps you on your toes and excited to keep contributing to making the webbetter?

I dont 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 its 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 its just extraordinarily difficult to build software in any capacity. I dont 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 its 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 youre building an image decoder backend service, or youre 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, thats why we are all here, right?

We all know that with too much fragmentation, you cant do anything, and eventually you end up joining back in. I hope that were able to join back in as quickly as possible. We dont 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 someones building the next layer, and they cant do that if our layer is too fragmented. We have to be able to unify, and collaborate.

Sebastian: Id add that one of the reasons Im excited about the web in general, is because theres 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 cant do anything, and eventually you end up joining back in. I hope that were able to join back in as quickly as possible. We dont 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 someones building the next layer, and they cant 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 its great that were 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 managertheyre all written in the same language. So, if you have a problem with one, its pretty easy to solve. Thats what excites me.

Continue reading on betweenthewires.org