MooTools total Technikwürze 165

Bevor wir mit der regulären Sendung beginnen, möchte ich noch kurz das Gewinnspiel von letzter Woche auflösen. Wir haben nämlich Donnerstag, den ersten April um null Uhr sieben in der Früh. Das heißt, unser Countdown ist gerade abgelaufen und, ich habe soeben per Zufallsgenerator die Gewinner ausgelost. Wir fangen an mit dem Webstandards-Magazin-Jahresabo. Das geht an Rise to the Sky. Viel Spaß damit und das WordPress-Buch ist bestimmt in guten Händen bei Pretty Cool Times.

Auch dir viel Spaß damit. Ja, allen anderen vielen Dank für die rege Teilnahme. Die hat uns, sehr beeindruckt. Und, ja, mit diesen Worten gebe ich jetzt ab. Zurück in die Vergangenheit an, mich und Peter Kröner mit einer, ich hoffe doch sehr unterhaltsamen Technikwürze. Viel Spaß damit.

Herzlich willkommen zu Technikwürze, eurem Design- und Webstandards-Podcast.

Herzlich willkommen zu einer weiteren spannenden Ausgabe der Technikwürze per Skype dazu geschaltet, Peter Kröner. Hi.

Hallo.

Wir werfen heute einen Blick auf ein JavaScript-Framework und das ist nicht jQuery. In, in, insofern, schon mal die ersten Skeptiker, da abgewehrt. Es ist MooTools, ein ziemlich altes, Framework, das Framework, auf dem ich das erste Mal, großartig rumgeritten bin und, wie du uns jetzt erzählen wirst, ist es noch immer spannend.

Ja, es ist vor allen Dingen, alt, möchte ich jetzt mal so ein bisschen relativieren. Alt heißt jetzt natürlich nicht, dass das, irgendwie veraltet ist.

Nein, nein, aber es ist schon länger dabei. Es ist erfahren.

Es ist erfahren. Es, hat seiner, seinerzeit angefangen als ein Aufsatz auf Prototype. Prototype war ja eines dieser, einer dieser ersten Bibliotheken, die es da gab und, war wohl – ich weiß es nicht, ich war nicht dabei – effektmäßig nicht ganz so fit im Sinne von, dass es halt entweder beschränkt oder langsam war. Eins von beiden war das da. Und da kam halt jemand daher, Valerio Perotti heißt er, glaube ich, und, schrieb da sein Effekt-Plugin für, nannte das MooFX.

Dann hat, dann ist irgendwann klar geworden, dass, Prototype als Basis, nicht so ganz das macht, was eben die MooTools-Entwickler wollten. Und dann haben sie eben angefangen, das, sozusagen die Basis auszutauschen, statt Prototype was eigenes gebaut und das ist dann nach und nach mutiert zu dem, was wir heute als MooTools haben: Ein komplettes eigenes JavaScript-Framework.

Magst du vielleicht kurz erzählen, wer dahintersteckt und, wo, wo der Name eventuell herkommt?

Also, wie gesagt, Valerio Perotti ist, der, die treibende Kraft dahinter und dann eine, bunte Mischung aus Entwicklern, kreuz und quer über alle Welt, die an verschiedenen Teilen des Frameworks, unterschiedlich hart arbeiten. Wo der Name herkommt, da gibt es zwei, zwei Versionen von: Die offizielle Version und die, die wahrscheinlich wahr ist. Also die offizielle Version lautet, dass, MooTools für My Object Oriented Tools steht, weil man damit eben objektorientiert programmiert.

Die andere Seite der Medaille ist, dass, Valerio ein, eine Website hat, schon lange, die, Mad for Milk heißt. Und, wenn man auch in den MooTools-T-Shirt-Shop reinguckt, da ist alles voller Kühe und so. Also wahrscheinlich mag der einfach Kühe.

Wahrscheinlich ein Zusammenspiel von beidem. Es hat wahrscheinlich einfach gut gepasst.

Man weiß es nicht.

Wir hatten ja im Vorfeld schon ein bisschen, über so die Vergleichbarkeit von, von MooTools, besonders mit, mit jQuery, aber auch allen möglichen anderen, gesprochen und auch über 'nen, 'nen Artikel, der, ja, das halt versucht. Du bist aber eher der Meinung, dass das nicht so wirklich sinnvoll ist, beziehungsweise eigentlich gar nicht so wirklich vergleichbar ist, oder?

Ja, es ist halt so, dass diese beiden Ansätze MooTools und jQuery unterschiedliche Ziele haben. Und das sagt auch der Artikel. Und, diese unterschiedlichen Ansätze, meiner Meinung nach und eben nach Ansicht des Artikels, Artikelautors, Klammer auf, der ist MooTools-Entwickler, deswegen möglicherweise vorbelastet, Klammer zu, sind einfach die folgenden: Dass jQuery ein Tool ist, um, das DOM zu bearbeiten. Also in Websites mal schnell ein Element reinkloppen, Punkt dieses, animier jenes, mach das.

