Optimierte JavaScript Anwendungen mit erweiterten Debugging-Möglichkeiten

Im Firmenblog habe ich einen Artikel unter dem Titel Optimierte JavaScript-Anwendungen mit erweiterten Debugging-Möglichkeiten veröffentlicht.

Es sollte mittlerweile in jeder halbwegs ernsthaften Webanwendung gängig sein, dass das JavaScript nicht as is ausgegeben wird, sondern in einer optimierten Variante. Dabei wird in der Regel auf eine Kombination aus Konkatenation und Minifizierung zurückgegriffen.

In diesem Artikel stelle ich eine Möglichkeit vor, dies in einem Java-Projekt mit Spring einzusetzen. Als Builder wird Maven und als JS-Compiler wird der Google Closure Compiler verwendet. Als Boni werden die Source Maps in der Konbination mit Google Chrome vorgestellt. Grundsätzlich sind einige Werkzeuge zum Teil auch ohne Java oder Spring einsetzbar — Google Closure Compiler ist zwar in Java geschrieben, aber als JAR verfügbar und universell per Executable steuerbar.

jQuery AutoSuggest v2 (pre) – oder: Heißer Scheiß mit grunt, coffee, sass, github und travis

In einer bislang nur als Pre-Release verfügbaren Version 2 gibt es nun von mir das jQuery Plugin AutoSuggest auf GitHub. Das Plugin basiert weitestgehend auf der Version von Wu Yuntao, welcher aber die aktuell verfügbare Version 1.6 nicht mehr wirklich zu pflegen scheint. Ursprünglich wurde das Plugin 2009 von Drew Wilson entwickelt. Das dortige Plugin dort wurde das letzte mal im März 2010 in der Version 1.4 veröffentlicht.

„jQuery AutoSuggest v2 (pre) – oder: Heißer Scheiß mit grunt, coffee, sass, github und travis“ weiterlesen

jQuery 1.8 / 1.9

Das jQuery Project hat einen Blogpost rausgehauen, der die erste Beta von jQuery 1.8 vorstellt. Gleichzeitig wird aber auch ganz allgemein darauf hingewiesen, was sich in den Version 1.8 und 1.9 ändert wird.

Im Großen kann man das zusammenfassen (API-relevant):

  • jQuery wird modular, d.h. man kann angepasste, kleinere Varianten bauen
  • Deprecated-Marker für  Zeug wie: $.browser, $.sub, jqXHR.success, jqXHR.error, jqXHR.complete (seit 1.5 durch Deferred). In 1.9 verschwindet es dann, und ist dann nur noch über das spezielle 1.9er Kompatibilitätsplugin erreichbar

Der Blogpost zeichnet auch noch die Built-in Fähigkeit aus, das jQuery nun sowohl automatisch Vendor-Präfixe nutzt und Animations besser unterstützt. Ob damit so etwas wie jQuery++ Animations gemeint ist?

Feature Detection, my ass!

Ein Tag wie jeder andere „im IE funktioniert die Anwendung nicht mehr, nichts lädt mehr“. Man ist es ja eigentlich gewohnt, zumal es sich hierbei ja um eine umfangreiche RIA in Ext JS handelt. Trotz laufender JSLint-Überwachung für Fehler wie trailing comma mogelt sich immer mal wieder ein Problem herein. Ungewöhnlich war diesmal allerdings, dass bei der weiteren Untersuchung auffiel, dass das Problem auf einem IE9 auftrat (Hut ab vor Microsoft, IE9 ist eigentlich sehr gut). Ein Gegencheck in der VM mit IE6 und IE8 zeigte das Verhalten nicht. Auch die Prüfung auf einem realen Windows 7-System mit IE9 war problemlos.

Nun ja, genauer gesagt, das Problem trat auf einem (Test-) Windows Server 2008 mit IE9 auf. Aha..?

Nach einem schnellen Aufschalten auf den Testserver und dem Aufruf der Debugging-Tools offenbarte, dass der IE9 an genau einer Stelle auf Nase flog: aAudio=“Audio“in window?new Audio(„“):{} Im Prinzip ein ganz normale Art und Weise, eine Feature Detection durchzuführen. Für diejenigen, die nicht in JavaScript firm sind: Die Variable aAudio wird, falls im Objekt window eine Eigenschaft Audio vorhanden ist, mit einer neuen Instanz eben dieser Audio-Klasse belegt, andernfalls mit einem leeren Objekt (hilfreich ist hierbei zu wissen, dass window der Standardscope ist).

