Auch heute gibt es wie jeden Mittwoch die besten Links der letzten 7 Tage für den interessierten Webworker:
- Javascript: Mashi – JS-Framework speziell für präzise getimte Animationen.
- HTML5: HTML 5 innerShiv – Wie man mit der unheiligen Kombination aus Internet Explorer, HTML5 und innerHTML umgeht (also HTML5-Elemente, die via innerHTML eingefügt werden „anmeldet“)
- JavaScript: Douglas Crockford: Loopage” (52 min.) – Teil 6 der Crockford-on-JavaScript-Serie
- JavaScript: Open Source Node eBook – Work in progress.
Du hast Vorschläge für die nächste Linkliste? Ein tolles Programm, einen wichtigen Link oder einen interessanten Artikel? Lass es mich wissen! (und wirf einen Blick auf die Richtlinien für Links)
Kommentare (13)
Axel ¶
1. September 2010, 13:30 Uhr
Seit Crockford gemeint hat, die Leute die sich IEEE754 ausgedacht hat (bezüglich NaNs in JavaScript) sind Idioten, kann ich ihn nicht mehr ernst nehmen.
Peter ¶
1. September 2010, 13:34 Uhr
Besser finde ich ja, dass er HTML5 stoppen will :)
Aber nicht alles was er sagt ist kompletter Käse.
Axel ¶
1. September 2010, 13:35 Uhr
Klar, aber ich habe das Gefühl, er sollte mal bissel zurückschrauben mit seinem Ego.
Bei HTML5 hat er übrigens sehr gute Punkte vorgebracht. Aber jetzt ist das Kind eh schon in den Brunnen gefallen.
Peter ¶
1. September 2010, 13:42 Uhr
So gut finde ich seine Punkt gar nicht mal, denn die sind ja alles nichts neues im Web. Es hat nur quantitativ etwas zugelegt. Und so ganz ohne konstruktiven Gegenvorschlag geäußert ist das eh nicht wirklich diskussionswürdig.
Axel ¶
1. September 2010, 14:21 Uhr
Jetzt behauptet er auch noch, dass Threads in Java eine schlecht Idee waren und man sowieso alles mit einem Event Loop ersetzen kann. Der sollte mal dringend über seinen JavaScript-Tellerrand schauen.
Das mag ja für eine GUI-Applikation funktionieren, nur benutzt man Threads nunmal auch zur Parallelisierung.
Das gleiche war ja schon bei den NaNs zu beobachten. Im JavaScript-Context mögen die komisch erscheinen, aber mathematisch betrachtet ist es das einzig vernünftige Verhalten, wenn man wirklich mal numerisch komplexe Dinge macht.
Peter ¶
1. September 2010, 14:30 Uhr
Also ich hatte das eigentlich auch so verstanden, dass er Threads nur in Endverbraucher-Apps, aber nicht prinzipiell verdammt hat. Hast du mal einen Link zu dieser NaN-Geschichte? Die ist irgendwie an mir vorbei gegangen.
Axel ¶
1. September 2010, 14:35 Uhr
Er hat in dem Video fast wörtwörtlich behauptet, dass "Threads in Java eine schlechte Idee waren". Wie soll man das sonst interpretieren?
Das mit den NaNs hat er in irgendeinem der letzten Videos gesagt, als es um Zahlen in JavaScript ging. Das ist mir echt sauer aufgestoßen, weil er auch noch dümmlich gelacht hat.
Robert ¶
1. September 2010, 14:54 Uhr
Da saß ich wirklich verwundert vor der Mashi-Seite, und habe mich gefragt was der Shit soll, bis mir aufgefallen ist, dass das ganze im FF4b nicht läuft, im FF3.6 hingegen schon...
(nur falls sich noch jemand wundert. Die scheinen wohl sehr präzise auf die Version zu prüfen, und neuere Browser ohne Hinweis einfach zu ignorieren...)
Peter ¶
1. September 2010, 15:16 Uhr
Zitat Axel:
Aber war nicht die Begründung für die Bewertung als „schlechte Idee“, dass damit Threads in Endverbraucher-Apps landen (können)? Ach, ist ja auch egal. Wir sind uns ja darin einig dass man den Herrn Guru mit Vorsicht genießen muss.
Alexander Trefz ¶
4. September 2010, 16:13 Uhr
Zitat Axel:
Das Problem ist nicht NaN an sich, sondern das Verhalten von NaN. Wenn NaN !== NaN gilt ist es schon ziemlich Grenzwertig oder?(das ist aber durchaus mehr ein ES Problem als ein IEEE Problem) Aber der IEEE 754 ist trotzdem einfach Schrott, aber nicht wegen NaN sondern wegen diesem netten "Feature" hier: 0.1 + 0.2 !== 0.3. Das geht einfach nicht und damit hat er einfach absolut recht.
Axel ¶
6. September 2010, 13:48 Uhr
Nein, das ist nicht grenzwertig, sondern völlig logisch. Ein NaN repräsentiert eben *keine Zahl*. Es ist einfach ein undefinierter, ungewisser und ungültiger Zustand.
Eine NaN kann also niemals gleich zu einer anderen NaN sein. Das ergibt keinen Sinn. Das ist als würde man behaupten dass jede Stadt in der kein Eiffelturm steht gleich ist.
Axel ¶
6. September 2010, 13:54 Uhr
Und das IEEE754 "schrott" ist bestätigt mich zusätzlich in der Annahme, dass du dich mal damit beschäftigen solltest bevor du solche Aussagen tätigst. Das ist binär einfach nicht korrekt darstellbar und die Alternativen (decimal floating point) sind viel teurer zu implementieren und verbrauchen mehr Speicher.
Wenn irgendwas ein Problem ist, dann das JavaScript überhaupt Floating Point als den numerischen Rechentyp definiert hat. Das macht ja auch die Portierung auf embedded Chips fast völlig unmöglich.
Axel ¶
6. September 2010, 14:02 Uhr
Und bevor du zurückmaulst: Auch dezimal lässt sich nicht jeder Bruch korrekt darstellen. Versuch es beispielsweise mal bei 7/9. Das ist exakt das gleiche Problem. Schrott!!!1111elfeinseins