Punkt, Punkt, Punkt, fertig. Und, MooTools ist, mehr so was allgemein Gehalteneres. Das erweitert einfach JavaScript beziehungsweise vereinheitlicht ein paar Sachen und, ist halt gut für die Leute, die halt JavaScript schreiben können und gerne schreiben und gerne hätten, dass es ein bisschen angenehmer zu händeln ist. Wir wissen ja um die vielen Macken, die es hat. Dafür ist MooTools da und deswegen würde ich mal infrage stellen, ob da so ein Vergleich so besonders sinnvoll ist.

Die sind eben für unterschiedliche Sachen gemacht. Deswegen machen die unterschiedliche Sachen unterschiedlich gut.

Gibt es oder kennst du denn irgendein, irgendein Framework, was, was dem Prinzip näher kommt als jQuery?

Welchem Prinzip?

Von, von MooTools.

Prototype, ganz klar. Deswegen kann man auch diese beiden, Frameworks, MooTools und Prototype, obgleich sie ja eine gemeinsame Vergangenheit haben, nicht gemeinsam einsetzen. Die machen aber das Gleiche. Das Klassensystem ist von Prototype, inspiriert und Prototype macht ja auch im Prinzip das. Also wir kennen ja von JavaScript diese prototypenbasierte Vererbung, dieses, klassenlose System. Prototype, das impliziert der Name ja schon, setzt darauf auf.

Das heißt, wir kennen es ja von JavaScript, alles, ob jetzt nur Strings oder Zahlen, sind Objekte und die haben Methoden. Und Prototype funktioniert im Prinzip so, dass eben diese, - Objekte erweitert werden, dass sie eben mehr Methoden haben oder bessere Methoden und dass man mit denen mehr Sachen machen kann. Und Prototype kommt halt eben, dem schon ziemlich nahe, aber MooTools ist halt einfach intern anders aufgebaut. Das wär jetzt so der Vergleich.

Wenn wir dann einsteigen, gibt es ja, bleiben wir mal bei jQuery, noch mal 'n kleinen Unterschied. Bei jQuery, zieh ich mir in der Regel die, die schöne, minimierte Version und, bind die ein und bin damit fertig. Das kann ich bei MooTools soweit ich weiß auch, hab aber auch noch die Möglichkeit, das Ganze 'n bisschen zu customizen.

Genau, das ist, das Ganze ist extrem modular. Also erst mal, die Download-Version, also das komplett glücklich Paket gibt's natürlich auch. Dann gibt's noch 'ne spezielle, eine spezielle Server-Edition, wo sozusagen diese ganzen, Sachen eben fürs DOM bearbeiten, also Elemente erzeugen und animieren und so was raus sind und man halt nur die Sachen hat, um mit den normalen JavaScript-Objekten zu arbeiten.

Und man kann tatsächlich sich seine ganz eigene, ja, seine eigene Distribution sozusagen zusammenklicken. Es gibt da so eine schöne Liste von Checkboxen, da kann man sich aussuchen. Ich brauche jetzt also zum Beispiel, nur die, was weiß ich, die Effektkomponent. Da klickt man sich die anderen, werden alle anderen, die, auf die diese Effektkomponente aufsetzt, mit ausgewählt und so Sachen wie dann dieser ganze Ajax-Krempel oder so was bleibt außen vor. Kann man also so zusammenstellen.

Insgesamt gibt das, ist MooTools aufgeteilt in zwei Komponenten. Da gibt's einmal Core, das ist so die Basis mit, ein paar wenigen Effekten, aber eben diesen ganzen Erweiterungen der bekannten JavaScript-Objekte. Und dann gibt's More, was sozusagen das offizielle Plugin-Verzeichnis, möchte ich das mal nennen, ist. Da gibt's also Sachen wie den, wie 'n Formular-Validator und so was. Also alles für 'n bisschen mehr bling bling, aber schon unter offizieller Leitung des MooTools-Teams.

Und das sind so diese beiden Hauptkomponenten. Kann man sich jeweils, individuell zusammenstellen. Die bauen alle irgendwo 'n bisschen aufeinander auf, aber das ist alles sehr bequem zu managen. Man kann sich's also, wie gesagt, customizen, schön klein halten für die Performance-Fraktion ganz wichtig. Oder man kann eben auch den Komplett-Download machen.

Was sicherlich besonders für den Einsteiger, der noch gar nicht so wirklich weiß, was er jetzt für das Projekt gegebenenfalls benötigen wird, halt ziemlich sinnvoll ist, oder?

Ja, der, dem Einsteiger würde ich einfach empfehlen, die Google, Ajax Libraries API zu benutzen. Da ist das dann komplett drin und dann muss man sich auch nichts runterladen oder aktuell halten, dann läuft das einfach.

