back to article The Node Ahead: JavaScript leaps from browser into future

Voxer is a walkie-talkie for the modern age, an iPhone app that lets you instantly talk across the interwebs and listen at the same time and leave voice messages if no one is on the other end and simultaneously chat with multiple people and toggle between text and voice to your heart's content. It's a real-time internet app in …

COMMENTS

This topic is closed for new posts.

Page:

  1. Alan Bourke
    Grenade

    Yes you can do anything in C++

    including spending some much time farting around with low-level stuff instead of actually fulfilling business requirements that the whole thing goes boobs aloft.

  2. Jon Press

    We are not simplifying multi-threading here. We are abolishing it.

    That's probably not a great idea. Event-driven architectures are fine for the cases in which the work required between events is small and/or approximately the same for each event. Any application which requires a significant period of processing in response to an event is going to have to yield to other event-handling sufficiently often to ensure other activities don't stall - and that's just multithreading by a different name.

    FSMs (that's finite state machines) are great for things like network protocols - get a packet, do something, send another one - but the more complex the "do something" is and the more you have to break it down into individually-schedulable events the more the code looks like another kind of FSM, the Flying Spaghetti Monster [no offence to disciples intended....].

    1. Stephen Bungay

      Funny...

      I always thought "multithreading" was "multiprocessing" by another name. For an event driven multi-process OS look at the Amiga.

      1. Nick Ryan Silver badge

        One of these days...

        One of these days somebody will produce an OS as clean and easy to use as the old Amiga OS (before the "magic" UI and other stuff took over that is). The OS rendered your application, including the buttons controls and everything. As a developer you just provided event handlers to the button presses and any custom rendering required. It was simple, efficient and applications remained largely efficient and consistent.

        It wasn't all good, of course, but it was a very good start. Applications tended to (want to) become more complicated than the OS would allow and they would sometimes start to take over the OS's tasks on their own as a result, but as a principle it was good.

        I still miss the lack of damn drive letters, obscure mount points and other arcane chicanery as everything was just assign points. The first versions of the OS didn't scale this concept too well but later revisions improved the handling considerably. Being able to access your application's assign point on the file system and not caring whether it was a diskette, CD, obscure mount point within the directories on a hard disk or even a remote file system was a delightful way to handle files. Libraries were handled by the OS and versioning was the norm - it could still lead to library (DLL in windows land) hell but unlike early Windows handling of such libraries it was manageable.

  3. Anonymous Coward
    Anonymous Coward

    A bit off topic, but...

    In the Node Knockout picture, are they ALL using MacBook Pros?

  4. Paul Ireland
    Thumb Up

    Haxe

    I think that nowadays any discussion on JavaScript and its use both client-side and server-side, should also include a mention of the Haxe language too. Haxe is JavaScript like language, but is more strongly typed (ECMAScript 5 is proposing some typing too), allowing you to write in a "safer" coding style, and then auto-translate your classes to other languages like JavaScript, ActionScript, PHP, C++ (with C# and Java planned in the future too).

    So Haxe is another option worth considering if you want one language for both client and server side web development, and I guess it should be possible to use it with JavaScript server-side environments like Node too, if it offers some other QA or flexibility/portability benefits.

  5. Peter X

    Why all the TIFFs ?

    FWIW .tiff files don't seem to render in Chrome -- so I can't see any of the images in this article. And who uses tiff files anyway... you weirdos! ;)

    1. mike panero

      I do

      Sometimes need >24bits on a picture like if it needs loads of correcting (say someone spilt coffee on the negative etc)

      And for that you need tiff, as far as I can make out (is there a 32bit PNG?)

  6. Anonymous Coward
    Anonymous Coward

    an iPhone app that lets you talk, listen, and leave voice messages

    So they've written an iPhone app that lets you use it like a telephone?

  7. yuriushakov
    Thumb Up

    Great article

    Hilarious and entertaining! Thanks.

  8. Rick Taylor

    So let me get this right...

    Node.js is just the Google V8 engine bolted on libev...

    Just like Twisted is Python bolted onto libev...

    Just like Ruby and Lua can/have been easily bolted onto libev or libevent...

    In fact, any language with the concept of callbacks or closures can be bolted on libev.

    So is the excitement that it's JavaScript they have bolted on top?

    Naturally, libev is written in C, and yes, I throughly recommend it to anyone who wants to do some serious Unix event-driven server development (I am not the author!)

    And... libev has limited support for Windows, and the author has no intention of making it better as the I/O model is so different.

  9. Anonymous Coward
    FAIL

    maybe he should've stuck with c++

    man 2 select

    1. Anonymous Coward
      Thumb Up

      @anon coward

      "man 2 select"

      Quite. Single threaded event driven programming is as old as the hills and using select() or poll() in C/C++ is pretty bloody simple for any coder with half a brain and is also the first thing you learn how to do when writing a network server app in C.

      In fact you don't even have to multiplex just network sockets with them , you can use unix sockets, pipes and other file system objects too thanks to Unix making socket and file descriptors equivalent in a lot of scenarios (unlike Windows). Try doing that with javascript "event" programming.

  10. KitD

    Node.js, event-driven et al

    The point about Node.js is NOT that it is JUST event-driven. Yes all you old farts, we understand that this is not new.

    The point is that JS gives you the syntactic sugar to string together multiple continuations into what looks like complete processes without the hassle of having to track "conversations". So you get something that looks like thread/request, but running underneath like event actors with the concomitant increase in throughput. Any language with good closure support can do this, but JS is the mainstream one ATM.

    BTW, there are other more performant frameworks doing this kind of thing on the JVM. Google Loft (Scala) and (as far as Java allows it) Deft Server (Java) for info.

  11. Anonymous Coward
    WTF?

    @KitD

    "multiple continuations"

    "complete processes"

    "conversations".

    "event actors"

    "performant frameworks "

    Sorry , I'm confused , was your post trying to make a point or was it just todays buzzword bingo game?

    Reading between the lines of all that guff I think you're saying that javascript makes it easier for script kiddies to write servers because all the actual hard stuff has been done in a library written by someone else.

    1. KitD

      Bingo

      Sorry you didn't understand my post. I had hoped the terms I was using would be familiar to those who have tried to do this stuff for real.

      But your final remark is true, up to the point that any framework or library is intended to make things easier for the user. So I'm not sure you can prove anything by it.

      BTW, there is a "Reply to Post" button.

      1. Anonymous Coward
        Thumb Down

        @KitD

        People who "do this stuff for real" talk about TCP or UDP, uni or multicast, sockets, (non)blocking descriptors, network interfaces, packet formats, I/O buffer sizes, retry loops etc. Not all that impress-the-dunces waffle you regurgitated.

        1. KitD

          Quite

          Doesn't that prove the point though of the benefit of libraries/frameworks that abstract over the nitty-gritty? (which I think is what you were arguing against. I'm not too sure. It's difficult to tell)

  12. Anonymous Coward
    Badgers

    @KitD

    Kit, you just proved your opponents point, nice own goal. To summarize your post:

    "event driven is hard, but Node.js give you 'syntactical sugar' to make it almost as easy as using a multi-threaded language which keeps state for you in the stack".

    That said, to the old timers: yes, its been possible to do all this forever, but now you can do it in a language that will run on *any* device. Kinda like Java promised, but for real this time :-P

    1. KitD

      You're probably right

      I just found it difficult to tell what his original objection was about. I suspect it was the "old fart" reference.

      Oh, and your summary was spot on. Thanks.

  13. chrisdew

    NodeJS, C, Old Farts and Script Kiddies

    This article has caused me to write about NodeJS, which we use on a day-to-day basis.

    http://www.barricane.com/2011/03/03/node-js-javascript-c-old-farts.html

  14. Nick Ryan Silver badge
    Coat

    Single threaded event driven programming...

    Single threaded event driven programming is new?

    No wonder I've been going so wrong when programming PLCs all these years...

  15. mangobrain
    Linux

    Event-driven "or" multithreaded?

    Certain people here, including - it would appear - the author of TFA, seem to think that the term "multi-threaded" is synonymous with using blocking I/O to service one session per thread, whereas "event-driven" is synonymous with using a single thread to service multiple sessions via the magic of non-blocking I/O. I hate to break it to you, but all "multi-threaded" means is that a process spawns multiple threads, it doesn't have to dictate an entire server architecture. In a similar vein, if when you say "event-driven" you really mean "uses non-blocking I/O", then just say so.

    The blocking I/O, one-session-per-thread architecture began life as one session per child process, on OSes where IPC doesn't suck, and fork not only exists but provides decent copy-on-write memory sharing - i.e. not Windows. It seems to have become fashionable to use the same architecture, but with threads in place of child processes, mainly because of a certain OS's handicapped notion of child processes. Oh, and because we're always told threads are difficult to work with, so being able to make them work must make you a l33t h4x0r, amirite? OK, so in-memory message passing can be faster than true IPC, but the genuine potential benefits of multi-threading don't seem to be the main reasons why people use it.

    On the other hand, a *single-threaded* event-driven architecture will very quickly stop performing if you actually need to do anything CPU-bound with your data, as opposed to simply shunting it from source to sink. Notice, though, that at no point have I mentioned multi-threading (using the real definition, not the article's definition) and event-driven concepts being mutually exclusive - you'd just better do it that way from the ground up, because bolting multiple threads onto existing single-threaded code is no less a recipe for disaster than trying to turn blocking procedural code into non-blocking event-driven code. I'm not saying it's easy to get right, either; you can find yourself bogged down by the overheads of things like context switching and message queue locking very easily. Don't try and do it on Windows, either, because IME it just doesn't have the APIs to do the approach justice.

    Nowt wrong with a bit of C++; if you can learn to use the POSIX socket API, your understanding of pointers and memory management ought to be up to snuff for most things you'll need to do in the real world. (Bloody sockaddr structures, bane of my existence.)

    Oh, and I'm only in my 20s, so hopefully there is *some* hope for future generations....

    1. CD001

      Aahhh...

      But I bet you are one of the "rare" hobbyists who then went on to do this stuff professionally? Someone who actually enjoys poking about with the software and learning how to actually get it to talk to the hardware (without an interpreter), who, had you been a wee bit older, would have copied the source code for Manic Miner for the BBC model B from a magazine and then spent hours debugging it and getting the glitches out just to see if you could!

      Many "younger" programmers don't seem to _want_ to know more, aren't prepared to look "under the hood" and many (unfortunately) don't know anything outside Windows ... or worse yet, .NET - if it can't be done in .NET they're stuffed.

      For them it's just a job - some of us, and I'm guessing you're one, actually love this shit :)

  16. YumDogfood

    Premature optimization is the root of all evil

    All this newbie code monkey jabbering, click-jerk down-voting and inter-generational cluebat swinging. I really, really, really, could do with a few pints about now to deaden the pain of it all.

    Oh yes, I was going to say something about measuring bottlenecks, profiling and such. Too late, I've already got my coat on. Have a good weekend all.

  17. maxant
    FAIL

    What I don't get...

    I read this and was not impressed. Long before I would decide to build a library for Javascript so that I could build a VOIP server based on it, I would exhaust all the other options... Like people here have already said, C++ similar would be fine. What takes less effort? Developing Node JS, or learning how to use an existing, mature and well supported language?

    So I blogged about it: http://blog.maxant.co.uk/pebble/2011/03/05/1299360960000.html

    Summed up: it didn't take long to implement a little Java app capable of doing what the author of Node JS was wanting to do - have a server capable of using up all the possible ports for incoming requests.

Page:

This topic is closed for new posts.

Other stories you might like