 I'm really excited and pleased to be here. My name is Christoph Poyer. I'm studying software engineering. I'm a Mutur's core developer, and I'm here to talk to you about Mutur's as a general purpose application framework. So what does that mean? Why did I choose that title? In order to answer the question, we need to look at the web in general. And the web has become or is becoming a general purpose platform. And what that means is that web developers, basically everyone who is in here, invents things on a daily basis. So web developers create fancy websites or big sophisticated web applications out of a blank web page. And I think it's reasonable to say that JavaScript libraries have made a significant contribution to inventions and innovation on the Internet. And in order to invent something, you need good sophisticated tools. And I'm going to show you how Mutur's is the perfect tool for any kind of application development on the Internet. And I'm really excited to present to you what the Mutur's core developers are creating on a daily basis. And we have about 20 to 40 or 250 years. I don't know how many contribute us. So JavaScript and Mutur's. The name Mutur's comes from my object-oriented JavaScript tools. While JavaScript is an object-oriented language, it lacks one main concept that is common in most of today's popular programming languages. And that is a class-oriented design. JavaScript is prototype-based. It doesn't have classes. It doesn't have classes as first-class objects, no pun intended. So this is really difficult for a lot of developers, because they're used to working with classes on the server side in another language. And when they come to JavaScript, they think it doesn't have classes. I need to rethink everything I'm doing. And it's weird, because a lot of developers, even despite of the popularity of the language, are not used to how JavaScript works. A lot of developers do not learn JavaScript. As Douglas Crockford says, people think JavaScript is the only language you don't need to learn. And I think that's wrong. But it's totally fine, because a lot of people just need JavaScript to do animation, XML, HDTV requests, or something like that. So who in here are JavaScript developers? So okay, that's great. And who if you started to use JavaScript without learning the language? I admit it. Isn't there shame in admitting it? Yeah. So I did my first animation library five years ago. The code is horrible. It somehow worked. I don't know why. I did a lightbox clone without knowing anything about JavaScript in general. So Moutour tries to build on that with Moutour's core. It tries to hide the complexity that is JavaScript, and it makes it easier for you to use the internal stuff that is in JavaScript by wrapping it with nice utility functionality. And one good pattern to begin with is class. So as I said, JavaScript doesn't have classes. It's bad for a lot of developers, so we provide something that looks like a class. It feels like a class when you use it, but it is not a class. Let's look at an example. And even if you don't know anything about Moutour's or JavaScript, you will be able to understand it. You don't need any documentation for it. So we create a new class called animal. We give it an energy property. And it has an initialized function, which is the constructor method, and it takes the name at the age of the animal. So that's all you need to know. I think it's really easy to read. So one main goal of Moutour's core is to provide an API that you can guess. And you should really, it should be really easy to understand this. So let's extend on the example. So add two methods, like an eat and tie method, so we can play with it. And at that point, we can create an instance. And this is just normal JavaScript. But this is really boring because we don't have a generic animal or something like that. So let's look at what Moutour's provides on a much lower level with subclasses. So we create a new class called tiger. And you can see three things here. We extend the animal class. So in this case, you can probably understand what it does. It takes the animal as a parent class and subclasses it. We override the eat method, and you can see a card to this.parent. So this cards the eat method on the parent class on the animal. And there is one thing that I really want to highlight. It's the if statement. It says if the animal is not instance of an animal, don't do anything then. So this just works because Moutour's doesn't provide something that is abstracted away from how JavaScript works natively. But it uses everything that is internal and native to JavaScript. So Moutour's classes use prototype-based inheritance internally, but you don't need to know anything about it to use it. So this just works because of the way Moutour's works with classes. And one more thing I want to point out is that when you, I like to look at my applications as one entity. I think server side and JavaScript, a server side and client side code should have the same structure. So if you're doing class-oriented, working with a class-oriented language on the server side, you should recreate that structure on the client side. It makes it a lot easier to understand the whole application. So even if your class is like an animal class, don't do the exactly same thing on the server and the client, you should try to recreate the same structure. It makes it a lot easier. Okay. So we have that Tiger example. Yes. Let's play with it. So for the sake of the example, let's create a sheep and then we create an instance of the tiger and the tiger can eat a new sheep. And this is kind of implementation code. So you should make your classes, put them in one folder or however you like it, far away from your application. You should make your classes as abstract as possible. And we provide a number of ways to do that. We have something like an implements Moutater. And this is how we work with mix-ins. So you can have one parent class, but you can mix in a lot of different classes. And in this case, we just mix in one class called options. It's a Moutater's core function or class for that matter, which provides you with an easy way for optional arguments and stuff like that. We even have stuff like an abstraction for or something that is pretty much the same. I don't know how to say it right now. Sorry, I'm really stuck. Okay. We have mix-ins called events, for example. And with the events mix-in, you can pretty much use the same abstraction that we use for DOM API events or event listeners with your classes. So you get the same API for elements in the DOM and the same API for S when you're using classes. So that's really great. I think that's a bit complex. So I have put up an example with everything that Moutater's classes do. It's really nice to look at it. You should, I just thought we don't have Wi-Fi in here, but that's bad. So just write it down, note it. Look at this. You will be able to read and understand what it does by just looking at the code. We even have a concept of protected methods. I think that's unique to JavaScript libraries. So those are protected methods that really work in the way that you would expect a protected method to work like. Because a lot of JavaScript libraries just do the thing where they prefix it with an underscore and they are supposed to be protected, but you can still call them from the outside. In Moutater's, you can do protected methods that you cannot call from the outside. So this is really something that is similar to what you probably used to on the server side. So let's look at a much lower level. Moutater's extends the native types. So what does that mean? It has a few common data types like array, string, function, and a lot more than those. And JavaScript offers you the incredible possibility to extend those native data types. So we can add methods to every array, to every function. And that is really great. And we use that. Look at one example. So we create an array and call it a map function on it. This doesn't work in IE in the Trident engine. It doesn't work in IE6, IE7, or IE8. So with Moutater's, you don't have to think about this. We provide a method. You can just use it. You don't care about any implementation details in a specific browser. So we don't only provide DOM abstraction, but we do try to provide you with a way to work around browser issues on a much lower level. The one thing I see that is quite common is something like this. Because JavaScript is loosely typed. It's really cool. You can use a string as an array-like object. So you can call an array method on a string. And I see these quite often array.prototype.each. That's Moutater's method for each.call. And this is really ugly. I mean, who wants to write code that looks like that? And Firefox introduced a concept called generics. So they put all those array functions that are usually on the array prototype. They put it on the data type object itself. So you can call it like this in Moutater's array.each. And it binds the hello world, the string to the each method, and iterates over each character. That's really cool stuff. And Moutater's also allows you to implement your own methods into JavaScript. A lot of people say Moutater's makes it easy to extend Moutater's. But that's not true, because we make it easy to extend JavaScript. So with that method, array.implement, we can just easily provide or define a shuffer method that is now available on our arrays and as a generic on the array object. So that's cool stuff. So I wanted to go with the DOM is inconsistent, inconsistent on a much higher level. But then I found this on Twitter, which is pretty cool. Okay. So the DOM is inconsistent. What does that mean? It is not only inconsistent across browsers, but even the specifications of the DOM API are very inconsistent. So we have a DOM selectors, a CSS selectors API that puts method on the document that we have the DOM, the different DOM lever specifications. And then we have the browser inconsistencies that the event listener stuff works different in every browser and all of that. And JavaScript libraries abstract away from this. So all of the JavaScript libraries provide a wrapper around the DOM. So Moutater does it in a different way. We just extend the native element prototypes, because this is what we do as a core function as we extend the native types like array and function and string. We also do that for elements. And you can again read this example and understand what it does. We create a new element, an ATAC with a class, an href, and a text. And you see on the bottom to what it corresponds to. Let's extend to the example. Again, you can read it. We create a new element. It's the same as before. We set the styles for the color and the display property. And you can add an event for when you click on it. You click me and then we inject it into the document. So that's great stuff. And this is not just an object that references to an element, but this is the real element. So you can do that. You can't do that in other libraries. You can only do that in Moutools. You can actually access the style property on elements. And this is also possible with Moutools, which you cannot do in other libraries. So we have the get element method, which queries the page and searches for an element. And this returns the real element and not just an object that references to that element. So in other libraries, you can't do that direct comparison. And there is one more cool thing that we provide that is called to element. It's like the to string function when you work with a function and call to string on it and stuff like that. But this is specific to Moutools. So classes have a to element function. Looks like that. You can see it on the bottom. You don't need to mind the stuff on the top. A to element method, a special method that makes it possible to use the instance of the class directly as a DOM element, something like that. So that's really cool because a lot of plugins on the client side have a DOM representation. Think about a button user interface element or think about a modal window or something. So there is either a container or one element that is tied closely to the instance of a class. And if you do implement the to element method, we can create an instance of the tiger. We can call the DOM method which is our way of finding an element by a D in the DOM on the tiger and it returns the element so you can call set style on it. And when we extend that example, we search for the animals element in the DOM and then we adopt the instances of classes. We don't adopt this usually used in Moutools to adopt another DOM element. But in this case, we just pass in the classes or the instances of those classes and it works like that. You can see this is probably what the output would look like. So you can see Dewey and Kit and Energy and something like that. So this may look a bit complex, but again, you can find all of that under the link. Okay, so we've looked at, like, four or five components of Moutools core. This is Moutools core. Moutools core is modular so you can download the stuff that you need in your application. You can strip out the stuff that you don't need which results in a smaller download size. So we have looked at the core of Moutools core, the core core. We have the extensions of the native, we've looked at class and element. But on a much higher level, we provide a sophisticated animation library. This is one thing that Moutools is known for. And we provide wrappers for XML, HTTP requests and stuff like that. So this is cool stuff and we think that Moutools core should be an ideal base for any kind of application development. So this is the stuff that you most likely need when you do any kind of application development on the client side. But quite often, you need more than that. You need more plugins. And we have a solution to that that's called Moutools more. And this is our official plugin repository. We have almost 60 plugins in it. All of them are supported, documented and tested. The new version is going to be released, I think, in the next two weeks or something like that. So we have a lot of plugins in there. About 50% of the plugins are low-level extensions and the other half is high-level extensions. So we, again, in Moutools core, we extend the native types like we provide extra functionality for arrays, for the data objects. We even have a URI native that makes it easy to work with links and stuff like that. And those are low-level extensions and it provides you with functionality that you don't need in most of the applications, but you probably need that stuff in a few edge cases. So this Moutools more is even more modular than Moutools core. So it provides a lot of things that, sorry, I'm stuck again. It provides you with a lot of things that you may need, but quite often you don't need everything, you just need three or five components of that. So it depends on what you're doing. On a high-level, we provide stuff like tour tips, like track and drop, the Accordion, the famous Accordion. And this is really cool stuff, yeah. So this is the impact graph on GitHub. We have like 10 to 20 contributors for each release. Every one of, every line is a different contributor. And you can see the amount of lines added or removed. So the whole Moutools team and a lot of contributors work on Moutools core. So everything is supported and tested. And now we have the official Moutools core library. We have Moutools more, but most of the time you need even more than that. And we even have solution for that. It's called the Forge. It's our official plugin repository with user-supplied plugins. And it's also open source. I talked to Dylan yesterday, and Dojo is going to use it, too, so that's great. So we basically created a plugin repository that should be able to be used for a lot of different libraries. So Dojo can use it, and maybe other libraries will like it, too. So we try to not only help the Moutools project move forward, but we try to provide components or applications that should be useful for the whole JavaScript world in general. Because I think everyone, every library creator wants the web to be great, so we try to help with that. We don't try just to help Moutools. So the Moutools Forge created by one of the Moutools developers. It looks like this. Users are able to contribute to their plugins. And that's the main page with new plugins and stuff like that. We released it almost two months ago, and we almost have 150 plugins, so that's really cool. Every user gets a user profile page. It really helped us to connect with the community. It's the first time we kind of were able to put faces to the code or put codes to the faces, so we have better ways to interact with our community. And every project or every plugin gets its own project page. And we have tight GitHub integration, so that's really great. We got our users to use Git and GitHub. For most users, it's the first time to ever use version controller, so I think that benefits every user who wants to upload a plugin in another way, too. And the cool thing is that we can leverage the whole functionality that GitHub provides. So we use a link to GitHub issues, which is really cool for small projects. And sometimes it happens that users abandon a project. This is just how it works. But the cool thing is that when we use GitHub, another user who wants to work on it can just fork the project and upload it to the Forge. And one more cool thing I want to highlight is that it's most of the time when you release a plugin, it's really a tedious task. You have to write a blog post, you have to create screenshots, you have to keep it updated and all of that. And it's really boring to do that. And with the Forge, you can just upload your repository on GitHub, pass your link into the Forge application and click submit, and it is in the Forge. So if you update your code, you just need to click one button, the update button, and everything is updated. So that's really easy to do. So think about it. You download Mootools Core, you use Mootools More, some Forge plugins, maybe something like that. You don't know a lot about Mootools. And you run into a problem. This is how it usually works. Everyone runs into problems when he develops applications. And quite often you ask on the mailing list for help, and you pass like five lines of code and wonder why it doesn't work. When you want to help the guy, you have to recreate the environment, and it's a lot of work to do, and it's really boring. So we have a solution called Mooshel or Chase Fiddle. Again, we provide this for the whole JavaScript community. It looks like that. You can, it's kind of a web sandbox, so you can put in your JavaScript, your HTML, and your CSS, and recreate the test case. And this is great. You can trust them right on the mailing list. Oh, I have found something that doesn't work. And provide a link to the Mooshel and say, I have provided, I have made a Mooshel so you can see it really doesn't work. And this is also great for the bug-dragging system, you know? So when people find a bug or think they have found a bug, we tell them to provide a Mooshel so we can just open it up in our browser and see if it's broken or not. So that's great. And Dylan also said they are suggesting their users to use Chase Fiddle. So this is, again, something that we provide for the whole JavaScript community, not just for Mootools. You can also embed Mooshels or shells or however they are called now. So if you're writing a blog post, you can embed it and you can directly run it on your own website. So that's really cool stuff. One more thing I want to highlight is Slick. It's our new Selectos engine for the next version of Mootools. It's completely rewritten. It is focused on accuracy. That means it almost completely implements the whole CSS free selectors specification. It is focused on customizability. That means that you can create custom attribute selectors, custom combinators, custom slider selectors, all of that stuff. The parser and the matcher are separated so you can maybe use the CSS parser for other things than doing queries in the DOM. So that's really cool stuff that we are going to implement in the next version. It's also focused obviously on speed, but it doesn't really matter that much anymore today. So you probably saw Slick speed at one point. The Mootools team released it about two years ago. And I think it started kind of a selector engine was, if you want to call it like that. It was the first time people were able to compare selector engines of different JavaScript libraries. And everyone was thinking like, oh, the library creators were thinking like, our selector engine is slow. Let's rewrite it. And we have a lot of selector engines now. I don't know how many there are. And the problem with most of them is that they are only maintained by a single person. And Slick is maintained even though there is no official or no public release yet. It is maintained by at least three team members and at least two more contributors. So it's a big team basically for a web project. You should not rely on projects that are only maintained by one person. Okay, so Slick speed kind of became the de facto standard to compare the speed of different libraries. And a byproduct of the Slick selectors engine is Slick spec. It's a selector engine independent list of specifications that every selector engine should fulfill. So this is done for Slick, but another selector engine can use that to improve the quality of the code and the accuracy of selector engines. That's great stuff. You can see the link on the bottom. It's free alpha right now, but other selector engines should be able to use it. Again, something that we provide for the whole community and not just for Mootourds. So Slick will be implemented into Mootourds Core 1.3. Mootourds Core, the current version 1.2.4. The API of 1.2 is stable for almost two years. I think that means a lot on the web. And it's working great, but we want to improve on that. So we are cleaning up some of the core features. We are implementing Slick, as I said, and adding a few new nice functions. Let's say that. We don't know when we're going to release it. We're working on it. It will take some more time. So I heard that in 2010, real time is going to be big. So that means that when you do something, someone else should immediately see the results of that. And I did my first real-time experience almost a year ago, turn-based strategy, best game principle ever. You can see a screencast under the link. It's really cool. And I did this with Ape, with the Ape project. And it's specifically designed to create real-time applications. The guys are somewhere over there, really great guys. It's an open-source project. It's not a Mootourds project, I need to say that. And they are the first ones to actually use Mootourds on the server side, for server-side JavaScript. And this is really great. There is a much bigger picture to that. It's common chess. Who knows what common chess is? Who has out of it? Okay, only a few people. I'm going to explain it. So common chess is, let's say, JavaScript itself is extending beyond the browser. So JavaScript is not only being used on the client side, but it can now also be used on the server-side. And it's not even limited to server-side, but you can also write command-line applications with JavaScript. I don't know where this is going. But common chess is actually trying to provide a set of standards or a set of features that each of those JavaScript implementations should provide. So they came up with an implementation for Mootourds, and they defined some core Mootourds that every implementation of JavaScript should have. So those are some of those implementations. You have probably heard of a few of them. Node.js is really popular right now. And all of those support JavaScript. They are basically server-side implementations of JavaScript using SpiderMonkey or V8, or SpiderMonkey with Rhino in those environments. So we try to make Mootourds use around the server-side. And it is already because of all the stuff that I said earlier that we extend the native types and that we provide a class system that works on a much lower level than just, and it's not just damage structure. So we are working on Mootourds 2 at the same time. OK, it doesn't work that good. Maybe you can see it. It still has a few bugs. We are working on both versions 1.3 and 2.0 at the same time. It's going to take a little more time than 1.3. But it should be the ideal base for application development on the server-side. And the cool thing is that at that point, you can properly create the same classes and use the same classes on both the server-side and on the client-side, unmodified. And that's a great thing to do. So I have my fork of core 2.0. You can see it under the link with Common Chairs, Mootourds support. So it works like Mootourds should work in Common Chairs. We have a couple of implementations. I think I did three of them. We have idea for a couple more. We did not decide on a final implementation yet because we really want to define the best practices for our community. So we are still in the thinking process. But you can use that if you want to use server-side JavaScript and if you want to use Mootourds on the server. One more project I want to highlight. It is being done by one of the Mootourds contributors. It's called DEC. And it works on the server-side JavaScript implementations I had earlier on the slides. And it is kind of a library that uses Mootourds core 2.0 on the low level. And it tries to abstract away from all these implementations. And it tries to make it easier for you to create web applications with JavaScript on the server-side. It's in early development, but it's really cool. And I think it's really important to do that kind of stuff because even if there is some sort of standard on the server-side, no one has to follow it. And I think at some point some implementations may have different implementations of the same thing in JavaScript. And DEC tries to eliminate those problems that may arise at some point. So if you use DEC, you can easily move or more easily move between those different implementations. So I said earlier, a lot of people think they do not need to learn JavaScript. And you do not need to learn JavaScript. You can just do something with it. When you want to add animations on the client-side, you just do it. You don't think about objects and their prototypes. You're just down to the library and create those animations. So you don't need to learn JavaScript. And the cool thing is when users, it's quite surprising that users are actually able to get something done without knowing a lot about the language. I think that is amazing for a programming language. I mean, think about it. And I don't know, but it probably will extend to the browser, to the server-side. So that means that you don't know a lot about JavaScript, but you're still able to create something on both the server and the client-side. So I think it's safe to say that it is getting a lot easier to develop web applications. And no worries. So you do not need to learn JavaScript, but you absolutely should learn JavaScript, because it benefits you. OK, so that's it. Thank you. OK, so any questions? OK, so I think the compressed version is about 65 kilopytes, something like that. But because it's modular, you can just strip out the parts that you don't need. So that's really cool. And quite often, when you do like working, that's why we don't provide a mobile version of Moutur, something like that. Because you can just remove the parts that you don't need and make the file size smaller. And that's also Moutur's more is very modular. So you only take the parts that you really need. OK, any other questions? OK, so 1.3 doesn't change the API that much. We are going to remove the TARLA prefix functions. And we are moving the functions to the objects themselves. So instead of $splat, we have array.from and something like that. And 2.0 is a complete rewrite. So we cleaned up the whole code base. And we try to provide a lot of features like only one timer for animations. All of those core features that should speed up your application. So Moutur's core is built on the 1.2 code base. And 2.0 is pretty much a completely new version. But we are going to provide or aiming for full backwards compatibility. OK. Yeah? I was not allowed to say that. But this is just a little internal deaf joke of our team. So Valerio, the inventor of Moutur's, created the accordion animation. And we mock him because he doesn't like it anymore. OK. So I think the way to go about it is with Moutur's, because I think it's perfect for that kind of stuff. So you should provide or create a base class. Like when you do an animal class with the base logic that can be applied on both the server and the client side. And then you should create an adapter for the server and the client side. So you have the same base class. And you subclass it on both sides of the end. So I think that's a cool thing to do, because you can use the same code on both sides unmodified. I mean, that was never possible before. I think that's cool. Yeah? Well, Moutur's is well-documented. And 2.0 will obviously be documented as well. Then write tutorials. We have great resources. We have two Moutur's books. I can give you some links if you want to. We have really great resources to learn Moutur's. And the cool thing, as I tried to point out, the AP is easy to guess. So you can guess what it means by just reading code. So I think that's one cool feature of Moutur's. OK. Any other questions? Nope. So that's it. Sorry. What? Sorry? XJS. OK. Well, XJS is a library that is focused to create user interface elements. So it provides those user interface elements, like buttons and dabs and whatever there is. So Moutur's is working on a much lower level. We don't provide those components out of the box. So you have to recreate them yourself. But there's one cool project that is called Moutur's Art. I don't know when it's going to be released, but it is an SVG and VML abstraction. And it is going to be a base for that kind of user interface stuff. So Art is going to be similar to Moutur's Core, just an abstraction of some implementations like SVG and VML. And you can build a sophisticated application development framework on that. OK. Any other questions? Nope. So that's it. Thank you.