Meinst du, es macht, also macht das denn überhaupt Sinn, mit MooTools loszulegen, wenn man von, von JavaScript eigentlich gar nicht so wirklich den Plan hat?

Ich würde infrage stellen, dass das überhaupt möglich ist. Das Problem ist nämlich, also was heißt das Problem? Es ist einfach so, dass, bei MooTools-- MooTools hat meines Erachtens eine ziemlich gute Dokumentation, hat aber kein Hello-World-Tutorial..

Also sprich, das, das schöne Aha-Erlebnis, was man bei, bei jQuery hat, selbst wenn man vorher so ziemlich noch gar nichts mit, JavaScript geschrieben hat, das fehlt hier so 'n bisschen.

Ja, ich glaub aber auch nicht, dass, dass, dass die Leute, für die das gedacht ist, letztlich, das auch wirklich suchen. Also der typische, jQuery-Nutzer wird wahrscheinlich so jemand sein: „Ach, hm, ich würd jetzt gern diese lustige Animation auf meiner Seite unterbringen, ich weiß aber nicht wie. Und ich kann kein JavaScript", weil normalerweise lernt niemand JavaScript, man wuselt sich da bestenfalls irgendwie rein.

Und er geht dann auf die jQuery-Seite, findet das tolle Tutorial und gleich auch dies, auf der Startseite diesen schönen Effekt mit, boah, so einfach ist das und der legt dann los und der ist zufrieden.

Der Mootooler ist im Idealfall jemand, der, JavaScript schon kann, aber sich halt darüber ärgert, dass es nicht mehr kann und dass es nicht angenehmer ist und dass da diese komische esoterische Prototypenvererbung ist und dass man da immer Punkt Punkt Punkt schreiben muss und da Sachen und alles so undurchsichtig und bah. Und der geht dann zu MooTools, klickt auf die Dokumentation und findet dann einfach nur sozusagen 'ne, 'ne API-Referenz.

Das gibt's Neues, das gibt's Neues, das gibt's Neues, das fütterst du mit diesen oder jenen Parametern und am Ende kommt das raus. Wunderbar. Also ist insofern nicht wirklich, eigentlich wirklich einsteigerfreundlich im Sinne von für JavaScript-Einsteiger freundlich. Ich glaub sogar, die Demos sind alle ziemlich veraltet auf der MooTools-Seite.

Ziemlich wenige sogar.

Das heißt, das, was man dann da schreibt, das ist auch noch sehr, sehr nah an JavaScript dran, oder beziehungsweise kann, kann das noch jemand lesen, der, der bisher mit MooTools noch so ziemlich gar nicht in Berührung gekommen ist? Das ist ja bei, jQuery teilweise schon 'n bisschen schwierig.

Ja, ich denke schon, dass das, in weiten Teilen geht. Die Sache ist, bei jQuery wird ja 'n ganz neues, Paradigma im Prinzip eingeführt mit dieser DOM-Behandlung. Da heißt es ja immer jQuery irgendwas, Punkt dieses, Punkt jenes, Punkt solches. Wenn man nicht weiß, wie das tickt mit diesem Durchchainen, dann ist das möglicherweise 'n bisschen schwierig zu sehen.

Bei MooTools ist es, kann es wiederum 'n bisschen schwierig sein, wenn man dann jetzt so ohne Vorbereitung in dieses Klassensystem, was es da gibt, da kommen wir gleich sicherlich auch noch zu, wenn man da so reingeworfen wird, wird's 'n bisschen schwierig. Aber letztlich ist MooTools wirklich nur 'ne Java, 'ne Erweiterung von JavaScript, wie man es kennt, im Gegensatz zu 'nem komplett neuen Ansatz.

Also ich denke mal, als JavaScript-Kennender, ich weiß es aus eigener Erfahrung nicht, weil ich wie jeder normale Mensch auch erst JavaScript geschrieben hab und dann hinterher angefangen hab, das so nach und nach zu lernen. Also ich denke, jemand, der dann aber die entsprechende Vorbildung hat, der wird da ganz einfach einsteigen können und sich einfach dann der neuen Features erfreuen können.

Okay, dann lass uns doch mal direkt in die tollen neuen Features einsteigen, die du da grad schon angepriesen hast.

Ja, wo fangen wir an? Also Features ist natürlich, müssen wir jetzt auch wieder 'n Stück weit einschränken, weil letztlich, auch wenn wir wieder jetzt an den Vergleich von verschiedenen JavaScript-Bibliotheken denken, die können alle das Gleiche im Endeffekt. Die können Sachen animieren, die können Ajax Requests machen. Die machen's halt nur alle unterschiedlich. Letztlich, ne, weil das, was möglich ist, ist eben dadurch limitiert, was im Browser halt geht. Und, das Wie ist halt die Frage.

