Mit dem seltenen Überraschungsgast Peter starten Rodney und Hans in eine neue Revision voller Spiel, Spaß und Abenteuer!
[00:00:10] News
- MySQL 5.6.6 ist da
- Mit memcached an Bord!
Schaunotizen
- [00:00:40] Neue Syntax in ECMAScript 6
- Die nächste Version von JavaScript wird allerlei neue Syntax einführen, wovon Nicholas C. Zakas ein großer Teil ganz und gar nicht gefällt. Rodney und Peter stimmen in diesem Chor voller Inbrunst ein. Fat Arrows machen, wenn überhaupt, nur in CoffeeScript Sinn, Quasi Literals könnten auch einfache Library-Funktionen sein und überhaupt hätten wir nichts gegen etwas mehr Zurückhaltung bei der Einführung von neuer Syntax. Sinnvoller finden wir da schon die neuen Syntaxen für z.B. Klassen und Konstanten, aber generell ist weniger mehr. Peter geht auch davon aus, dass die ES-Macher noch rechtzeitig zur Vernunft kommen.
- [00:20:33] Support for @supports in Firefox Nightly
- Ist das Ende von JS-Polyfills nahe? Mit der @supports-Regel können CSS-Autoren den Browser fragen, ob sie eine CSS-Deklaration verstehen und dann entsprechend darauf reagieren. Die Idee finden wir summa summarum ganz großartig. Der Firefox legt nun mit seiner Implementierung vor, doch auch Opera arbeitet dran. Ein weiteres mögliches Feature für die Zukunft, die color()-Funktion, steifen wir auch.
- [00:31:27] Microsoft commits to WebRTC – just not Google’s version
- Der Artikel, der Anlass zu diesem Thema ist, enthält nicht viele Informationen, aber das was da ist reicht, um Peter fragen zu lassen: „können wir uns WebRTC an die Backe schmieren?“ Die pluginfreie VOIP-im-Browser-Technologie (s. webrtc.org + dieser umfassender Talk von Googles diesjähriger Entwicklerkonferenz) will jetzt auch Microsoft unterstützen, macht aber das von <video> und <audio> bekannte Codec-Fass auf. Statt sich auf einen Codec zu einigen sei es ja viel besser für den Endnutzer, wenn er die freie Wahl hätte. So wie ihr bei ihrem Stromanbieter! Wir sind nicht alle komplett von dieser Argumentationskette überzeugt.
[00:45:19] Keine Schaunotizen
- Prism
- Lea Verou hat den bei Dabblet.com verwendeten Syntaxhighlighter geopensourced.
- Mobilism’s Videos
- Reinziehen, lernen!
- gridster.js
- jQuery-Plugin für rekonfigurierbare Grid-Layouts.
- Piecon
- A tiny javascript library for dynamically generating pie charts in your favicons.
- SCSS-Toolkit
- Auf SMACSS basierendes Toolkit für SCSS.
Kommentare
Hans Bauer #
Geschrieben am 10.08.2012 um 11:57
Ich kann mich Euren negativen Kommentare zu den neuen Syntax von ECMAScript 6 nicht identifizieren.
Ich finde diesen neuen Syntax extrem gut und macht Java Script Syntax endlich brauchbarer.
Just my 2 cents.
-Hans
Rodney Rehm #
Geschrieben am 10.08.2012 um 12:29
Hallo Hans,
kannst du erläutern was du an der neuen Syntax gut („sinnvoll“) findest? Also, so mit Argumenten statt Bauchgefühlen. Wir lassen uns gerne eines Besseren belehren und zur hellen Seite der Syntax-Macht bekehren :)
Hans Bauer #
Geschrieben am 10.08.2012 um 13:17
Hi Rodney,
zuerst will ich noch ein paar Worte los werden.
a) Working Draft klasse und höre schon ca. 1 Jahr all Eure Beiträge
b) Weiter so!
:)
Zu dem Thema „Syntax von ECMAScript 6“ stören mich z. B. solche Aussagen wie „function“ ist doch kein Thema, da tipp ich „fun“ und function wird vom Editor vervollständigt. Diese Art von Argumenten kann schon sein, aber nur weil etwas in der Vergangenheit so war muss es in der Zukunft nicht so sein.
Beispiel: Ich selbst hab mich mit den Syntax von Java Script anfänglich extrem schwer getan und habe das mit „function() {}“ einfach so akzeptiert (gab ja keine andere Lösung). Jedoch ist mein Java Script Code im Verhältnis zu meinen bisherigen Code in anderen Sprachen immer sehr unübersichtlich und schwer zu lesen gewesen. Hatte ich mich auch dran gewöhn (weil ich die Funktionen im Browser bedienen wollte (WebApps, durchaus größere Projekte) und es keine Alternative gab).
Nun bin ich vor 3 Monaten über CoffeeScript (aus meiner Sicht nur eine Ergänzung zum Java Script Syntax) gestolpert und hatte es anfänglich belächelt. Als ich ein paar Beispiele durch hatte, hatte ich das Potential entdeckt.
Kurz um: Mein Code wurde ca. 40-50% weniger (worauf ich gar nicht mal abfahren würde), aber das viel bessere und viel wichtigere, er ist lesbar/maintainbar geworden (ich will jetzt nicht behaupten, dass ich in Java Script ein Legastheniker bin – aber die Unterschiede rein durch den Syntax sind Welten einfacher/effektiver).
Aus meiner Sicht kann ich nur sagen, CoffeeScript ist das bessere Java Script.
Es gibt auch ein Interessantes Video vom prototypjs Erfinder dazu: http://vimeo.com/35258313
Auf das wollte ich aber eigentlich gar nicht raus. Ich würde mir wünschen, dass in Euren Podcasts neuen Sachen positiver entgegen steht. Das letzte mal ist mir das bei MVC in Client aufgefallen – da war Eure Meinung dazu, dass kann man auch mit einem eigenen Objekt und einen Custom-Event machen -> das ist je nach Einsatzbereich richtig, aber in den heutigen Tagen von WebApps schlicht und einfach unprofessionell :). Will aber gar nicht in Details rum springen. Einfach ein wenig offener für neues. :)
Sonst bitte weiter so, ich bin von Euch sehr überzeugt! Note „1a“!
Peter #
Geschrieben am 10.08.2012 um 13:26
Die Sache ist nur: die Arrow-Funktionen reparieren das ich-muss-immer-das-lange-function-tippen-„Problem“ nicht, denn man will ja nicht immer eine Funktion haben, deren inneres this dem äußeren entspricht. Ich würde sogar sagen, dass das ein Sonderfall ist. Und für einen Sonderfall gleich eine komplett andersartige Syntax einführen? Vor allem, da man es doch in JS auch normal ganz bequem hinbekommt:
var f = function(){ }.bind(this);
.Hans Bauer #
Geschrieben am 10.08.2012 um 13:37
Peter, hier hast Du recht (wenn man => macht, darf -> nicht fehlen).
Ohne this:
var f = function(a, b, c){
// some code with a, v, c
}
var f = (a, b, c) ->
// some code with a, v, c
Mit this:
var f = function(a, b, c){
// some code with a, v, c
// .bind(this) at the end will be overlooked easily
}.bind(this);
var f = (a, b, c) =>
// some code
Axel Rauschmayer #
Geschrieben am 10.08.2012 um 13:48
Das ist in der Tat das richtige Pattern. Aber es werden zwei Funktionen erzeugt, wo bei einer Arrow Function nur eine erzeugt würde. Bis zu einer gewissen Grenze stimme ich zu: Man muss nicht immer krampfhaft neues erfinden. Ich bin auch kein besonderer Fan von CoffeeScript, aber Arrow Functions machen JavaScript schon sehr viel lesbarer. Beispiel:
let squares = [ 1, 2, 3 ].map(function (x) { return x * x });
let squares = [ 1, 2, 3 ].map(x => x * x);
Zudem finde ich den Unterschied Non Method Function und Method konzeptuell wichtig. Und bei konzeptuellen Unterschieden profitiert man immer davon, wenn sich diese Unterschiede auch in der Syntax niederschlagen.
Bei Bedarf, mehr Info zu Arrow Functions: “ECMAScript.next: arrow functions and method definitions”.
Rodney Rehm #
Geschrieben am 10.08.2012 um 13:39
Hallo Hans,
freut uns, dass unsere geistigen Ergüsse trotz Peters und Meiner „Grundnegativität“ (ich würde es eher unverblümte Skeptik nennen) brauchbar sind :)
Und damit hast du das ganze ja schon auf den Punkt gebracht. Für dich, als CoffeeScript-Liebhaber, sind (obskure) Konstrukte wie »foo = ()=> bar« alltägliche Erscheinungen. Es ist vollkommen OK, dass du diese Syntax toll findest. Es gibt auch Leute die Erlang toll finden. Oder Brainfuck. Oder Java, PHP, … Jeder Mensch tickt anders und das ist total in Ordnung so.
Peter und mir ging es dabei weniger darum, dass der Fat-Arrow an sich eine dämliche Idee ist. Ist er nicht. In Sprachen wie CoffeeScript macht das total viel Sinn, da die Syntax ja genau in das Schema passt.
Javascript ist aber ein C-Derivat (naja, im weiteren Sinne halt) – eben nicht CoffeeScript, Erlang oder Ruby. Der Fat-Arrow würde hier ein Konstrukt einfügen, das überhaupt nicht in das Landschaftsbild der Sprache passt. Der => stünde hervor wie die Milka-Kuh auf einer Schweizer Alm.
Vielleicht hilft auch ein Vergleich mit natürlicher Sprache. Findest du es nicht auch strange, wenn in einem deutschen Satz ständig Anglizismen auftauchen, die einfach nur die readability stören? Genau so sieht das auch Javascript aus, wenn auf einmal ein => auftaucht.
Wir greifen also weniger die Syntax / Idee an sich an, als vielmehr den Versuch ein eckiges Schwein in einen runden Stall zu ferchen.
Zum „optischen“ kommt dann halt (erschwerend) hinzu, dass diese Erweiterungen der Syntax nicht abwärtskompatibel sind. Nutze ich auch nur einen einzigen Fat-Arrow in meinem Script, wird es in keinem Browser vor Firefox 35 und Chrome 112 laufen. Auf der einen Seite schreiben wir Polyfills en masse, um auch einem IE6 noch die <canvas> beizubringen, auf der anderen Seite wollen wir dann aber Dinge einführen, die wir nicht mal abwärtskompatibel hinfrickeln™ können. Dieser Plan wird – meines Erachtens nach – nicht aufgehen.
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.