senäh

17senäh und so…

HTML/CSS/JS
06. Dez 2012
Kommentare: 0

Web Dev Rückblick für Oktober/November – Teil 1

Kategorien: HTML/CSS/JS | 06. Dez 2012 | Kommentare: 0

Schon wieder zwei Monate vorbei? Dabei wollte ich doch dieses Mal schon nach einen Monat einen Rückblick bringen. Mist. Bei mir gibt es dieses Mal auch ein paar rants. Aber auch wahre Begeisterungsstürme! Und etwas philosophisch wird es auch. Das sollte doch was für euch dabei sein oder? 😉
Schnell noch ein paar Schlagwörter ins excerpt: Sencha Touch, Bootstrap, node-webkit, RMVC and more!

Seid ihr heiß? Dann sofort weiterlesen!

Sencha Touch

Kennt ihr Sencha? Sencha ist eine Firma, die ausschließlich JavaScript Frameworks entwickelt, vermarktet und supported. Sie haben eine – nach meinem empfinden – relativ große Community. Ich gehörte auch einmal dazu.

Sencha

Sencha

Im März diesen Jahres sah ich mich der Aufgabe konfrontiert eine mobile Webapp zu entwickeln. Zur gleichen Zeit wurde Sencha Touch 2 veröffentlicht: ein App-Framework in JavaScript für Android, iOS und BlackBerry (also Webkit-only). Damals war es da sh1t! Sencha bietet für alle Frameworks eine ausführliche Onlinedokumentation an, zusätzlich einige erklärende Videos und Artikel. Das Framework bot alles, was man für aktuelle Apps braucht: MVC, Klassensysteme, Templates, Widgets, etc. Obendrauf gab es Sencha Cmd, ein Command Line Tool zum Wrappen der App in eine native Shell mit Zugriff auf native APIs. Zusätzlich gab es wie eingangs erwähnt eine große unterstützende Community. Klingt doch toll oder?

Ja, das liest sich gut. Aber mit der Zeit entdeckte ich zahlreiche Fehler. Der Teufel steckt im Detail! Sencha Cmd besaß doppelt belegte Keywords. Je nachdem ob man sich gerade im Projektordner befand oder nicht bewirkte der Aufruf von sencha im Terminal unterschiedliche Dinge. Dieses Verhalten war zunächst schwer nachvollziehbar und nicht wirklich online dokumentiert. Ich bin außerdem schnell an die Grenzen des nativen Shells gestoßen, weswegen ich früh wieder zu PhoneGap/Cordova gewechselt bin.

Generell ließ die Dokumentation ab einen gewissen Punkt zu wünschen übrig. Sie war zwar schön übersichtlich, zeigte aber selten komplexe Beispiele. Dies machte mir u.a. bei den Models, Stores und Proxies Probleme, aber auch bei den Views bzw. Components.

Richtig sauer wurde ich aber, als einfache Basisfunktionen in vorgefertigten GUI Elementen nur instabil funktionierten. Bestes Beispiel: Ich hatte häufig das Problem, dass ein Textfeld unter Android keine Eingaben angenommen hat. Ein Textfeld! So ziemlich das grundlegendste Eingabefeld, das man verwenden kann, funktionierte in einem extra dafür entwickelten Framework unzureichend! Und das war kein einfaches open-source Projekt: hier stand eine Firma hinter dem Framework!

Zunächst entwickelte ich die App komplett alleine. Als ich das Projekt so umstellen wollte, dass Designer besser mitarbeiten konnten, stieß ich vor weitere Probleme: das Layout und viele weitere Designkomponenten ließen sich nur über JavaScript komfortabel festlegen. Eine saubere Trennung von Markup, Style und Logik war kaum möglich. Senchas Templating Engine zeigte auch weit weniger Features als andere Konkurrenzframeworks.

Ich war echt enttäuscht… Das sollte das derzeit beste mobile Appframework sein? Arme Webapps 🙁 Ich suchte auf der Webseite nach einer Roadmap in der Hoffnung, dass viele meiner Probleme bald behoben werden sollten, fand jedoch nur ein paar Zeilen aus denen kaum Informationen hervor gingen. Dann war ich weg…