Und bei Mootools ist es eben so, dass man normales JavaScript hat plus ein bisschen. Das ist also wirklich ein Framework im Sinne von, da gibt's ein, Gerüst, auf das man aufsetzen kann oder einfach viele neue Funktionen und Methoden, die man verwenden kann. Die, die Basis des Ganzen beziehungsweise ich denke mal, dass das das Kernanliegen ist, dieses Klassensystem. Wir hatten ja vorhin schon erwähnt, JavaScript, objektorientiert und, Vererbung und so was.

Ja, aber so wie man das eigentlich, heutzutage aus objektorientierten Programmiersprachen kennt, nein, da gibt's nämlich keine Klassen, sondern diese Prototypen. Und, das ist in Mootools auch noch so, nur das wird ein bisschen angenehmer verpackt, dass man einfacher seine Sachen kapseln kann und, wiederverwerten kann und eben auch erweitern kann. Nichts, was mit JavaScript normal nicht auch ginge. Nur es ist halt viel leichter. Und, das ist eigentlich jetzt das Wesentliche.

Das klingt unspektakulär, wenn man das wirklich mal so verinnerlicht hat und dieses Prinzip anwendet, dann schreibt man summa summarum sehr viel weniger Programmcode, als wenn man, wie üblich sein JavaScript nimmt und das von einer Seite in die nächste portiert und dann immer so ein bisschen anpasst und rumheckt und dann auch neue Fehlerchen einbaut und solche Sachen hat.

.

Das braucht jetzt sicherlich ein Beispiel.

Ja, das wär nicht schlecht.

Okay, ich hab nämlich auch ganz akut eins. Ich hab mal was gebastelt für einen Kunden. Das war eine einfache, Slideshow. Also einfach, das waren dann irgendwelche Textcontainer, die nacheinander eingeblendet wurden mit einem Effekt, den man sich aussuchen kann und so weiter und so weiter. Und, jetzt brauche ich was Ähnliches, mit 'nem noch angehängten, mit so angehängten Links, mit denen man das so steuern kann, welches Slide da jetzt kommt, dass man das so durchschalten kann. So 'n, so 'n Menü.

Ich weiß nicht, wie man die Dinger richtig nennt. Beim Weißen Haus haben sie so was sehr schön. Jetzt würde ich als normaler JavaScript-Programmierer das Folgende machen: Ich würde mein Skript nehmen, das rüberkopieren und anpassen und dabei vermutlich dann Sachen kaputt machen oder, sonst was tun. Als Mootools-Programmierer-

Oder redundanten Code.

Ja, das auch. Und ich steck auch nie wirklich drin und das ist alles nie einheitlich und bla. Schlimm, aber so macht man's halt normalerweise. Das Gute an Mootools ist aber, weil ich diese Slideshow in der Klasse gekapselt habe, kann ich mich da einhängen. Ich kann also eine neue Klasse schreiben, die auf meine Slideshow aufsetzt, also Slideshow steuerbar nenne ich die dann.

Ich hak mich da ein, indem ich einfach darauf, wie gesagt, aufsetze, die ganzen Methoden sozusagen der Slideshow erbe, zwei, drei modifiziere, eine neue hinzufüge und ich bin fertig. Das ist, glaube ich, jetzt, als abstraktes Beispiel ein bisschen, bisschen ungünstig, aber ich würde einfach mal empfehlen, wir haben in den Links zur Sendung, einen, einen Link auf ein, echtes Mootools-Plugin aus dem Core. Das ist, die, Request JSON-Klasse auf GitHub.

Da kann man direkt in den Code gucken und das ist das Tool, was, eben Ajax Requests ausführt und JSON-- interpretiertes JSON, also fertige JavaScript-Objekte zurückgibt. Das ganze Ding ist, wie viel, keine zwanzig Zeilen lang. Warum ist das keine zwanzig Zeilen lang? Weil das auf eine andere Klasse aufsitzt, nämlich die Request-Klasse. Die Request-Klasse ist so ein etwas abstrakteres Konstrukt. Das macht halt irgendwelche, Ajax-Sachen.

Und dann kann man das eben, dieses, Muster variieren, indem man da verschiedene Klassen aufsetzt. Es gibt diese Request-HTML-Klasse, glaube ich, die gibt HTML-Elemente zurück und dann gibt's die JSON-Klasse, die gibt den JSON zurück. Diese beiden modifizieren jeweils nur die Request-Klasse, sodass man letztlich, als ich irgendwann mal jemand hingesetzt hat, gesagt, ich brauche jetzt eine JSON-Request-Klasse, musste der zwanzig Zeilen schreiben und nichts hacken.

Das heißt, auch wenn wir jetzt vielleicht so ein bisschen springen,, wie sieht das, wie sieht das grundsätzlich so mit, mit Plugins aus? Ist es in der Regel dann so nach dem, nach dem gleichen Verfahren, dass, viele Dinge einfach nur erweitert werden?

So sollte es im Idealfall sein. Dass also alle schön aufeinander aufsetzen.

Die Realität ist ein bisschen eine andere, oder?

