Google JavaScript-Werkzeuge

Hallo Leute,

dies ist sicherlich für den einen oder anderen ganz interessant.

http://www.heise.de/newsticker/meldung/Google-gibt-JavaScript-Werkzeuge-als-Open-Source-frei-851937.html

Hi,

das ist ja schick. Das werd ich bei gelegenheit direkt mal ausprobieren :)

Original von Murmeli

Hi,

das ist ja schick. Das werd ich bei gelegenheit direkt mal ausprobieren :)

Auf Anhieb gefällt mir der "Closure Compiler" besser als der YUI-Compressor, zudem er - scheinbar - besser kompiliert. Irgendwer ebenfalls Erfahrungen? Leider hat er ein paar Probleme mit Codekommentaren (bzw. entsprechenden "JsDoc"-Annotationen).

Das Firebug-Plugin hat mich bisher funktional nicht überzeugt - wo ist da der echte Vorteil zu vorher? Abgesehen der offensichtlichen Tatsache, das er den minified/compressed Sourcecode über die Map-Dateien wieder "sichtbar" zu machen, habe ich da noch keine nennenswerten Unterschiede feststellen können.

Schaut nicht schlecht aus. Jetzt weiß ich allerdings überhaupt nicht mehr welches JavaScript Framework ich nehmen soll.

Am besten ein Framework dass schnittstellen zu allen Frameworks bietet, so kann man problemlos das Framework tauschen ;)

fein fein, muss ich mal ausprobieren...

Original von Kampfhoernchen

Am besten ein Framework dass schnittstellen zu allen Frameworks bietet, so kann man problemlos das Framework tauschen ;)

Ehrlich gesagt bin ich wirklich dabei einzelne Komponenten unabhängig von einem Framework zu schreiben. Falls ich dann mal ein Stückchen jQuery (immer noch mein Favorit) benötige gehe ich trotzdem einen Umweg über meinModul.tollerNameFuerBenoetigteFunktion, was ich dann halt in einer Art Konfiguration mit dem jQuery Feature belege. Das ließe sich aber leicht gegen ein ähnliches oder gleiches Feature eines anderen Frameworks austauschen..

Original von Kampfhoernchen

Am besten ein Framework dass schnittstellen zu allen Frameworks bietet, so kann man problemlos das Framework tauschen ;)

Beispiel: Der ExtJS Core (Base). Man hat die Wahl zwischen ExtBase, jQuery, Prototype und mW mootools.

Okay. Dann halt so. Spricht etwas gegen meine Auslegung? Dass das aufwendig bei Verwendung von vielen verschiedenen Features wird, das ist mir klar. Trotzdem macht es doch Sinn Module unabhängig von Frameworks zu entwickeln? Okay, das ist dann jetzt wohl OT, sehe aber nicht genügend Anlass, dazu einen neuen Topic aufzumachen...

@Phoscur:

Eine Abstraktion hat meist die Folge, dass du auf den niedrigste Funktionalität aller abstrahierten Frameworks gehen musst.

Ähnlich der Gleichberechtigung: Man senkt das Niveau soweit, bis alle die gleichen Chancen haben

Da man gute Frameworks auch parallel nutzen kann, hast du auch ein schönes Migrationsszenario, falls dir ein Framework eine bestimmte Funktionalität nicht mehr bietet.

Die 1-Mann-Abstraktionsschicht führt meist auch dazu, dass du zwar abstrahierst, aber so krass gegen ein Framework abstrahierst, dass es schwierig wird andere Frameworks zu abstrahieren. Allein deswegen, weil du dich während der Entwicklung meist nur mit einem Framework beschäftigst.

Ich persönlich würde es lassen.

Zwiebelbauen ist nicht sonderlich sinnvoll...

Ansonsten würde ich mir auch noch eine Meta-Sprache entwickeln, die dein Skript automatisch in PHP|Perl|Ruby umformt, so dass du auch die Programmiersprache bei Bedarf wechseln kannst ;-)

Zusammengefasst:
Durch Abstraktion sammelst du meist alle Nachteile aller Abstrahierten und verzichtest auf Alleinstellungsmerkmale.

Okay, bevor du mich jetzt für meine Idee verurteilst, hier wie ich das gemacht habe.

JavaScript:

// configuration example with jQuery and the language-getter I've written
Template.Getter.request = jQuery.get; // function (url, callback)
Template.transform = jQuery; // function(html).appendTo(node)
Template.getLang = getLang; //
Template.Exception = Exception;

Bisher ist das in einem Rahmen, wo man jQuery leicht austauschen könnte, wobei man einen vielleicht einen kleinen Adapter zwischenschalten muss.

Zudem habe ich ja gar nicht vor die Idee auszureizen. Wenn ich ein spezielles Framework verwenden will, das mache ich das auch ohne Rücksicht ob Austauschbarkeit.

Diese Idee bietet aber auch noch einen weiteren Vorteil: Man kann eigene Methodennamen bestimmten, die besser zum Kontext passen.

Das sind aber alles Ideen der JavaScript-Erfinder und nicht deine :P

Aha? Dann tut es mir Leid, dass ich sie als meine bezeichnet habe. Abgeschrieben hab ich das allerdings nirgends.. Kannst du dich expliziter ausdrücken?

Als Abstraktion würde ich das nicht bezeichnen.

Höchstens als Schnellzugriff/Shortcut auf die Methoden.

Eine gute Abstraktion abstrahiert unter anderem die Methodensignatur. Das tust du nicht. Du gehst davon aus, dass alle Frameworks die gleiche Methodensignatur besitzen.

http://de.wikipedia.org/wiki/Methodensignatur

Original von Phoscur

Aha? Dann tut es mir Leid, dass ich sie als meine bezeichnet habe. Abgeschrieben hab ich das allerdings nirgends.. Kannst du dich expliziter ausdrücken?

Naja du kapselst einfach Funktionspointer in ein JS Objekt. Das ist ein Feature der Sprache und sehr Ideenreich ist das jetzt irgendwie nicht *g*

Ich würde auch nicht daherlaufen und sagen hey ich hab eine tolle Idee: Anstatt überall den Wert 5 zu schreiben benutz ich einfach eine Konstante mit dem Wert 5. Ist halt ein Sprachfeature, mehr nicht.

Eine echte Abstraktion hättest du, wenn dein Objekt eine eigene API zur Verfügung stellt, welche wiederum die konfigurierten Frameworks aufruft. Z.B. Template.DOM.animateMyObjectAlongAPath(obj, pathObj) , und diese Funktion ruft widerrum die entsprechenden jquery oder scriptaculous etc funktionen auf.

Ich soll einen Adapter (oder eben eine Abstraktionsschicht) schreiben, obwohl ich noch gar keinen brauche? Die Methodensignatur lässt sich doch leicht ändern in JavaScript (ja buhrmi, wenn du das meinst mit den Ideen der Entwickler, dann hast du wohl recht).

Hatte ich das jetzt als geniale Idee angepriesen oder warum müsst ihr deshalb so rumflamen?

Was ihr vorschlagt, ist dass ich quasi eine eigene andere API für DOM, Effekte etc. zwischenschalten könnte? Yeah, just another API to learn. Da nehme ich lieber die selben Methodensignaturen wie jQuery und schreibe ein paar Adapter, wenn ich denn doch wechseln will.

Das Konstrukt hat auch noch einen Vorteil: Die Module können gleichzeitig geladen werden um erst danach verknüpft zu werden. Man könnte sogar zur Laufzeit das Framework tauschen, wofür auch immer das gut sein sollte^^.

ok