CRE167 node.js

Die event-basierte Programmierumgebung für das Realtime Web

Episode image forCRE167 node.js

node.js ist eine neue und recht neuartige Laufzeitumgebung für JavaScript-Programme, dass das asynchrone Programmieren in den Vordergrund stellt, um eine hohe Performance zu erreichen. Im Gespräch mit Tim Pritlove berichtet Felix Geisendörfer von Hintergrund, Eigenschaften und Anwendungsmöglichkeiten von node.js.

Themen: aktuelle Probleme bei Webanwendungen; Long polling und File Upload; Asynchroner I/O; Latenzen und Performance-Bottlenecks; Vor- und Nachteile eventbasierter Programmierung; Threads und Thread Safety; node.js Architektur und Komponenten; Warten im Netz; Vom Umgang mit vielen gleichzeitigen Verbindungen; Serverseitiges Web Browsing; Anwendungsverteilung zwischen Client und Server; Asynchrones Rendering von Templates; Asynchrone Kommunikation mit Datenbanken; Debugging; Node Package Manager; Module und Addons; nodeJS auf Embedded-Systemen.

avatar
Tim Pritlove
avatar
Felix Geisendörfer
Shownotes

Links:

22 Gedanken zu „CRE167 node.js

  1. Vielen Dank für eine weitere interessante Folge CRE!
    Ich bewundere ja immer auch deine ausführlichen Linklisten in den Shownotes. Aber fehlt da nicht noch was wichtiges?

    Es ist ja ok, dass du die Intros immer son bischen mysteriös für sich stehen lässt :-) Ich hab mir nur bei der Intro-Musik diesmal die Mühe gemacht, und durch kurzes Googeln rausgefunden, dass die Musik unter CC-Lizenz veröffentlicht ist. Was ich auch nicht anders erwartet habe.

    Wo bleibt denn da die laut CC erforderliche Namensnennung?

  2. Nette Folge, dachte eigentlicht etwas über ein weiteres JS-Framework zu erfahren, aber Server-JS ist auch mal ’n interessantes Thema.

    Was mich ein bisschen wundert ist, dass ursprünglich keine DOM-Unterstützung existierte!? Das finde ich seltsam, denn… ich will nicht sagen „im Wesentlichen“ aber meistens generiert man mit Web-Servern ja irgendwie Websites in HTML oder XHTML oder sowas (klar, nicht nur…).
    Da böte es sich imho super an, wenn ich ein DOM habe und bei reinkommenden Events eben irgendein Element in mein DOM hängen kann und wenn ich mit allem fertig bin serialisiere ich den Kram und schick’s dem Browser.
    Wenn man das noch asynchron hinbekäme um so besser, aber was ich eben meine ist: Man baut Webseiten, Webseiten haben ein DOM, aber man baut kein DOM sondern Strings!? (Derzeit noch). Komisch :)

    Die restlichen 30 Minuten höre ich dann, wenn ich von der Arbeit heim komme :)

  3. Eine Programmiersprache für IO zu verwenden, und sei es noch so asynchron, die nicht einmal das Konzept Byte, Integer oder gar Bytebuffer kennt halte ich für dumm.

    Wer Crockfords „JavaScript – The Good Parts“ gelesen hat, der weiß, dass JavaScript zu 70% aus Bad und Ugly Parts besteht. JavaScript ist allenfalls eine „besser als erwartet“-Sprache, so wie Angela Merkel einst die „besser als erwartet“-Kanzlerin war.

    Weshalb soll JavaScript „besonders gut für asynchrone Programmierung geeignet“ sein? Weil es Lambda-Funktionen hat, die man als Callbacks verwenden kann, so wie das eigentlich jede vernünftige Programmiersprache hat?

  4. Danke für den Podcast! Ich beschäftige mich schon seit einigen Wochen mit node und endlich gibt es auch eine gute deutsche Ressource im vertrauten Format, das sich doch deutlich von den amerikanischen unterscheidet. Somit konnte ich vieles besser verstehen, was ich bisher nur angewendet oder nicht verstanden habe. Felix war dafür auch ein super Gesprächspartner.

  5. Wow. Das war mal wieder ein genialer Podcast. Ich habe damals den JavaScript Podcast gehört und dachte, man müsste doch einen eigenen über node.js machen!
    Node ist aus meiner Sicht neben den Objektorientierten Datenbanken eine der wichtigsten Webtechnologien der Zukunft. Wenn man als Datenbank CouchDB benutzt, muss man plötzlich nur noch Javascript programmieren um eine ganze Webapplikation zu schreiben, wer hätte das vor ein paar Jahren gedacht :-)

  6. Auch solaris hat kein aio{_read,read}-Support fuer normale Dateien. Dies wird ebenfalls ueber einen Userspace-Threadpool gehandhabt. Die Kernel-Implementierung supportet meines Wissens nach nur block-devices, ist im Gegensatz zu linux aber agnostisch bzgl. der API.

  7. Der Podcast hört sich ganz gut, mir ist das Tempo etwas zu langsam. Inhaltlich: Node ist schon toll, gerade weil es die oft grossen Unterschiede zwischen Client und Server-Platform reduziert, aber zu behaupten, dass es keine andere Platform gibt, die non-blocking IO supported, ist so nun wirklich nicht richtig (Java NIO, IO:AIO für Perl, Boost AIO für C++, gibt sicher noch mehr) und select() kann man durchaus als Non-Blocking IO Methode gelten lassen, und viele C-Proggies nutzen das ja einfach direkt.

  8. IMHO: einer der ersten Sprachen, die event-based programming (richtig) umgesetzt hat war wohl Tcl mit Tk. Einfach, das mal auch jemand wieder diese tolle Spache erwähnt hat ;-)

  9. Wenn ein PHP Entwickler über POSIX redet… FEHLINFORMATIONEN!!!

    Natürlich können Linux, FreeBSD, usw. non-blocking IO; bei Dateien GENAUSO wie beim Netzwerk! Und Solaris kann hier gar nichts besser, ausser vieleicht dass ZFS derzeit performanter eingebunden ist.

    Schonmal etwas von einem Filedecriptor gehört, der sowohl Dateien als auch Netzwerk, Geräte, usw. gleich behandelt? Insbesondere nach POSIX können alle Systeme mit select, tollerweise aber teilweise sogar noch viel schöner mit anderen Systemcalls (z.B. unter Linux mit epoll) mit vielen gleichzeitigen Filedescriptoren umgehen. Das skaliert auch mit richtig vielen gleichzeitigen Verbindungen und/oder offenen Dateien wunderbar.

    http://linux.die.net/man/7/epoll

    Ich bin noch nicht ganz durch, aber alles was ich so höre geht wesentlich schöner und einfacher mit POE: http://poe.perl.org/.

    P.S.: Ich kann UNIX Network Programming von W. Richard Stevens empfehlen.

  10. Pingback: Node.js | Paul Vorbach

  11. Pingback: oreillyblog » Node.js: Blitzschnelles und stabiles JavaScript

  12. Pingback: CRE176 Cloud Computing | CRE: Technik, Kultur, Gesellschaft

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.