Mh, ich steck da jetzt nicht so tief drin, dass ich das beurteilen könnte. Ich bastel meistens meine Sachen, meine, meine, meine Plugins selbst. Also es gibt, es war auch so, müssen wir auch mal einführen: Mootools hatte lange Zeit eine etwas, also die Macher haben sich nicht so sehr darum geschert, was die anderen so denken. Bei jQuery weiß man, da gibt's Foren, Tutorials en masse und Bücher und was nicht alles. Das, gab's bei Mootools alles nicht. Gibt es nicht.

Denen ist mal das Forum kaputtgegangen, dann haben sie es einfach kaputt liegen gelassen, weil, hey, weniger Arbeit für uns. Super. Das gibt's so alles nicht. Und deswegen, wo war ich stehen geblieben? Gab's lange Zeit so keine, etablierte Plugin-Kultur. Das hat sich geändert. Und da ist das durchaus schon so, dass die auf andere Sachen aufsetzen. Meistens setzen die halt auf Sachen auf, die schon im Core oder More sind, weil das sozusagen der Kanon ist.

Theoretisch kann ich natürlich mir auch, was wahrscheinlich das realistische Szenario ist: Ich nehme irgendein Plugin aus dem offiziellen Plugin-Verzeichnis, also nicht aus Core oder More, also nicht aus den beiden offiziellen Komponenten, und erschaffe mir mein eigenes, indem ich sozusagen das Plugin nicht modifiziere, nicht hacke, sondern wiederum erweitere.

Ist denn die, angesprochene Plugin-Kultur inzwischen so weit ausgebaut, dass man da so für die, für die klassischen Anliegen, die man so hat, ja, Hilfe findet?

Also neunzig Prozent von dem, was man, wirklich braucht, so im Tagesgeschäft, das ist eigentlich abgedeckt durch die, Core- und More-Bibliotheken. Also Core, wie gesagt, bietet die Basis. Da gibt's auch schon ein paar Effekte drin, also für so Sachen wie einblenden, ausblenden und ein bisschen animieren. Da ist alles drin. Und in More, More ist sozusagen die etwas erweiterte, Bling-Bling-Fraktion drin.

Da gibt's also schon ein paar ausgebautere Effekte und, Sachen, um zum Beispiel Formularvalidierung zu betreiben. Solche Sachen, sind nicht mal so irgendwelche Plugins aus der Community, sondern das ist schon, im Kernsystem drin.

An der Stelle wahrscheinlich auch noch mal ein Vorteil gegenüber jQuery. Also gut, da hat man noch jQuery UI, was ja auch nicht von irgendwo herkommt, aber besonders wenn's dann so an Validatoren geht und so weiter, da steht man dann vor, den vielen, vielen Möglichkeiten, die einem die Community so bietet und die müssen nicht unbedingt immer, so wirklich schön sein.

Genau, das Gute an dem MooTools-Teil ist, an dem MooTools-Validator, nicht dass ich den schon mal benutzt hätte, aber, der ist in sämtlichen Sprachen, die man sich vorstellen kann. Da ist von, Katalanisch bis was weiß ich alles dabei und das ist wie gesagt offiziell gepflegt. Also MooTools More und Core Team sind schon irgendwo getrennt.

More sind halt so die, Leute, die also wirklich die Effekte und dieses ganze Bling Bling nach außen bauen und im Core Team sind so Sachen, sind so Leute, die eben wirklich dann so ganz an der Basis eben überlegen, was braucht jetzt so das Objekt String für neue Methoden und solche Sachen. Aber der gesamte Oberbau ist also schon quasi offiziell. Kann man so sagen.

Was gehört dann zu den zehn Prozent, die nicht bedient sind?

Die zehn Prozent, die nicht bedient sind, da gibt es jetzt seit Neuestem, 'ne offizielle Plugin-Schnittstelle. Also wie gesagt, früher haben die sich alle überhaupt nicht darum geschert. Da kommt auch so 'n bisschen dieses, dieser Stereotyp her, die MooTools-Community sei unfreundlich oder was. Gab einfach keine, weil sich darum keiner gekümmert hat. Mittlerweile ist das also aber, in die Hand genommen und es gibt dieses offizielle Plugin-Verzeichnis, was relativ jung ist.

Deswegen ist da noch nicht so wahnsinnig viel drin, aber es wird halt ständig mehr.

Hast du 'n, 'n Beispiel für etwas, was, wo halt die neunzig Prozent Core und More nicht mehr ausreichen?

Das sind dann meistens so spezielle Effekte wie zum Beispiel, solche, solche Slideshows zum Beispiel. Das ist 'n bisschen so 'ne Frage, ob man so, ob so was irgendwie in die Kern, in die Kernkompetenz einer Bibliothek reingehört. Da würd ich nämlich wirklich auch eher sagen, eher nicht. Das ist dann wirklich was, was, was so 'ne Plugin-Geschichte sein müsste. Also so Sachen wie 'ne Lupenfunktion oder 'n Zoomer und solche Geschichten. Ja.