Das heißt also, nur wenn der Browser die HTML5-API „Audio“ kann, wird auch eine Instanz davon erstellt. Weiter später wird im Script auf eine spezielle Eigenschaft/Methode dieser Variable geprüft: Damit lässt sich dann feststellen, ob HTMl5-Audio implementiert wird (hier: canPlay). Das gesamte Problem gilt natürlich auch analog für die HTML5-API des Tags video.

Eine Exception „Not implemented“, die nicht aus der Anwendung kam, nicht aus dem Framework und auch nicht aus dem Plugin, welches im Endeffekt diese Zeile beinhaltet, wurde geschmissen und stoppte die gesamte Anwendung bzw. das verursachende Script. Und genau diese Zeile war die Feature Detection für HTML5-Audio in einer Sammlung von Flash/Video/Audio-Funktionalitäten.

Lange Rede, kurzer Sinn: Der Internet Explorer 9 hat u.a. die HTML5-APIs für Audio und Video implementiert — eigentlich. Nicht jedoch auf einem Windows Server 2008, denn dort wird dafür ein optional zu installierendes Feature — so called Desktop Experience Feature — des Betriebssystems benötigt. Und damit das ganze auch richtig gegen die Wand fahren kann und muss, tut man (der Browser) erstmal so, als würde er HTML5-Audio anbieten können (API window.Audio gibt es!), schmeißt dann aber eine Exception, wenn man das Objekt tatsächlich nutzt.

Tatsächlich ist die einzige Lösung, dies mit einem billigen try-catch zu lösen. Eine Post-Recherche ergab, die Macher von Feature-Detection-Framework Modernizr haben das genauso gemacht.

Es hat sich in den Jahren nicht viel geändert: Sonderwürste für den IE stehen weiterhin an.

Hintergrund – oder: Die Sache selbst

Eine granulare Feature Detection ist heutzutage bei modernen Webanwendungen oder besser -frameworks quasi Pflicht. Hat man früher noch eine grobe Browser Detection (Browserhersteller und -version) vorgenommen, um daraus herzuleiten, ob Feature X unterstützt wird, so prüft man heute besser auf dieses Feature direkt. Erstens sind die Features unzählig mehr geworden, zum anderen benötigt das das „Wissen“, welcher Browser welches Feature kann. Außerdem ist es mit den modernen Workingdraft/Livingstandard-Trends quasi unmöglich geworden, Features zu bestimmten Browsern zuzuordnen. Chrome und Firefox aktualisieren sich mittlerweile  mehr oder weniger selbstständig; und überhaupt ist die Geschwindigkeit der Browserentwicklungen so schnell geworden, dass eine Browser-basierte Herleitung von Feature-Verfügbarkeiten schwierig wird. Ein ganz gutes Beispiel ist HTML5 — denn HTML5 ist als Standard weder komplett fertig, noch in einem/jedem Browser gleichwertig implementiert.

In der Regel läuft eine Feature-Detection wie folgt ab: Man prüft, ob die Voraussetzungen bspw. für einen Tag oder eine DOM-API-Funktion vorhanden ist und ermittelt gegebenenfalls noch weitere Ausprägungen.

Beispiele

  • navigator.geolocation ist nicht undefined, wenn der Browser die Geolocation-API kann.
  • document.createElement(‚canvas‘).getContext ist nicht undefined, wenn der Browser Canvas-Tags unterstützt und damit Canvas zeichnen kann.
  • document.createElement(‚audio‘).canPlay ist nicht undefined, wenn der Browser HTML5-Audio-Tags unterstützt und demnach HTML5-Audio abspielen kann.

Weitere Links

CSS3: SASS, Compass und PIE

Nach einer längeren Pause gibt es heute ein paar kurze Notizen zum Thema CSS3 und Internet Explorer.

Aber der Reihe nach.

SASS

So schön CSS ist, so alt und stupide ist der Spielraum zum entwickeln und konzipieren. CSS kann keine Vererbung, keine Strukturierungen, keine Kapselungen bzw. Mixins. Das einzige, was CSS kann: eine Aneinanderreihung von Tags, bspw. #element ul > li

Mit SASS ist das alles möglich. Es sind hierarchische Strukturen möglich, man kann Mixins (Kurzanweisungen für ein Set von Funktionen/Attributen, Stichwort: Browser-Cross-Features) oder endlich Variablen im CSS nutzen. Der Code-Syntax ist dabei eine Erweiterung von CSS3* (d.h. CSS selber ist weiterhin möglich) und wird üblicherweise in .scss-Dateien abgelegt. Jedes öffentlich zugängliche Stylesheet muss dann in ein „normales“ CSS umgeschrieben werden, das erledigt SASS wahlweise auf Knopfdruck oder mit einem Watchdog (Befehl watch). Mit letzterem geschieht die Generierung on-the-fly, d.h. man kann zwischen SCSS und Browser genauso wechseln wie beim guten alten CSS.

