wordpress-backbonejs-underscorejs

WordPress 3.5: Willkommen Backbone.js und Underscore.js; Adios Prototype und script.aculo.us

Während des gestrigen Entwickler Chats waren die JavaScript Bibliotheken in WordPress großes Thema.

Zum einem wurde jQuery 1.8, welches mittlerweile 3 Wochen auf dem Markt ist, für den Core abgesegnet. Zudem wurde auch jQuery UI auf die stabile Version 1.8.23 aktualisiert.

Backbone.js und Underscore.js

Backbone.js ist ein Model-View-Controller (MVC) Framework für JavaScript. Die Bibliotheken bieten eine solide Basis für objektorientierte Programmierung und simulieren etliche Hilfsfunktionen und eine erweiterbare Klassenhierarchie.
Dieser Vorteil ermöglicht das organisieren der Daten und die saubere Trennung zwischen Daten und Logik.
Mit der integrierten Template-Engine kann das HTML-Markup und die Logik sauber voneinander getrennt werden.

With Backbone, you represent your data as Models, which can be created, validated, destroyed, and saved to the server. Whenever a UI action causes an attribute of a model to change, the model triggers a “change” event; all the Views that display the model’s state can be notified of the change, so that they are able to respond accordingly, re-rendering themselves with the new information. In a finished Backbone app, you don’t have to write the glue code that looks into the DOM to find an element with a specific id, and update the HTML manually — when the model changes, the views simply update themselves.

Backbone.js: Introduction

Underscore.js verspricht hingegen die Unterstützung von funktionalen Programmierkonstrukten für den Umgang mit Arrays, Collections und Objekten, wie zum Beispiel each, map, find, filter oder toArray.

Underscore is a utility-belt library for JavaScript that provides a lot of the functional programming support that you would expect in Prototype.js (or Ruby), but without extending any of the built-in JavaScript objects. It’s the tie to go along with jQuery’s tux, and Backbone.js’s suspenders.

Underscore provides 60-odd functions that support both the usual functional suspects as well as more specialized helpers. It delegates to built-in functions, if present, so modern browsers will use the native implementations.

Underscore.js: Introduction

Was will WordPress mit Backbone.js und Underscore.js?

Beide Projekte sind eine optimale Grundlage für sogenannte Single-Page Webanwendungen.
Eine solche Anwendungen findet man auch jetzt schon im WordPress Core.

Es ist der Theme Customizer (Live-Vorschau des Themes), der mit WordPress 3.4 eingeführt wurde.

In WordPress 3.5 wird es weitere Projekte geben, die auf diese Art umgesetzt werden sollen.
Dazu zählt der neue Media-Workflow samt den Dialogfenster, sowie die Umsetzung von Aktionen und Filtern für JavaScript, quasi add_action() bzw. add_filter() für JavaScript.

Den Grafiken folgen Prototype und script.aculo.us

Wie schon berichtet, hat WordPress sich von ungenutzten Grafiken befreit. Jetzt hat es auch die beiden JavaScript Bibliotheken/Frameworks Prototype und script.aculo.us getroffen. Kein großer Verlust, denn sie wurden schon länger nicht mehr genutzt.

Fallback für Plugins/Themes: Falls doch noch ein Plugin/Theme existiert, welches von den beiden Bibliotheken abhängig ist, werden die benötigten Skripte automatisch von der Google API eingebunden. Guter Schachzug meiner Meinung nach.

Ausschnitt aus der Funktion wp_default_scripts():

<?php
	// WordPress no longer uses or bundles Prototype or script.aculo.us. These are now pulled from an external source.
	$scripts->add( 'prototype', '//ajax.googleapis.com/ajax/libs/prototype/1.7.1.0/prototype.js', array(), '1.7.1');
	$scripts->add( 'scriptaculous-root', '//ajax.googleapis.com/ajax/libs/scriptaculous/1.9.0/scriptaculous.js', array('prototype'), '1.9.0');
	$scripts->add( 'scriptaculous-builder', '//ajax.googleapis.com/ajax/libs/scriptaculous/1.9.0/builder.js', array('scriptaculous-root'), '1.9.0');
	$scripts->add( 'scriptaculous-dragdrop', '//ajax.googleapis.com/ajax/libs/scriptaculous/1.9.0/dragdrop.js', array('scriptaculous-builder', 'scriptaculous-effects'), '1.9.0');
	$scripts->add( 'scriptaculous-effects', '//ajax.googleapis.com/ajax/libs/scriptaculous/1.9.0/effects.js', array('scriptaculous-root'), '1.9.0');
	$scripts->add( 'scriptaculous-slider', '//ajax.googleapis.com/ajax/libs/scriptaculous/1.9.0/slider.js', array('scriptaculous-effects'), '1.9.0');
	$scripts->add( 'scriptaculous-sound', '//ajax.googleapis.com/ajax/libs/scriptaculous/1.9.0/sound.js', array( 'scriptaculous-root' ), '1.9.0' );
	$scripts->add( 'scriptaculous-controls', '//ajax.googleapis.com/ajax/libs/scriptaculous/1.9.0/controls.js', array('scriptaculous-root'), '1.9.0');
	$scripts->add( 'scriptaculous', false, array('scriptaculous-dragdrop', 'scriptaculous-slider', 'scriptaculous-controls') );