Die findet man dann eben in diesem, in diesem Community-Verzeichnis. Das ist, relativ gut cool, weil das, das ist mit GitHub verzahnt. Also GitHub kennt man vielleicht, das ist dieser, Code-Hosting-Service, der da mit dem Versionskontrollsystem Git verzahnt ist. Und die, MooTools-Plugin, dieses MooTools-Plugin-Verzeichnis, die Forge, ist wiederum mit GitHub verzahnt.

Das heißt, wenn also mal eines Tages Folgendes passieren könnte: Mein allerwichtigstes Plugin, wird nicht mehr geupdatet, weil der Besitzer von einem Bus überfahren wurde. Dann kann ich zu GitHub gehen.

Todales Beispiel.

So was soll vorgekommen. Dann geht man einfach zu GitHub, forkt das Repository, hat den Code direkt da, holt sich das mittels Git auf den heimischen Rechner und, dann geht's nicht mehr verloren, dann kann man das ausbauen.

Also diese ganze, dieses ganze GitHub hängt da im Prinzip mit dran und das ist 'ne ziemlich praktische Sache, wenn man so meint, das Plugin ist gut, das wird aber jetzt nicht mehr weiterentwickelt oder entwickelt sich in die falsche Richtung und ich will da nicht einfach nur meinen Klassenaufsatz haben, sondern meine eigene, Variation dessen bauen. Dann geht das darüber sehr gut.

Ist natürlich auch jetzt für Leute, die jetzt nicht mit, Git und GitHub so fit sind, 'n bisschen schwierig, 'n Plugin einzustellen. Da ist jetzt die Frage, ob das gut ist oder schlecht. Ich bin mir noch nicht sicher.

Ich glaub, die Vorteile von Git und GitHub überwiegen da den, die Einstiegshürde.

Ja, vielleicht ist es ja auch gar nicht so verkehrt, dass da eine gewisse Einstiegshürde ist. Ich weiß nicht, wie die jQuery-Plugins sind, aber die meisten, die bei MooTools hier ankommen, sind von 'ner gewissen Qualität, muss man sagen. Da hab ich jetzt noch keins gesehen, wo ich mir jetzt unmittelbar an den Kopf greifen müsste.

Und, selbst wenn man, also wenn man dann an den Punkt kommt, wo man, lustig ist und, so was schreiben will, dann sollte man sich sowieso meiner Meinung nach, mal mit Git und GitHub, also auf jeden Fall mit Git beschäftigt haben. Ist nämlich 'ne super Sache an der Stelle.

Ja, definitiv. Und vor allen Dingen, es gibt auch, also Plugin einstellen ist wirklich schwierig. Die verlangen, dass man, 'ne ordentliche Dokumentation anlegt. Wenn man 'n Plugin hat, was nicht ordentlich dokumentiert ist, ist es nicht möglich, das einzutragen. Das wird technisch verhindert. Ist das gut oder schlecht? Ich find das ziemlich gut.

Ich find, das hört sich auch erst mal ziemlich gut an.

Da kann man auch direkt die Demos, glaub ich, drauf hosten und all solche Sachen. Das ist ziemlich cool, aber es ist wie gesagt noch relativ neu, deswegen noch nicht so besonders gut gefüllt, aber ich merk schon, ich hab da vorhin ein bisschen drauf rumgescrollt, das wird, wöchentlich, wächst das und wächst das und wächst das. Und ist einfach, denk ich mal, für die, für die Entwickler auch sehr komfortabel zu bedienen. Das wird also schon noch.

Ich würd gerne noch mal kurz springen. Hat MooTools jetzt eigentlich MooFX, die Geschichte, bei der ich damals irgendwie 2006 oder so auch eingestiegen bin, komplett abgelöst oder gibt's das noch?

Das, gibt's noch. Also das wird zumindest noch, zum Download angeboten.

Ist aber-

Entwickelt wird das, glaub ich, nicht mehr.

Und hat dann auch nicht mehr wirklich viel mit MooTools dann zu tun und ist irgendwie nicht irgendwie, also...

Na ja, alles, was mit MooFX ging, geht jetzt auch mit MooTools. Insofern ist die Frage. Und andersherum, Prototype hat, glaub ich, meines Wissens an, seiner Performance und so fleißig gearbeitet. Da ist die Frage: Braucht man das noch?

Okay. Ja, was gibt's sonst noch so zu MooTools zu sagen, was man wissen müsste?

Es gibt mittlerweile, also es wächst da drumherum eben, also die Community ist jetzt im Wachsen, nachdem das halt-- Das schneiden wir.

Tun wir das?

Tun wir. Also die Community ist, im Moment sehr im Wachsen, nachdem das halt, meine Einschätzung, lange Zeit ziemlich vernachlässigt wurde. Deswegen schießen im Moment, die Bücher und die Tools und all solche Sachen aus dem Boden. Was 'ne relativ coole Einrichtung ist, wie ich finde, ist die Moo Shell. Das ist sozusagen 'ne, kleine Sandbox.

