Peter war wieder auf Achse und so haben wir uns diesmal Marc Hinse und Khalil Lechelt als Fachleute dazugeholt.
Schaunotizen
- [00:02:06] speak.js – Text-To-Speech on the Web
- Wieder einmal wurde dank Emscripten etwas nach JavaScript portiert. Und diesmal ist es was sehr Praktisches: ein Text-zu-Audio-Synthesizer. Damit lassen sich endlich Vorlese-Dienste quelloffen umsetzen, wie sie bislang nur das kommerzielle ReadSpeaker zum Beispiel in heise Newsticker Meldungen möglich gemacht hat (oben links: „vorlesen“).
- [00:10:53] tween.js
- tween.js ist ein generisches Werkzeug zur Erzeugung von zeitgesteuerten Übergangskurven. Diese Werte lassen sich dann zur Animation beliebiger Dinge nutzen.
- [00:17:56] Cross-browser contextmenu support with a polyfill
- Firefox 8 unterstützt erstmalig HTML5 Contextmenüs. Addy Osmani zeigt, wie das geht und verweist auf ein Polyfill von Rodney Rehm.
- [00:34:02] Native Client – Googles Vision vom nativen Web
- Google stellte schon 2008 seine Idee des nativen Clients vor. Mit Chrome 14 ist die Plattform nun einigermaßen vorzeigbar und erste Chrome Apps nutzen das schon. Was ist davon zu halten?
- [00:55:26] pjscrape
- Ein Contentscraper, der auch dann funktioniert, wenn der Inhalt der Zielseite per JavaScript erzeugt wird. Möglich macht das der darunterliegende Headless-WebKit namens PhantomJS
- [01:02:08] backbone.js und andere MVC/MVVM-JavaScript-Frameworks
- Kahlil erzählt uns ein wenig was über backbone.js und underscore.js. Wir reden aber auch über Knockout.js und über die Designphilosophie all dieser recht frischen MVC bzw. MVVM Frameworks. Dazu lesenswert: Der Artikel Standardkonforme und zukunftsfähige JavaScript-Bibliotheken von Mathias Schäfer.
[01:31:41] Keine Schaunotizen
- How Browsers Work: Behind the Scenes of Modern Web Browsers
- Dieses Dokument beschreibt den gesamten Ablauf, den Browser beim Darstellen einer Seite .durchlaufen müssen.
- Verbesserungen am Netzwerkstack von Firefox 6
- Interessanter Beitrag des zuständigen Firefox-Architekten, was in Version 6 alles an cleveren Verbesserungen in den Netzwerkstack geflossen ist.
- Browserling
- Mit Browserling kann man Seiten in den wichtigsten älteren Browsern testen. Das coole dabei ist, dass das Ergebnis in Echtzeit in ein HTML5 Canvas Element gezeichnet wird.
- Spin.js
- Ein reiner Markup-Loading-Spinner.
- Firefox Scratchpad
- Firefox kommt nun mit einer Art integriertem jsfiddle zum Code-Testen daher. Praktisch!
- Rasta.js
- Ein simpler kleiner Cross-Domain-Key-Value-Store.
- Usability in Icons
- Dieser Artikel beschäftigt sich mit der Tatsache, dass die wenigsten Icon-Symboliken von den Benutzern verstanden werden.
Kommentare
molily #
Geschrieben am 26.08.2011 um 13:24
Das Problem von Backbone und offenbar auch Knockout ist, dass sie nichts bieten, um eine *JavaScript-Anwendung* als solche zu strukturieren. Was sie bieten, ist ein Pattern, das auf der untersten Ebene von JavaScript-Anwendungen liegt: Sie haben ein Datenobjekt, das mit JSON/REST gefüllt wird, ein HTML-Template und eine Art und Weise, zwischen diesen ein Binding zu erzeugen und auf User-Events zu reagieren – bei Backbone View genannt, bei Spine Controller, bei Knockout durch deklaratives Binding gelöst.
Das ist schön, aber hilft einem nicht dabei, eine ganze Anwendung zu strukturieren. Dieses Pattern kommt in einer Anwendung dutzende Male vor – jetzt ist die Frage, wie man diese dutzenden Model-Template-View-Paare strukturiert. Sowohl von der UI-Logik als auch der Geschäftslogik.
Auf Serverseite ist MVC wirklich ein Pattern für die Software-Architektur. MVC in den sogenannten MVC-JavaScript-Frameworks ist das nicht oder nur eingeschränkt über das Routing von Backbone und Spine. Dieses ist aber für die komplexen Übergänge in Anwendungen nur sehr rudimentär geeignet – wirklich robust ist diese pushState-/Fake-Hash-URI-Geschichte auch nicht. Bei der Anwendung, an der ich zuletzt gearbeitet habe, konnten wir das Routing aus gewissen Gründen gar nicht verwenden (Stichwort IE 7 und Cross-Domain-Zugriffe).
Marc #
Geschrieben am 30.08.2011 um 11:23
@Mathias: Wie sähe denn ein sinnvoller Ansatz aus? Oder meinst Du eher, dass es mit JavaScript gar nicht sinnvoll zu lösen ist, da es die erforderlichen Werkzeuge nicht bzw. deren Verbreitung (push-State etc.) noch nicht mitbringt?
molily #
Geschrieben am 30.08.2011 um 21:38
Die Ansätze der genannten Bibliotheken sind schon sinnvoll, aber nicht hinreichend für größere Anwendungen. Das ist m.E. das große Missverständnis bei der gegenwärtigen Backbone-Rezeption.
pushState ist fein, wenn es einmal alle Browser unterstützen und man tatsächlich klassische URLs haben kann und will. Der Grund, warum wir in der oben genannten Anwendung nicht auf Hash-URIs setzen konnten, ist ein Sonderfall – die API liegt auf einem anderen Server, für Cross-Domain-Zugriffe wird document.domain gesetzt und damit kommt Backbones hashchange-Fallback für den IE7 nicht klar. Twitter macht etwas ähnliches, nur verwenden die nicht Backbone, sondern ausgereifte hashchange-Fallbacks.
Allgemein taugen URLs nur bedingt dazu, um den Status von Webanwendungen festzuhalten. Bei Backbone mappt der Router URLs auf Methoden, die dann üblicherweise Models und Views erzeugen. Dieses Modell taugt nicht für Anwendungen mit mehreren parallelen Views. Für die braucht man weitere Patterns und weitere Ebenen. Bei der genannten Anwendung haben wir Controller eingeführt, die mit Rails-Controllern vergleichbar sind. Sie erzeugen die Models und Views. Zudem gibt es als »Kleber«:
– ein Application-Objekt als Namensraum und Publish/Subscribe-Channel
– eine ApplicationView, die den Wechsel zwischen den Modulen vornimmt
– einen ApplicationController, der die ständig sichtbaren Views und die von verschiedenen Views benötigten Kern-Daten verwaltet
Aber das werde ich beizeiten noch in einem Blogpost näher beschreiben. ;)
Schepp #
Geschrieben am 31.08.2011 um 07:10
Randnotiz: Passend zu dem Thema ist diese Woche ein interessanter Artikel namens Patterns For Large-Scale JavaScript Application Architecture erschienen.
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.