Nebenbei: min.css/min.js für komprimierte Stylesheets/Skripte

Bisher wurden die unkomprimierte Stylesheets mit der Endung .dev.css kenntlich gemacht, analog bei den Skripten .dev.js.
WordPress 3.5 geht nun die typische .min Konvention ein, das heißt: Komprimierte Dateien bekommen die Endung .min.css/.min.js und die Unkomprimierten haben keinen Suffix mehr.

Vor WordPress 3.4:
Entwicklerversion: dateiname.dev.css
Komprimierte Version: dateiname.css

Mit WordPress 3.5:
Entwicklerversion: dateiname.css
Komprimierte Version: dateiname.min.css

Zum Thema

7 thoughts on “WordPress 3.5: Willkommen Backbone.js und Underscore.js; Adios Prototype und script.aculo.us”

  1. werden die benötigten Skripte automatisch von der Google API eingebunden. Guter Schachzug meiner Meinung nach.

    Saublöde Idee, meiner Meinung nach. Es gibt genug Artikel im Netz die dringend davon abraten z.B. jQuery von den Google-Seiten zu laden um quasi auf den neuesten Stand zu sein. Die wichtigsten Gründe hierfür sind Performance und die Tatsache das Projekte auch mal umziehen können.
    Ich hätte es wesentlich besser gefunden wenn benötigte Komponenten nachinstalliert werden könnten. Bei JavaScripten könnte man über die Dependencies gehen. Taucht eine Dependency auf die zwar nicht installiert, dafür aber bekannt ist ( z.B. Scriptaculous ), wird das Plugin/Theme deaktiviert und ein Hinweis auf fehlende Komponenten mit einer entsprechenden Quelle angezeigt. Ob die Quelle dann die WordPress-Seiten oder Google ist, kann man fallweise entscheiden. Zudem hätte der Benutzer dann die Wahl ob er sich für die von WordPress angebotene oder eine andere, ggf. ältere, Version entscheidet.

    Diese Technik hat sich bei vielen Softwaren bewährt. So könnte man dann auch mit anderen Teilen von WordPress verfahren. Das würde dann schon stark in Richtung Core-Plugins gehen.

  2. Da ich mich zuletzt sehr viel und gerne mit den beiden libraries auseinandersetze, freut es mich auf jeden Fall zu hören, dass sie auch ihren Weg in ein so populäres Produkt gefunden haben. Gibt es einen bestimmten Grund, dass die Wahl auf backbone gefallen ist, und z.b nicht auf die ebenfalls sehr populären angular.js, knockout.js oder ember.js?

  3. Da ich schon des Öfteren in einigen (Ruby on Rails-)Projekten backbone.js verwendet habe, kann ich die Entscheidung nur begrüßen, aber die Antwort auf Marcel seine Frage würde mich auch interessieren. ;)

  4. Ich habe nachgefragt und Daryl Koopersmith hat geantwortet. O-Ton:

    1) They’re simple. 4kb and 5kb minified, respectively.

    2) Underscore is wonderful for functional programming. We have many implementations of its various functions in our existing JS, and it’s incredibly useful independent from Backbone.

    3) Backbone is both the smallest and most mature MV* Javascript framework. The fact that its Views are basically just a convention is very important for us — it does not require us to alter our markup or lock us in to any one templating library/system.

    That last point is probably the most important one, and is what makes Backbone the most compelling choice, IMO. That, combined with its stability, the size of its community, and the willingness of the author to work with us.

    With the size of many of these things, another option was to roll our own. But then we would lose out on the community/widespread testing benefits.

    And when experimenting with writing my own, I found that I was writing conventions quite similar to those in Backbone.

    I realized that while we could get 80-90% of the way there in an initial implementation, we’d miss certain important edge cases which the Backbone community (or any mature library) has figured out over the past few years.

    So yeah. I’ve been following all of this for quite a while, and making a choice was a big deal to me. So far, I’m pleased with the decision.

  5. Danke dir und Daryl für die doch ausführliche Antwort :)

    Was ich auch an backbone.js so gut finde, ist die wie ich finde leichte & kurze Eingewöhnungszeit, die kompakte und gute Dokumentation und vor allem auch, dass es mit Coffeescript ohne Einschränkungen und großartige Konfigurationen nutzbar ist.

Leave a Reply