Findet man auf mootoolsnet/shell, wo man sozusagen, ja, Code ausprobieren kann, wo man drin rumspielen kann, wo man dann seine Rumspielereien auch speichern kann und, verlinken kann oder auf seiner eigenen Seite einbetten kann. Solche Sachen sind ganz praktisch. Und, was jetzt vielleicht, um auf jQuery zurückzukommen, noch 'ne Erwähnung wert ist: Letztens hat jemand jQuery als Mootools-Plugin implementiert. Also wenn man auf so was steht, geht das auch.

Das ist allerdings dann schon mal ein ziemlich komisches Konstrukt und da möcht ich so ein bisschen an, an der Sinnhaftigkeit doch zweifeln.

Ja eben, wo wir schon gesagt haben, es sind ja eigentlich zwei unterschiedliche, mm, Richtungen, auf die das jetzt abzielt. Ob man das jetzt braucht, kann man drüber nachdenken.

Vor allem hat man dann, redundanten Code, der sich gewaschen hat, weil, also da ist ja dann wirklich alles, zwei und dreimal abgedeckt. Ich,, sach ja eigentlich schon immer, dass man sich überlegen sollte, ob man jetzt wirklich für einen Effekt auf einer Seite ein komplettes Framework einbinden will, dann aber gleich zwei, ist noch mal eine andere Frage.

Tja, man kann ja event-- Man könnt's ja eventuell so machen, dass man von Mootools nur die Kla, die, die Basis nimmt, die ausreicht, um jQuery als Klasse zu implementieren.

Dann ist das schon gar nicht mehr so dramatisch. Na, aber, vergessen wir das. Ist halt eine nette Spielerei, dass halt so was geht.

Alles klar.

Ja, aber die Sache ist halt, letztlich die, dass solche Sachen halt gehen, ist eben das Tolle. Und dieses ganze Klassensystem ist wirklich das, wo man, wo man sozusagen den gedanklichen Sprung machen muss. Man kann in Mootools im Prinzip genauso arbeiten wie in jQuery Dollar irgendwas, Punkt dies, Punkt jenes, Punkt mach. Nur da hat man nichts von, wenn man das so macht. Dann sollte man lieber gleich jQuery nehmen, weil das ist dafür gebaut.

Mit Mootools, wenn man dann wirklich anfängt, jede Kleinigkeit, die man bastelt, in eine Klasse zu, zu packen. Also die Faustregel ist, wenn irgendwas mehr als fünf Zeilen hat, mach eine Klasse draus, dann sind's zwar fünfzehn, okay, aber dann kann man das halt hinterher, verwenden, in andere Klassen implementieren oder andere Klassen darauf aufsetzen lassen.

Und wenn man das so ein bisschen macht und seine Plugins dann auch wirklich, das ist die zweite große Herausforderung, an der es bei mir lange scheiterte, wenn man die dann wirklich sammelt und ordentlich archiviert, am besten bei GitHub und ins Mootools-Plugins-Verzeichnis einstellt, dann spart man dahin auf lange Sicht wirklich Arbeit, weil man es dann so hat wie ich bei meinem Kunden am Montag, wo ich dem dann, ordentlich was werde aufschreiben können, aber in fünfzehn Zeilen fertig sein werde.

Dann hoffen wir mal, dass der nicht mithört.

Er soll ruhig mithören. Wenn ich, wenn ich solche fortschrittlichen Tools verwende, macht das bestimmt einen ganz tollen Eindruck. Außerdem glaube ich nie, wirklich nicht, dass der zuhört.

Vor allem nicht mehr, bei Minute siebenundzwanzig wahrscheinlich.

Man weiß es nicht.

Okay, ja. Hast du noch was, was, was die Welt wissen muss?

Guckt euch die Links an. Es gibt ein Mootools-Tutorial, was mit Hallo Welt anfängt. Ich weiß nicht, ob das jetzt für den geneigten JavaScript-Nicht, -Experten was bringt. Ich kann's auch nicht beurteilen. Das gibt's neuerdings auch in Form von toten Bäumen. Kann man sich angucken. Und, ja, gebt ihm eine Chance, wenn ihr JavaScript könnt. Wenn nicht, bleibt bei jQuery, weil dann ist das genau das Richtige.

Wir hatten im, im Vorhinein auch noch mal über die toten Bäume, bezüglich, allgemein JavaScript, gesprochen. Jetzt mal angenommen, das, was du jetzt, hier eine halbe Stunde erzählt hast, macht jetzt jemanden so heiß, dass er total Bock hat, von, jQuery auf Mootools umzusteigen oder generell bei Mootools einzusteigen, ist allerdings eigentlich gar nicht mit JavaScript irgendwie konform. Was tun?