Mittlerweile fahre ich die Strategie modularere Frameworks zu verwenden. Als MVC-Framework verwende ich im Augenblick Ember.js (wobei ich mir irgendwann auch noch AngularJS zu Gemüte führen möchte) und als Widget-Bibliothek nehme ich als Grundlage Twitter Bootstrap. Mit diesen zwei großen Frameworks und einigen kleinen Helfern kann ich wesentlich flexibler entwickeln. Wenn mir Ember.js nicht mehr genügt, dann wechsele ich halt zu AngularJS – kann aber trotzdem noch Bootstrap verwenden. Bei Sencha greift aber alles irgendwie ineinander. (Dies kann natürlich auch Vorteile haben…) Aber das ist noch nicht alles: ich bin nicht nur nicht mehr abhängig von Webkit-basierten Browsern und könnte theoretisch auch für Windows Phone 8 entwickeln – ich bin einfach komplett unabhängig von mobilen Endgeräten und könnte ggf. sogar den Desktop bedienen! Wirklich Nachteile haben sich dadurch nicht ergeben. Einige mobile-spezifische GUI Elemente, die Sencha Touch von Haus aus mitlieferte, musste ich mir in Bootstrap nachbauen. Aber das hat nicht wirklich lange gedauert. Eventuell läuft Ember.js etwas langsamer als Sencha Touch – aber bei mobilen Webapps darf man sich ohnehin (noch) nicht viel Performance erhoffen. Also, who cares? Noch ein Bonus: da ich Bootstrap nutze, steigert sich die Wahrscheinlichkeit, dass ein Designer mit einigen Vorkenntnissen die Gestaltung der App übernimmt. Einfach weil Bootstrap so beliebt ist. Siehe nächster Punkt:

Twitter Bootstrap

Schon viel wurde über Twitter Bootstrap berichtet. Ein überaus beliebtes Framework – zu Recht! Es ist schön übersichtlich und benutzerfreundlich. Die JS-Plugins sind super aufgebaut und haben einige Konventionen, die ich noch nicht kannte, aber mittlerweile sehr schätze (Konfiguration der Plugins im Markup durch data-Attribute!).

Twitter Bootstrap

Twitter Bootstrap

Im Großen und Ganzen das beste Framework seiner Art. Ich möchte deswegen nur etwas konstruktiv ranten:

Mir ist aufgefallen, dass sich bei der Verwendung des Responsive Designs fluide und statische Gitter des Frameworks exakt gleich verhalten – sie werden im Prinzip komplett aufgehoben. Das hätte ich vorher nicht erwartet, zudem ich viele Verwendungen für ein fluides Gitter auf kleinen Bildschirmen habe. Ich habe die Jungs von Twitter deswegen einmal angeschrieben, aber an diesem Verhalten wollen sie nichts ändern. (Allerdings überlegen sie das Grid-System komplett umzustellen…) Ich musste mir deswegen ein eigenes Grid anlegen. Jetzt habe ich .row, .row-fluid und .row-fluid-important. Letzteres bleibt auch bei Responsive Designs erhalten. Außerdem finde ich es überaus praktisch fluide Gitter ineinander zu nesten. Dann wird als Maximalbreite nicht mehr das Browserfenster genommen, sondern der parent container.

Auch wünschenswert: ein etwas größerer Fokus für mobile Browser. Es gibt ja schon .visible-phone Klassen und ähnliches. An der Stelle könnte man ansetzen und so eventuell GUI Elemente für Buttons größer gestalten, wenn man ein Smartphone nutzt. Klar kann man das im Augenblick manuell machen – aber wenn es von Haus aus mitgeliefert wird, wäre das doch auch schön 😉

Was ich persönlich noch ganz interessant fände, wäre die reine Gestaltung separat zu halten. Es gibt da das schicke Inuit CSS Framework, welches die gleichen/ähnlichen Features für CSS mitbringt wie Bootstrap – nur ohne Styles. Man bekommt so eine Art nacktes CSS Skeleton, das man selbst stylen kann. Die wichtigsten Klassen wie .button sind schon angelegt und teilweise mit Eigenschaften ausgestattet. So wird bei der Verwendung der Klasse .button als Cursor eine Hand/Pointer angezeigt, aber man erhält nicht gleich wie bei Bootstrap einen vollgestylten Button mit Verläufen und abgerundeten Ecken. Wäre toll, wenn die das Styling nur als Zusatzoption anbieten würden. Sollte ich vielleicht mal vorschlagen…

Gerade eben auf dem Bootstrap-Blog gelesen: IE7 Support wird in Version 3 gedroppt. I like! Schließlich wird Anfang des Jahres auch von jQuery der IE-Support bis Version 8 gedroppt. Das heißt für uns Entwickler – schlankere Frameworks und hitzigere Diskussion mit dem Marketing und Projektmanagern, ob IE bis 8 ignoriert werden darf oder nicht.

Fortsetzung folgt…

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.