senäh

17senäh und so…

Allgemein, HTML/CSS/JS
03. Sep 2012
Kommentare: 0

Web Dev Rückblick für Juni/Juli

Kategorien: Allgemein, HTML/CSS/JS | 03. Sep 2012 | Kommentare: 0

Hallo Freunde der hilfreichen und überaus unterhaltsamen senäh Artikel. Wie ihr mitbekommen habt, hat Enno seit Ende Mai hier den Alleinunterhalter gespielt. Ich möchte mich überaus entschuldigen, dass ich euch vernachlässigt habe, aber ich habe auch ein paar gute Entschuldigungen:

  1. Mein Masterstudium frisst erstaunlicherweise weit mehr Zeit als der Bachelor zuvor. (Hätte ich nicht gedacht, da gleiche FH und so…)
  2. Habe ich im Frühjahr einen neuen Job angefangen, in welchen ich mich gerne voll reinhänge.
  3. Werde ich bald Papa! 😀 Und da ist man mit allerlei Vorbereitungen beschäftigt.

Da sich bis Mitte nächsten Jahres nichts daran ändern wird, muss ich zwangsläufig mein Bloggingverhalten ändern. Sad, but true. Denn gar nichts zu schreiben ist auch doof. Schließlich fängt Enno bald auch wieder seinen Master an! Deswegen begrüße ich euch zu Pipos Rückblick für Webentwickler. Es handelt sich hierbei ausdrücklich um keine feste Serie. Ich habe genug angefangene Serien, die ich nach jetzigem Stand nicht beenden kann 🙁 Stattdessen fasse ich mehrere kleine Themen eines oder mehrerer Monate zusammen. Es handelt sich dabei um geballte Learned Lessons, die ich in der Zeit gesammelt habe, ohne viel Firlefanz. Na das ist doch was!

Learned Lessons Aggregator

Warum überhaupt mein Wissen über verschiedene Themenbereiche mit euch teilen, wenn ich nicht ausführlich auf ein Thema eingehen kann? Ich bin in letzter Zeit Fan von sogenannten News Aggregatoren geworden. Ein News Aggregator sammelt News zu einem bestimmten Themenbereich ohne selbst News zu verfassen. Dadurch werden interessante Artikel aus vielen verschiedenen Seiten herausgefiltert und übersichtlich zusammengefasst. So kann ein Leser effizienter aktuelle Informationen zu einem bestimmten Bereich erhalten. Da aber die Artikel von unterschiedlichen Autoren kommen, können die Ansichten zu einem Thema verschieden sein. Eine sehr spannende Geschichte also. Ich möchte aber nicht einfach auf News anderer Autoren verlinken (dazu gibt es schon genug Seiten), sondern einfach Dinge, die ich in letzter Zeit gelernt habe, zusammenfassen und kurz kommentieren. Anschließend verlinke ich auf weiterführende Quellen. Schließlich kommt mein Wissen auch nur aus diesen Quellen und die haben mehr Kompetenz in dem Bereich als ich 😉 Ich bin für euch nur ein Ideengeber und eine Inspirationsquelle 🙂

Welche News Aggregatoren ich nutze?

Mobile Development ist eine Qual

So langsam lernen wir damit umzugehen, wie man mehrere verschiedene Desktopbrowser bedient, da tauchen auf einmal Smartphones und Tablets in Hülle und Fülle auf. Noch mehr verschiedene Betriebssysteme, noch mehr verschiedene Browser. Und auf einmal ist sie wieder da, die Zeit in der JavaScript langsam lief. Einfach weil die Hardware für Smartphones noch nicht gut genug ist (mMn). Weil die Software noch nicht optimiert wurde und in vielen Bereichen keine Hardwarebeschleunigung stattfindet. Weil iOS ein geschlossenes System ist und die JavaScript Engine Nitro nur in Safari Mobile, aber nicht in Chrome oder in UIWebViews eingesetzt werden kann und auch keine anderen Engines verwendet werden dürfen. Weil iOS Geräte nicht einmal vernünftig per CLI gesteuert werden können. (Ihr benötigt Fruitstrap oder andere Lösungen.) Weil Android Chrome noch immer nicht als Standardbrowser verwendet (ja, ja Nexus 7). Weil Android eine schlechte Updatepolitik hat, alte Versionen einen langsamen Browser besitzen und weil CSS3 Animationen in Android flackern und ruckeln. Weil Frameworks für mobile Geräte noch in den Kinderschuhen stecken. Weil Responsive Design extrem heikel ist. (Gell, Enno?) Und und und…

$someTool to the rescue!

PhoneGap/Cordova/Whatever löst schon einmal einen kleinen Schlag (← muhahaha) dieser Probleme. Gerade die letzte Version 2.0 ist echt fett geworden. PhoneGap kommt jetzt mit einem relativ einheitlichen CLI für Android, iOS und BlackBerry. Tolle Leistung! Außerdem erhält jetzt jede Plattform die gleiche JavaScript Datei! Bisher musste jede Plattform eine andere Datei mit unterschiedlichen Implementierungen einbinden. Ein großer Schritt für PhoneGap.

Was Performance (gerade für Spiele) angeht hat Ludei in letzter Zeit was feines herausgebracht. Ich konnte es leider noch nicht testen, aber Ludei verteilt nun den Scene-Graph Manager CAAT in Kombination mit CocoonJS. Heißt übersetzt: Ein Hardwarebeschleunigstes Canvas über OpenGL ES mit passendem Framework. CocoonJS ist eh sehr innovativ. Durch CocoonJS kann bspw. vor allen Browsern die HTML5 Vibration API genutzt werden. CocoonJS ist quasi ein für Spiele optimiertes PhoneGap.

JavaScript hat zu viele Frameworks