Keinesfalls googeln. Ganz schlechte Idee. Es gibt, glaube ich, insgesamt zwei gute Bücher zu JavaScript. Der Rest ist alles Käse, weil da all so Sachen drin vorkommen. Also man weiß, man kennt vielleicht am ehesten auch als JavaScript-Nichtnutzer vom Douglas Crockford das Buch, JavaScript: The Good Parts. Und was jetzt, das kann man jetzt lustig finden oder nicht, dass das, dass das keine hundert Seiten dick ist und dass die Hälfte davon auf, RegEx einfällt. Geschenkt.

Das ist eins von den guten Büchern. Ist aber also insofern halt, dass das einem sagt, welche Sachen man vermeiden sollte, weil eben JavaScript seinerzeit mehr oder minder, mit heißer Nadel gestrickt wurde und eben voller Fußangeln ist. Wenn man das jetzt wirklich, mal, von der Pike auf lernen möchte, da gibt's, von O'Reilly eins, JavaScript: The Definite Guide. Das ist so eins, das ist, glaube ich, türkis mit einem Rhinozeros drauf.

Das ist halt wirklich dann so ein, das, das Buch für, für den Fall von der Pike auf. Das ist dick und kostet vierzig Euro. Wenn man das für eine sinnvolle Investition hält, kann man ja mal gucken.

Gibt es inzwischen oder ist dir bisher ein, ein Mootools-Buch untergekommen, das, lesenswert ist?

Es gibt eins, das hatte ich auch vor, einiger Zeit mal im, in meinem Blog verlinkt. Das ist auch von dem Autoren des, Mootorials, also von dem, einem, guten Tutorial, was es halt gibt, was eben bei Hallo Welt, anfängt. Und das Buch ist insofern ein, für Einsteiger sinnvoll, dass es halt, auch mit diesem Hallo Welt anfängt, aber, man könnte kritisieren, dass es eben relativ nah an der Oberfläche dran bleibt.

Das heißt so wirklich in die Tiefe tauchen, wo man dann mit diesen ganzen Klassen wirklich das aus Mootools rausholt, was man haben möchte, wo, wo man die Vorteile gewinnt, das kommt da eher weniger vor. Da geht's halt mehr so um schnell mal einen Effekt, schnell mal einen Ajax-Request, den Aha-Effekt erzeugen. Legitimes Anliegen. Ich frag mich halt nur, ob es das Ziel von Mootools ist. Meiner Meinung nach eher nicht. Aber, man kann ja mal gucken.

Mootools, Beginner's Guide heißt das ganz einfach.

Die zwei, drei Werke werden wir auch auf jeden Fall noch mal sehr, komfortabel verlinken.

Das müssen wir auf jeden Fall tun. Aber wie gesagt, also JavaScript lernen finde ich, ist glaube ich trotzdem, trotz und alledem trotz jQuery, Mootools und was es noch so alles gibt, eine gute Idee. Ich glaub, das, werden wir Jetzt und in Zukunft sicherlich, immer mehr brauchen für alle möglichen Anwendungsfälle.

Dein Wort in, Gottes Munde.

Ich glaub nicht, dass Gott damit viel zu tun hat. Aber die Sache ist halt zum Beispiel auch die, auch wieder was, wo man jetzt Mootools einbringen kann. Im Moment explore ich ja die Entwicklung von, serverseitigem JavaScript. Da gibt's ja allerlei lustige, neue Entwicklungen. Node.js ist jetzt ja vielleicht die bekannteste.

Und das Gute an Mootools ist, man kann Mootools eben auch für so Serversachen einsetzen, weil es eben in seiner Kernform ohne dieses ganze DOM- und Effekt-Gebimsel, wirklich die JavaScript-Basisobjekte erweitert. Wenn man jetzt also sich jetzt sagt, die, Array-Behandlung von Mootools, diese ganzen neuen Funktionen hätte ich da auch ganz gerne. Bitte schön, die gibt's. Gibt sogar eine extra Serverdistribution zum Runterladen. Dafür ist das halt auch ganz nützlich.

Wir springen heute ganz schön, oder?

Wir springen ganz schön, aber ich glaub, wir haben auch ein bisschen was oder beziehungsweise du vor allem hast auch ein bisschen was an Inhalt rübergebracht.

Das will ich doch hoffen.

Ja, dann, würde ich sagen, wenn du nicht noch irgendwas aus dem Hut zauberst.

Ist glaube ich nix mehr drin.

Ist nix mehr drin?

Nein.

Dann, danke ich dir an dieser Stelle und, ich glaub, wir wünschen dann viel Spaß beim Ausprobieren.

Das wünschen wir auf jeden Fall. War mir ein Vergnügen.

Dann, bis es demnächst.

Tschüss.

Adios.

Mehr Qualität im Webdesign durch Webstandards. Tipps und Tricks zur Umsetzung findet ihr bei den Webkrauts auf Webkrauts.de. Für ein besseres Web.

Weitere Informationen und die Links zur Sendung auf technikwürze.de.