* So lange man natürlich kein CSS3 nutzt, ist man auch CSS2 kompatibel.

Compass

Als Erweiterung für SASS gedacht, erweitert Compass das Funktionsspektrum um einige hilfreiche CSS(3)-Features. Die Referenz zeigt stets den aktuellen Stand und auf GitHub sind die Sourcen offen zugänglich. Um beispielsweise die mittlerweile zahlreichen (6!) vendor-spezifischen Anweisungen eines linearen Gradienten (hier: weiß zu schwarz) zu erzeugen, reicht das simple Mixin linear-gradient(color-stops(white, black)).

Nett: Als Pull bekam das Projekt auch schließlich einen experimentellen Hack, damit Gradienten out-of-the-box im IE6-8 funktionieren. So funktioniert Open Source.

PIE

CSS3PIE ist eine winzige Library, die in Form einer HTC (so genannte HTML Components, eine microsoft-spezifische JavaScript-Datei) weitestgehend die CSS3-Features border-radius, box-shadow und linear-gradient bereitstellt.

In Compass ist PIE optional verfügbar. Mit der Ergänzung einer Zeile SCSS-Code ist damit ein runder, schattierter Button real.

Beispiele

Da war noch was…

CSS3PIE wurde dieses Jahr ein Teil von Sencha. Da ist es nicht verwunderlich, dass Sencha selber für ihren Theme-Generator (Bestandteil der Sencha SDK Tools)  für ExtJS/SenchaTouch auf Compass, PhantomJS u.a. setzt.

SenchaCon

Sagte ich letztens, Sencha würde sich gut entwickeln? Die hauseigene SenchaConference ist gestartet, und die Firma hat erstmal kräftig auf den Putz gehauen. Es gibt nicht nur die finale Version SenchaTouch (quasi das ExtJS für mobile Plattformen inkl. UI), sondern direkt ein passendes Ext Designer Update zum entwickeln von Touch Anwendungen. Und auch einen Marktplatz für Entwickler/Kunden — den so genannten SenchaDev-Bereich. Ob der was taugen wird, das wird man später sehen.

Im Einzelnen: Ausgewählte Informationen per Copy-Paste aus dem @tdgi-Staccato:

  1. #SenchaCon ext designer to be moved to CSS, icon, template, theme and event mangers!
  2. #SenchaCon Web services: font, data image resizing and more, all from #senchainc.
  3. #SenchaCon #ExtJS 4has a brand new layout engine. Same API.
  4. #SenchaCon #ExtJS 4 has 4000 unit tests!
  5. #SenchaCon #ExtJS 4 is UI tested by a new tool called VisualQA. Awesome!
  6. #SenchaCon #ExtJS 4 most useful documentation ever. All classes documented.
  7. #SenchaCon #ExtJS 4 examples integrated into docs.
  8. #SenchaCon #ExtJS 4 upgrade guide available!
  9. #SenchaCon #ExtJS 4 API improvements, clears cruft. Standardizing naming, funcs conventions.
  10. #SenchaCon #ExtJS 4 new charting package. Bye bye flash!
  11. #SenchaCon #ExtJS 4: building complex forms are a lot easier!
  12. #SenchaCon #ExtJS 4: Record becomes Model. More complex data manipulation now possible.
  13. #SenchaCon #ExtJS 4: data associations are now going to empower a new level of application development!
  14. #SenchaCon #ExtJS 4: local and session storage APIs available.
  15. #SenchaCon Sencha Command is a way to start your apps.
  16. #SenchaCon #ExtJS 4: sencha command is automated by the model generator.
  17. #SenchaCon JSBuilder is tied into Sencha Command.
  18. #SenchaCon #ExtJS 4: that was beta in six weeks. Final is feb 28, 2011
  19. #SenchaCon #ExtJS 4: VisualQA will be open to end debs, release date unknown. Bye bye selenium, hellos new world of testing RIAs!

Eine neue Layoutengine hatte man bereits im Vorfeld leicht angekündigt; die Model-Neuerfindung ist auch nicht überraschend, da es bereits in SenchaTouch Einzug fand. Model Associations sind genial. Der Wegfall von Flash im Charting-Paket sollte auch nicht verwundern, schließlich hat man jetzt bereits zwei alternative Know-Hows in Form von Frameworks eingekauft.

Alles in allem hört sich das alles super an: Mehr UI-Testing ist speziell in einer RIA sehr schwierig und könnte durch geeignetes Framework-Hilfstool sicherlich um einiges besser machbar werden. Was sich genau hinter Sencha Command verbirgt bzw. welche Power es genau hat, wird man sehen.