Gewagte These, aber manche Bereiche – besonders MVC – werden einfach überbedient. Es gibt mMn zu viele Frameworks für bestimmte Dinge in JavaScript. Das ist per se nicht schlecht, aber ich glaube besser wäre es, wenn es ein paar große Frameworks geben würde und weniger kleine. Dass daraus eine gewisse Not und Problematik entsteht zeigen Projekte wie TodoMVC und Blogartikel mit großen Übersichten, welche mit Kusshand entgegengenommen werden. Denn mal ganz ehrlich: Wer hat als einzelner Entwickler die Zeit und nötigen Kompetenzen, um alle MVC Frameworks oder Templating Engines zu testen und zu vergleichen. Da bedarf es schon sozialer Netzwerke oder eine großen Firma wie LinkedIn (siehe beide Links).

Vor einigen Tagen habe ich angefangen mit EmberJS zu arbeiten. Ein sehr viel versprechendes mächtiges Framework mit einer nach meinem Empfinden erschreckend kleinen Community. Dies kann auch andere Gründe haben – so änderte sich die API in die Pre 1.0er Versionen sehr stark -, aber dass jeder Entwickler sich für ein anderes Framework entscheidet zählt bestimmt auch dazu.

Hoffentlich habe ich jetzt eine kleine Kontroverse losgetreten…

Meteor ist noch lange nicht ausgereift

Ein super Screencast, viel Trommelwirbel und 11,2 Mio $ Startkapital: Die Anfänge von Meteor habe ich mit Spannung verfolgt. Meteor ist ein hypermodernesfantastisches Framework für Echzeit-Webapps mit Node. Die erste Ernüchterung kam vom Derby-Team: Meteor bricht mit vielen Konventionen von Node Frameworks (u.a. keine Nutzung von NPM). Das war damals nicht so wild für mich, weil ich ohnehin noch keine Node Konventionen kannte, aber mitterweile hat sich das geändert. Trotzdem hatte ich zwischendurch mal Zeit gefunden Meteor (kurz) zu testen.

Zurück blieb ein sehr ernüchterndes erster Eindruck. Natürlich ist das Framework erst in Version 0.3.x. Aber normalerweise zeigt man es dann auch noch nicht der Öffentlichkeit und kann auf so ein großes Kapital zurückgreifen. Meine Erwartungen waren zu hoch. Das es noch keine vernünftige Authentifizierung ermöglich – damit kann ich leben. Ich betreibe eh keine echte App. Aber dann hatte ich erhebliche Probleme eine Meteor App (von Haus aus eine Singlepage App) mit ein paar statischen Seiten zu verbinden. So wollte ich als Test einen Chat entwicklen (Echtzeit – super für Meteor), aber auch ein paar Konfigurationsmöglichkeiten (User erstellen, etc.) über separate Seiten abwickeln. Das hätte ich auch in Meteor machen können, aber statische Seiten waren viel einfacher und schneller zu entwickeln und hätten für diesen Einsatzfall locker ausgereicht. Dummerweise stellte sich die Kommunikation zwischen Meteor und diesen Seiten als ziemlich kompliziert heraus.

Fazit: Für nicht 100%ig reine Echtzeitanwendungen, welche es so vielleicht gar nicht gibt (jede Anwendung hat doch irgendwie auch statische Elemente), stellt Meteor für mich noch ein zu großer Overhead dar. Und dank mangelnder Integrationsmöglichkeiten, vielleicht auch wegen dem oben genannten Bruch mit Node Konventionen, kann ich für die Fälle, in denen ich nicht Meteor verwenden möchte, nicht einfach Express oder etwas anderes als Ersatz nehmen.

CSS-Preprocessors und LiveReload are da sh!t

Das CSS-Preprocessors cool sind, wissen ja bereits alle senäh Leser. Ob ihr Less oder Sass benutzt ist dabei fast egal. Ich finde es aber immer noch Schade, dass Twitter Bootstrap nicht auf Sass setzt. Dann würde es diese Zweispaltung vermutlich nicht geben. (Ja, ja, es gibt auch noch Stylus…) Trotzdem wollte ich es noch einmal erwähnen. Denn mein einziges Problem, was ich damit hatte, habe ich nun auch endlich gelöst…

Mich hatte immer gestört, dass die Kompilierung von Less/Sass zu CSS zu lange gedauert hat (trotz CLI und watch commands). Deswegen habe ich schnell nach einer Live Reload Möglichkeit gesucht, welche die Komipilerung so schnell wie möglich übernimmt und die Ansicht im Browser aktualisiert ohne die Seite komplett neu zu laden. Alle getesteten Lösungen (z.B. die integrierte Lösung von WebStorm) haben mir nicht gefallen, weil sie zu langsam waren oder es irgendwleche Probleme gab. Nun habe ich LiveReload getestet und bin begeistert. Kaum speichert man eine Datei ab, werden die Änderungen im Browser sichtbar. Dafür muss nur ein Mini-Script in die HTML eingefügt werden. Der Rest funktioniert automatisch. Keine weiteren Plugins sind nötig. Daneben verträgt sich LiveReload prima mit mobilen Geräten, anderen Sprachen (CoffeeScript, etc.) und anderen Automatisierungsmöglichkeiten (Shell Scripte, etc.).
Und hey… es kostet nur 9,99$.

Soweit erst einmal der Juni/Juli Rückblick. Demnächst folgt August.

Autor: Pipo

...kommt ursprünglich aus der Designerecke, ist aber im Laufe seines Studiums in die Webentwicklung gestolpert. Kann sich seit dem nicht so richtig entscheiden wo er hingehört und wagt deswegen vielleicht die Flucht nach vorne in ein komplett neues Gebiet. Vielleicht Management? Niemand weiß es. Auch er nicht.