Forgot your password?
typodupeerror
Image

Book Review: Sams Teach Yourself Node.js In 24 Hours 112

Posted by samzenpus
from the read-all-about-it dept.
Michael Ross writes "Since its introduction in 1994, JavaScript has largely been utilized within web browsers, which limited JavaScript programmers to client-side development. Yet with the recent introduction of Node.js, those programmers can leverage their skills and experience for server-side efforts. Node.js is an event-based framework for creating network applications — particularly those for the Web. Anyone interested in learning this relatively new technology can begin with one of numerous resources, including Sams Teach Yourself Node.js in 24 Hours." Keep reading for the rest of Michael's review.
Sams Teach Yourself Node.js in 24 Hours
author George Ornbo
pages 464 pages
publisher Sams Publishing
rating 7/10
reviewer Michael J. Ross
ISBN 978-0672335952
summary An introduction to the Node.js framework.
This book, authored by George Ornbo, was released by Sams Publishing on 15 September 2012, under the ISBN 978-0672335952. The recent publication date is promising, because Node.js is evolving rapidly, thus gradually obsoleting books written not that long ago. On the publisher's page, visitors will find a brief description of Ornbo's book, a few customer reviews, the table of contents, a sample chapter (the 14th, "A Streaming Twitter Client"), and links to purchase the print and electronic versions of the book. There is also a link to the companion site, which offers some of the same content as Pearson's page, but also has a link to download an archive file containing all the example code, nicely organized.

The book's material spans 464 pages, and is organized (shoehorned) into 24 "hours" (chapters), grouped into six parts. The first two chapters in "Getting Started" explain how the reader can download Node.js, create a "hello world" web server program, install new modules using npm (Node Packaged Modules), search for modules, locate documentation on them, and indicate module dependencies for an application. Unfortunately, the blocks of source code presented in the first examples (Listing 1.1 and Figure 2.2) are not explained in the narrative (until the fifth chapter) or even commented. Readers would likely appreciate some clues as to the nature of http.createServer, req, res, the "underscore" module, etc. — especially at the beginning of their journey. If readers are not expected to understand these details at this point, then they should be told so, to avoid any concerns that such an understanding is assumed in the subsequent chapters. The author does not explain where Node.js is installed or what changes it makes to the terminal's default path variable. On page 18, the term "project folder" is unclear: should the "underscore" module end up in hour02/example01/node_modules, or nodejs/node_modules, or nodejs/node_modules/npm/node_modules? Only later is this (partially) answered.

Chapter 3 demonstrates the complexity that arises from concurrent input/output in networked applications. This material should arguably have been presented at the beginning of the book, to better establish the purpose of Node.js, and the value to the reader of studying it. The next chapter summarizes jQuery and JavaScript callbacks, and then provides a helpful discussion of how Node.js uses the latter. The author contends that the asynchronous paradigm of Node.js is unsuitable for long-running processes, but does not explain why this is true, which would have provided some substantiation for the claim.

The second part of the book, "Basic Websites With Node.js," encompasses four more chapters. The first one discusses how to: create a simple server (using the core HTTP module), examine the response headers (generated for web pages, in different browsers and on the Linux command line), execute 301 redirects, respond to different types of requests (using the URL module), and create a simple client. Oddly, the author does not explain or even mention the sizable JSON output — the first line of which is "{ domain: null," — displayed in the reader's server terminal when the web page pointing to that server is refreshed or when the "curl -I" command is run. The next two chapters cover how to build websites using the Express framework, and are likely the first point where the reader will see some of the real-world complexity of Node.js. The eighth chapter explains how to persist data between calls to the application, including files, environment variables, and MongoDB.

Debugging, testing, and deploying are all critical topics for any application development, and are covered in the third part of the book. The author illustrates three methods of debugging: STDIO, a core module, is a lightweight method for debugging Node.js code; it allows one to output messages to the console, check the value of any variable or literal, and track function calls and responses from third-party services. Node.js provides access to the more powerful debugger of V8 (the Google Chrome JavaScript engine), which supports breakpoints and code stepping. Node Inspector, compatible with WebKit-based browsers, provides all of the above functionality, and more. The next two chapters present several modules that ease the important process of creating full-coverage tests, and demonstrate how to deploy applications to any one of three Node.js-capable cloud hosting providers (Heroku, Cloud Foundry, and Nodester).

Having covered the basics of Node.js, the author begins the fourth part of his book with two chapters that show how to use Socket.IO, WebSockets, and Express to build real-time web applications. These techniques are illustrated in the development of a chat server as well as a nickname management and messaging system. The aforementioned sample chapter extends these techniques further in working with the Twitter API to consume its real-time data, push it to the browser, and show results in a dynamic graph. This section is wrapped up with coverage primarily of JSON — specifically, how to create, consume, and send JSON-structured data.

APIs were addressed briefly in the previous section, but are explored much more deeply in the subsequent five chapters. Readers may initially conclude that the discussion of processes is elementary, but the author then shows how one could utilize that knowledge to interact with Node.js scripts, including detecting script exits and errors, sending signals and arguments to a script, generating child processes if needed, and sending messages among them. In the 18th chapter, the author goes into greater detail about Node.js's Events module, best practices, and how to generate event listeners dynamically. The buffer API may be low-level, but it is essential for storing raw binary data, as opposed to the Unicode-encoded strings that JavaScript uses within a browser. The Buffer and Stream modules are presented with plenty of helpful examples.

The last part of the book addresses miscellaneous topics, starting with CoffeeScript (a JavaScript precompiler). While CoffeeScript affords numerous benefits, it is not clear why it would deserve an entire chapter in a book dedicated to Node.js. In the next chapter, readers learn how to verify their Node.js code, add command-line executables, and then package it all up into portable modules that can be contributed to the npm registry or GitHub. The last two chapters explain how to create and configure middleware using the Connect module, and how to use Backbone.js (a front-end JavaScript framework) in conjunction with Node.js to build browser-based web applications.

Each chapter concludes with a summary (invariably a waste of space), a Q&A section, a workshop comprising quiz questions (with the answers presented immediately below it, for almost instant spoiling), and several exercises for the reader.The index at the end is missing several of the important topics discussed in the text.

The book contains many errata: "EBay" (page 1; should read "eBay"), "OSX" (page 9; presumably Mac OS X), "yaml" (page 15; should read "YAML"), "irc" (19), "led to [a] great deal" (27), "to solve Concurrency" (37), "process" (54; should read "processes"), "try and" (55; should read "try to"), "This goal" (56; should read "The goal"), "how [a] class" (56), "You will [see] the" (62), "status of [a] web server" (70), "javascripts" (77), and "then [the] name" (87). At this point, less than 20 percent into the book, it was clear that the copyeditors had done a sloppy job, so I stopped recording these flaws that should have been caught. Those first four errata suggest that "textese" is even pervading the world of technical publishing. (Strangely, there does not appear to be a place on the publisher's website for reporting errata.)

The production team should have been looking for places to cut down on the heft of the print edition. The "Try It Yourself " sections sometimes duplicate what is found in the regular text nearby — especially in the third and fourth chapters. For instance, three sets of HTML markup are repeated, as well as the surrounding discussion (pages 42 through 47).

In general, the text does not appear to have been carefully scrutinized by technical reviewers and copyeditors. Occasionally the reader is given critical information later than would be optimal, e.g., the "Watch Out" warning on page 18, provided after the reader installs a module. The writing style is noticeably awkward in countless places in the book, including several run-on sentences. (Technical authors should not be bashful in using commas when doing so would help readability.) Also, the text is littered with too many exclamation marks — as if that is going to make any narrative more exciting.

In terms of the production quality of the book, a lay-flat binding would have made it much easier to read when using both hands on the keyboard. Also, in my review copy (kindly provided by the publisher), a disappointingly large number of the pages had small black splotches of ink; fortunately, none made the text unreadable.

On the other hand, Node.js is certainly not a simple subject area, and this book is able to convey a lot of information about it. This book's forte is the extensive use of example code to illustrate the concepts being presented. Incidentally, kudos to the author for inviting the reader to contribute to the Node.js community, such as adding new modules to GitHub or updating the documentation of existing modules. Overall, readers new to Node.js would certainly benefit from working their way through this volume.

Michael J. Ross is a freelance web developer and writer.

You can purchase Sams Teach Yourself Node.js in 24 Hours from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

*

This discussion has been archived. No new comments can be posted.

Book Review: Sams Teach Yourself Node.js In 24 Hours

Comments Filter:
  • Yup (Score:4, Funny)

    by gazbo (517111) on Monday December 10, 2012 @04:32PM (#42245541)
    Before node.js it was literally impossible to use JS on a server. Thanks Node!!!1
  • by Anonymous Coward on Monday December 10, 2012 @04:33PM (#42245563)

    In my experience the hardest parts(for a relatively novice javascript programmer with less than a year of production experience) the hardest parts of whipping up something that scales is the hard part, so that you don't run into connection limits(imposed by os) or node.js failing in funky undocumented ways due to too many half open connections or connections failing on negotiation part. Also a lot of the popular libraries for Node.js are buggy in the parts that matter - like socket.io(a new version should be pushed out soonish that hopefully fixes things the maintaining team has previously claimed working.. like scaling over multiple instances properly without leaking connections).

    Still, Node.js is my new favorite light scripting environment. Just because I hate Python. I so very much hate Python.

  • or.. (Score:1, Funny)

    by tracius01 (2541214) on Monday December 10, 2012 @04:33PM (#42245565)
    how not to learn node.js in 24 hours
  • by Anonymous Coward on Monday December 10, 2012 @04:35PM (#42245581)

    Looks interesting, I'll have to checkout the e-Book and see if it is any good. Some "24" hour books have been sloppy.

  • by schneidafunk (795759) on Monday December 10, 2012 @04:43PM (#42245663)
    What are the benefits of using javascript on the server side over a more typical server side programming language?
    • Re:Benefits (Score:5, Funny)

      by Spy Handler (822350) on Monday December 10, 2012 @04:49PM (#42245719) Homepage Journal

      you can add cool sliding divs and blinking banners to your server console UI.

    • by Anonymous Coward on Monday December 10, 2012 @04:49PM (#42245721)

      It's easier to write less efficient spaghetti code since even mouth-breathing web scripters can use it.

    • by betterunixthanunix (980855) on Monday December 10, 2012 @04:54PM (#42245773)
      The question is not, "what makes this better than languages that people typically use to write programs that run on servers?" but rather, "What is the benefit of Javascript as a language, and how can it make writing/maintaining applications easier?" or perhaps, "How can using Javascript make me more productive?"
      • by Anonymous Coward on Monday December 10, 2012 @05:15PM (#42245971)

        What makes this better than languages that people typically use to write programs that run on servers?

        Nothing.

        What is the benefit of Javascript as a language, and how can it make writing/maintaining applications easier?

        No benefits, no ease.

        How can using Javascript make me more productive?

        Unless your productivity is a function of rage, it cannot.

        • by Unnngh! (731758) on Monday December 10, 2012 @05:26PM (#42246107)
          Lexical scoping, fast interpreted language, automatic memory management, same language client and server-side, dynamic typing, are all good reasons to use it, if you actually want all these things; otherwise there are almost certainly better choices. JavaScript is a really nice language if you ignore the parts of it that are terrible. The language is largely mis-understood and has a long history of abuse at the hands of those who mis-understand it. This is a real problem if you want to build a maintainable system and all the developers don't have a clear view of how to program well in JavaScript. The language is more like Lisp (specifically Scheme) than it is like Java, but not that many people know or even understand the idea behind Lisp nowadays. I would think that the resurgent interest in functional programming would ameliorate this to some extent but most of the JS I've worked on is crap and I would strongly recommend against using it unless you have a clear picture of why you would want to do so.
          • by VoidEngineer (633446) on Monday December 10, 2012 @05:37PM (#42246215)
            Well stated. The sharing of language client and server side is the biggest practical benefit, in my experience. And yes, it's important to have a clear understanding of how Javascript is related to Lisp, what lambda calculus is good for, and what that entails by the way of anonymous methods, closures, and the like. That being said, if you understand those things, programming with node.js and associated frameworks (like derby, meteor, etc) is like surfing in Hawaii..
            • by AaronLS (1804210) on Monday December 10, 2012 @10:01PM (#42248245)

              Having the same language client and server side definitely is a big plus, and something I've strongly desired for a long time. There's alot of things you can do server side that you can't do so well client side due to lack of implementing libraries in the client-side language.

              I just wish it was with a different language. Not trying to flame JS, just not my personal preference if I had to code a medium or large application/API/framework.

              I really think desktop applications could have done this, but various shenanigans made it difficult to do this successfully on a wide enough range of devices without a great deal of trouble.

              • by rioki (1328185) on Tuesday December 11, 2012 @10:15AM (#42250070) Homepage
                "I really think desktop applications could have done this, but various shenanigans made it difficult to do this successfully on a wide enough range of devices without a great deal of trouble."

                The great deal of trouble came from differing *implementations* of Java Script in the browsers over the past decades. Luckily this has died down somewhat and the wide adoption of things like jquery helps. But the big deal about node.js is that it is V8 and period. I needed to relearn Java Script from the last time I looked at it in the 90s, but once that was done it really was like "surfing in Hawaii".
            • by ahabswhale (1189519) on Tuesday December 11, 2012 @12:50PM (#42251547)

              Saying javascript is like lisp, is like saying a pool is like the ocean. Really not the same beast at all and you certainly don't need to know a thing about lisp to be good at javascript.

          • by Anonymous Coward on Monday December 10, 2012 @05:52PM (#42246341)
            That sounds like PHP or Python, except for the part about using the same language the UI guy is copy/pasting in.
            • by MightyYar (622222) on Monday December 10, 2012 @07:17PM (#42247081)

              I actually find that I can do a lot of things in Javascript in a way similar to how I do them in Python (which is my favorite). I don't have the strong visceral hatred for PHP that other folks do, but I can definitely see how Javascript and especially Python are superior. Most of the problems I have with JavaScript have to do with how the individual web browsers implement it, the tendency to fail silently, and the looseness of the syntax in general. Python, except for typing, is a much bigger hard-ass - and that's the way I like it! :)

            • by K. S. Kyosuke (729550) on Tuesday December 11, 2012 @12:34PM (#42251341)

              That sounds like PHP or Python

              Neither PHP nor Python are actually fast, unless you count PyPy, and PHP and scoping? Uhh...they fixed some stuff, but in a ridiculous way, and...uhhh...when you read the PHP docs and find stuff like "[create_function] creates an anonymous function from the parameters passed, and returns a unique name [sic!] for it", you should shudder at the PHP creators' notions of logic.

          • by epine (68316) on Monday December 10, 2012 @07:31PM (#42247179)

            I would think that the resurgent interest in functional programming would ameliorate this to some extent but most of the JS I've worked on is crap and I would strongly recommend against using it unless you have a clear picture of why you would want to do so.

            I'm taking an online course on MongoDB. This caused me to look into JavaScript and Node after a long hiatus concerning the web application stack.

            We're deep into the territory of people confusing a tool with the culture of its use. JavaScript appears to be a fairly decent language of Scheme derrivation, minus one horrible blunder on scoping rules (to be addressed, perhaps in the worst possible way, in the next language standard). I'm given to understand that many of the horrendous web applications out there involve heaps of disorganized JavaScript maintaining application state via DOM edits. What could possibly go wrong? Is the language at fault, or the culture of its use? Hint: one of these answers takes more than five seconds to justify, so you might find it time efficient to run with the first answer that comes into your head. No one ever got fired for spewing blame in the widest possible arc.

            Node.js itself is a strange beast. There's something to be said for language plasticity, of not having to prematurely bind code to server or client. Adopting an entire world-view to make this possible is the domain of fools and zealots. Today's zealots are tomorrow's gurus. Gurus don't grow on trees, after all.

            I write a fair amount of code in R, also from the Scheme family tree. Are there any people out there who think that JavaScript sucks, but R doesn't? Wow. I'd be interested to hear that argument. No wait, with an infinite number of monkeys, all languages suck, by the simple statistical principle that natural languages are denser in idioms of derision than admiration. It's almost as if our languages know something about us. Hey, no one ever got fired for spewing blame in the widest possible arc.

            I've said this before and I guess it's my fate to keep repeating this observation. There's a litmus test across the language like/despise spectrum of attitude toward one's fellow humans. If you hate your fellow humans, you most favour languages that offer facilities of orthodoxy, control and prevention. On the other hand, if you believe that your project is so difficult that only by the miracle of collaboration and teamwork can the project be completed at all, then you tend to value languages with the fewest expressive impediments, whether the nail-gun interlock works or not.

            I've read many times about small teams doing big things with C++ and remarking about the language's unbearable legacy of self-harm "we're professionals: we rarely have a problem with it". If you're an ambitious code monkey and the coder beside you working on the same project was fathered by a dangling pointer, you really hate C++. No power under the sun can prevent the dangling pointer from making you also look bad.

            I would certainly use Node.js, but with great caution. It won't maim your appendages like C++, but it will paint you into a corner (a certain asynchronous world view) if you don't understand its long term limitations. This is why I ultimately rejected my online MongoDB course. It taught you enough to get yourself into trouble (deep trouble), but not enough to get yourself back out again.

          • by Xest (935314) on Tuesday December 11, 2012 @06:19AM (#42248942)

            "JavaScript is a really nice language if you ignore the parts of it that are terrible."

            I'm sure Hitler was a really nice guy if you ignore the bits that were terrible too, but that doesn't strike me as a particularly strong argument for something being good.

            Let's be honest, people use Javascript because it's the only serious client-side scripting language supported by browsers. If browsers supported a number of languages client-side, including some of the most popular ones about in general today, I suspect Javascript would be far down the list of popular choices.

            Though I do agree with much of what you say, it is a primarily functional language and most people don't get that, though I would argue that's part the problem in itself. Functional is neither the most common or arguably even the most natural programming paradigm to work with, so when people start learning to programming it's unlikely they'll learn in the functional way.

            But regardless, I think the whole HTTP stack is past it's prime anyway in terms of the way it's trying to be mangled into a web application platform. I think we need a new platform for web applications, built from the ground up. HTTP and it's related technologies like XHMTL, CSS, Javascript and so forth should be relegated to what they're good at - document production and presentation, not continue to try to be shoe-horned into wider application developement.

            • by nzhavok (254960) on Tuesday December 11, 2012 @07:01PM (#42255027) Homepage
              I wouldn't say it's primarily a functional language at all, it certainly contains functions and you can use it in a functional way but the same can be said of many non-functional languages.

              The killer features of Javascript are:

              1) Lexically scoped closures
              2) First class functions

              And more importantly it's the combination of these two features which allows you to create, on the fly, lexically scoped first class function objects.

              This is incredibly useful in many situations and is justification by itself to put up with the uglier parts of the language. If someone is not used to using closures (and let's face it, the vast majority of programmers are not) then it is difficult to appreciate why this would be useful but I'll list a couple of very generic scenarios:

              1) It allows the programmer to defer execution of code to a later point whilst allowing a state to be associated with it.
              2) It allows the programmer to deal with many small blocking I/O operations concurrently.

              These are not remarkable things in themselves however it is difficult to do them programmatically without threads, and once you start using threads you have already lost.

              Years ago I was working as a consultant for Lufthansa and was working on a system that dealt with a significant proportion of Europe's air cargo. There were a lot of messages being sent about that we needed to capture and process. The system we eventually developed was a multi-threaded Java application which replaced a single-threaded C application. It worked pretty well and was about twenty times faster than the C one. Having worked with Node.js for over a year now in some similar scenarios I am confident that it would out compete the Java app easily, and with a fraction of the code, perhaps 20-30%.

              Of course if you're not writing the kind of code that needs multiple threads in a conventional language, or code that is dealing with a lot of blocking I/O, then you may not see any benefit in writing something in Javascript. However once you have got used to closures going back to something like Java is like trading in your motorbike for a delivery van.

              Javascript is here to stay, it probably has more money spent on it than any other language right now. The current version has got rid of a lot of the ugliness and if you are running node then you don't need to worry about globals, modules or block scoping. The next version should be out soon and many features which are designed to allow JS to become a compile target for other languages (like it is for coffeescript now). Many of these features are already implemented in the JS engines such as V8 and Rhino.
    • by shdowhawk (940841) on Monday December 10, 2012 @04:54PM (#42245775)
      It's very lightweight/fast so things that often hit the server side with ajax calls benefit. Example: gmail checks for updates every few seconds and then uses javascript to update the gmail interface without refreshing. That's a good example of where node.js work well.
      • by multicoregeneral (2618207) on Monday December 10, 2012 @04:59PM (#42245827) Homepage
        Yeah, but you're suicidal if you put it on anything with traffic.
        • by Anonymous Coward on Monday December 10, 2012 @05:11PM (#42245925)

          depends on what you mean by 'traffic'. what sites do you know of running node that don't perform well? I've read the criticisms of node, just haven't seen one of these node sites explode like the critics keep claiming.

          thx

        • by VoidEngineer (633446) on Monday December 10, 2012 @05:47PM (#42246291)
          Mmmm, maybe if you have only a single node. But a cluster of node servers can scale as well as you're ever going to hope for. And for real time applications, I'd much rather have a cluster of well-behaved optimized node.js threads than hoping a black-boxed apache thread won't decided to randomly fork and/or block.
          • by multicoregeneral (2618207) on Tuesday December 11, 2012 @03:35PM (#42253299) Homepage
            Yes, but do you see what you're doing there? You're throwing money at a problem, to get away from inherently poor architecture and bad design. Dude, you can make anything work if you throw enough hardware at the problem. You shouldn't have to scale your hardware to use basic features (Perl had this figured out in 1996) like parallelism. It's asinine.
            • by nzhavok (254960) on Tuesday December 11, 2012 @07:14PM (#42255131) Homepage

              Yes, but do you see what you're doing there? You're throwing money at a problem, to get away from inherently poor architecture and bad design.

              Yes, but do you see what you're doing there? You're constructing a strawman, to get away from your unsubstantiated claims.

              Dude, you can make anything work if you throw enough hardware at the problem.

              Actually you can't.

              You shouldn't have to scale your hardware to use basic features (Perl had this figured out in 1996) like parallelism. It's asinine.

              Which is why perl explicitly bans clustering of any sort.

            • by VoidEngineer (633446) on Tuesday December 11, 2012 @08:15PM (#42255645)
              I see it differently. I see it as an issue of encapsulation. The issue is whether one is going to encapsulate the parallelism inside of a thread, or inside a machine, or inside a network. From an operations perspective, a thread is usually an opaque black-box, with few controls for the operations team to manage whether they want to scale a process up or down, add extra resources, migrate to different hardware, do disaster recovery fail over testing, etc. And having been in operations for many years, I like to expose controls in my application designs that allow operations to manage those parallelism features. And so, when it comes to encapsulation, I tend towards encapsulating parallelism with a hypervisor, rather than with a thread.

              The idea isn't to just scale *hardware* (although that's one way of doing things). Rather, scale the virtual nodes within a hypervisor environment. Then, if you're using a 32 core server, run 31 virtual node servers, with each node server running on one core, and with one optimized dedicated thread per CPU. The last core gets used by the hypervisor itself to manage inter-node infrastructure. The end result is a virtual network running on a multi-core server, and is essentially just this generation's version of a mainframe architecture.

              There are, of course, pros-and-cons to this approach. Some things you gain, while others you loose. But as far as scaling goes, one doesn't need to scale hardware to use parallelism. Just need to have a hypervisor with some micro-sized virtual machines. I like to keep my virtual machines running node.js at about 256mb of disk space. But when the time comes to go parallel with hardware, everything is already set up to.
    • Re:Benefits (Score:4, Insightful)

      by i kan reed (749298) on Monday December 10, 2012 @04:54PM (#42245781) Homepage Journal

      Your boss can say "Oh you're not a server developer? You are now! Experienced engineer who's familiar with backends, you're fired!"

    • by Anonymous Coward on Monday December 10, 2012 @04:55PM (#42245783)

      If you are most comfortable with JS, or only really know JS...

    • by Synerg1y (2169962) on Monday December 10, 2012 @05:03PM (#42245863)
      Maybe to let UI only devs write for the server side? I once interviewed for a UI position that had AJAX listed in the requirements because the UI's they were making (or something...) had heavy server side integration, so UI code > a lot of server code. Other than that, I could've sworn this was tried and eclipsed before.

      Can't believe nobody has mentioned this yet, but 3... 2... 1...

      JS programmers belong on the UI side because:
      a. Server side code requires a lot more factors to be considered (ex. viewstate (.NET), rendering, # of calls, etc...)
      b. The web is trashed with bad javascript, I'm not saying server code is much better, but at least I don't have to see it on a view page source. Too many JS programmers don't understand how to "link" their .js files...
      c. It's different enough from server side development that coupled with html and css development can easily eat through 40 hours a week every week.
    • by Trepidity (597) <delirium-slashdo ... g ['kis' in gap]> on Monday December 10, 2012 @05:09PM (#42245909)

      One advantage sometimes touted is that you can reuse code between server and client sides, or even move it between the two as changing needs dictate. For example, you could use the same syntax-highlighting code to syntax-highlight "offline" on the server side and "online" in a live client-side text field.

      • Re:Benefits (Score:5, Interesting)

        by VoidEngineer (633446) on Monday December 10, 2012 @06:05PM (#42246479)
        It's actually a really huge advantage, if done correctly. A trivial example: I'm working on an app that has a file import functionality, so I wrote a half dozen helper functions to parse a spreadsheet into JSON. Later wound up using those same functions on the server to implement an XML interface. Business logic is the same in both instances, and having a single language for both server and client allows that business logic to be stored in a single place, maintaining the Don't Repeat Yourself (DRY) rule of thumb. Having a single language on both server and client is a godsend for keeping your app DRY.
    • by Fallingcow (213461) on Monday December 10, 2012 @05:18PM (#42246025) Homepage

      The idea is that you can share code (say, data models) between the client and server. IMO this is an awful reason to suffer through Javascript, though.

      Node in particular handles async IO for you, which means it saves you from learning threading, or an async IO framework in some other language like Python or Ruby, or learning Erlang, or any number of other better things you could do with your time. The cost is callback soup, and having to use Javascript.

      Node's package manager, NPM, makes it super-easy to set up 5-line demos of WebSocket echo servers and such, which pulls a lot of people in. Tends to be messy as hell once you get past 100 lines or so (of Coffeescript, mind you, which is what you'll have to use to maintain your sanity even that long), especially if you need more than one source for IO (say, read from RabbitMQ and Redis, output over Websockets and XMPP, or whatever—basically anything you could use it for that's interesting). You pay for the up-front ease with constructs that get excessively complex later on, IMO.

      Also, there's no excuse whatsoever to use it in a case where you're simply writing a REST api or a typical website. There are way, way better tools for that kind of thing, namely anything that's not NodeJS, with an appropriately-designed cache in front of it, and a well-configured webserver.

    • by Anonymous Coward on Monday December 10, 2012 @05:18PM (#42246029)

      What are the benefits...?

      Node is very simple. The server is V8 and your code runs in V8. There are no layers or extra overhead. The server is just another command line tool you run and Ctrl-C while iterating.

      V8 is fast. It doesn't interpret. It just compiles everything to machine code and executes.

      Node is a single threaded non-blocking environment. You do everything with lambdas/closures and nothing blocks. The is an elegant and pleasant way to program.

      Just a few of the things that occur to me as I think of my experience with Node.

      • by akeeneye (1788292) on Monday December 10, 2012 @05:53PM (#42246363) Homepage
        I've just started messing with Node, and so far it's fun, but it's nothing that lives up to what the fanboys who I know have implied. They seem to think it's got some kind of secret sauce to it that makes it unbelievably fast, completely stomping those Average Bargain Brand web frameworks that have been put together by ignorant clods who don't understand networking or application design. These fanboys are mostly JS devs from client-land who have taken some long drags on the Hype Pipe, and I suspect that many like them are behind all the Node noise. Mostly Node feels to me like an ultra-lightweight wrapper around my code. It makes me think of the minimalist Python frameworks I've assembled from parts like CherryPy and Genshi. The parent made a good analogy of it to a command line tool. I hadn't thought of it that way, but yeah. If you write your app code in CoffeeScript you'll be able to enjoy using a modern language with Node, or at least the illusion of one until it gets compiled.
        • by rioki (1328185) on Tuesday December 11, 2012 @10:46AM (#42250361) Homepage
          Node's biggest strength lies in doing nothing. That is not wasting CPU resources while waiting on something. By having concurrency though asyncronality instead of threads you have no overhead in the operating system to switch threads and "waking up" pending tasks is computationally trivial. Node.js shines where your application is mostly waiting on something, like a database of file system and as it happens that is what most web applications do. If you want raw computational power, take C or FORTRAN and don't start with python.

          Funny that you mention CoffeeScript... Don't ask me why but for me it is reversed, CoffeeScript looks like someone vomited code in his editor... But that is only the ramblings of a hardcore C programmer... ^_^
    • by jellomizer (103300) on Monday December 10, 2012 @05:22PM (#42246057)

      Primarily the benefit is that a Full Web Application can be done with one language.
      For some people switching between languages gets in the way, of writing uniformed code.
      Also I would expect that it would allow for easier movement from the prototype running in the browser and moved to the server.

      Or if you want to be more computer science purist. You can reuse functions and classes on your browser and on the server side. Often in web development you have to write code twice that does the same thing, because the browser will do an initial check, and the server will do the final (more secure) check. That and you will be using similar data structures.

    • by Anonymous Coward on Monday December 10, 2012 @05:30PM (#42246153)

      Casuals think it's cool

    • Re:Benefits (Score:5, Interesting)

      by Kergan (780543) on Monday December 10, 2012 @05:37PM (#42246213)

      What are the benefits of using javascript on the server side over a more typical server side programming language?

      You get to write every possible thing you need to use for your app, including basic things that aren't functional in the handful existing (albeit very dysfunctional) libraries.

      *Ducks*

      In all seriousness, there's a sweet spot when you're writing some app that needs a real-time, state-full, non-blocking environment, such as a chat server. There are of course alternatives, but this is what node.js was designed for.

      It does a good job at it, too, as long as you don't mind the tons of callbacks (read: impossible to follow spaghetti code), and the lack of decent debugging tools (unless this changed since last year?), the scarce (and occasionally unmaintained, and frequently buggy) libraries related to much about anything useful.

      My (admittedly scathing) take on node.js is this: it was created by a someone with a specific need, lots of love of javascript, and time to spend on reinventing the wheel instead of using more mature tools for the job. Many credits to him for being such an enthusiastic hobbyist who then open sourced his work. The issue is, it then got picked up by an army of web designers, as opposed to actual programmers. They thought "Oh great I can now code server stuff too!" and went off to write a library or three. And it shows, because nearly all of the libraries in question are borderline unusable except in very specific cases.

      In practice, node.js is a horror story littered with writing your own libraries for much about everything because testing existing ones revealed that they suffered from either or all of a missing feature, too many bugs, no maintainer, etc. As a hobbyist and potential library contributor, go there; you're much needed, and you'll even have fun if javascript turns you on. For actual development, just don't -- not even with a 10-foot pole.

      • by arkhan_jg (618674) on Monday December 10, 2012 @09:16PM (#42247983)

        does a good job at it, too, as long as you don't mind the tons of callbacks (read: impossible to follow spaghetti code), and the lack of decent debugging tools (unless this changed since last year?), the scarce (and occasionally unmaintained, and frequently buggy) libraries related to much about anything useful.

        If you're writing a bunch of nested anonymous callbacks, you're doing it wrong - as you say, it looks ugly as sin and is a bugger to debug. Plus it means you may well be trying to wedge a synchronous workflow onto an asynchronous model. Either use something like async to get your control flow looking much cleaner if you absolutely must do things in specific order, or use events to announce when a section is done, so a pre-set listener can kick off the next section. Javascript is a very event driven language,and embracing as such drastically simplifies code.

        I'm not going to deny there are a bunch of unmaintained buggy modules out there, especially as node is evolving so quickly. But then, the same could be said about pretty much any frame work or open-source platform. As long as you stick to the 'mainstream', big modules, they're solid and do the job, and there's plenty of those now - it's a lot more robust environment than it was a year or two ago, and it will no doubt continue to mature.

    • by amaupin (721551) on Monday December 10, 2012 @05:50PM (#42246311) Homepage
      Node.js is an event-driven system utilizing callbacks on a single thread. (So after requesting data from the database Node can continue responding to other events until the database comes back with an answer - it doesn't sit there waiting.) Javascript is particularly suited to this environment due to anonymous functions and closures.
    • Re:Benefits (Score:4, Funny)

      by arkhan_jg (618674) on Monday December 10, 2012 @08:46PM (#42247751)

      It's faster than liquid manure off a buttered shovel.

      More seriously, node.js - as it's javascript - is ideal for asynchronous, non-blocking apps. When you think about a website, you need to be able to handle request n+1 promptly while you're still working on request n. i.e. while you're waiting for that database query to come back with the data you need to handle request n, you can still handle that entirely different new request without waiting for the first to finish.

      The whole design of node.js is to do that, and do it well.

      Node isn't the only server platform that works this way - python twisted springs to mind - but node has a built in event loop library that everything uses, whether it's your own code or plugin in modules. It makes it utterly trivial to add event listeners to 3rd party module events in your own code, and mix them in with your own event emitters for your own logic seemlessly. This is also handy when doing behaviour driven development with mocha (for example) - you can just add hooks to events in the code you're running the test suite to check it's working, and mock out inputs and even modules.

      The other option is callbacks, which are also universally supported. Call a function from a module (or your own), and pass a callback argument along with it - when the called function completes, it passes back the error and results to the callback. Big whoop. The key thing is that callbacks are non-blocking - so your server will happily be getting on with other things in the meantime. One mistake it's easy to make though is nested callbacks; if you want to do function A, B and C in order, it's easy to fall into the trap of putting B as an anonymous function in the callback of A, and C as an anonymous function in the callback of B - which rapidly leads to a horridly complex bit of nested code. You can either use a helper module like async, which gives you various options for running functions serially without writing a horrid mess; or use your own event emitters to announce when they're done, and have a listener wait for that to trigger the next step.

      One of the strengths of node is that you can easily build up your own server from modules. Ruby on Rails is fine if you want everything under one roof, and done the One True Way, but if you want to mix-n-match your own modules - web server, middleware, nosql or key-value store, imap, smtp, etc etc to fit in with your own code, then node is the way to go. This does mean you might need to do a bit more work putting the framework together, but you can use something like Express and its various addons to do most of the boilerplate for you with regards routing logic, static resources and middleware if you're doing a classic web app. JSON and binary buffers are built in to node, so you can easily handle AJAX responses and file streaming with minimum effort.

      In fact, everything is a module, and it's trivial to add in your own modules - and variables are local to that module, so you only end up with globals if you specifically ask for them, so avoiding polluting the namespace no matter how many modules you use.

      The last really huge strength of node.js is socket.io. Going from the one-way client-to-server ajax model, with a kinda kludgy server-to-client channel (xml long polling) to a true two-way server-client model so your server can directly send information to your client-side code without waiting to be asked for it is really, really powerful for truly responsive web apps - and will fall back to long-polling if using an older client that doesn't support it, so you don't have to hack about. It's arguably the most powerful feature of node - makes real-time apps an absolute walk in the park.

      OK, yes, it's javascript. Scoff away. Personally, I don't find it a problem, and being able to write client-side and server-side code in the same language is a plus - though to be honest, you tend to use quite different styles in node.js; client side is based heavily upon your framework (jquery, backbone, knockout, etc) more than 'va

  • by kc67 (2789711) on Monday December 10, 2012 @04:45PM (#42245687)
    Poorly written and organized. Somehow recommended for newbies dispite the scathing review.
  • by Anonymous Coward on Monday December 10, 2012 @04:50PM (#42245725)

    Yet ANOTHER JavaScript fad that we have to learn in 21 days or be outsourced to Timbuktu. My mother warned me to become a dentist.

  • by The Asmodeus (18881) on Monday December 10, 2012 @05:02PM (#42245853)

    Ever heard of Netscape Livewire? (Google it kids)

    And yes it sucked.

  • by Anonymous Coward on Monday December 10, 2012 @05:08PM (#42245905)

    I have this book for my iDevices and it gives a solid base to build on. Node modules tend to move pretty quickly so some of the syntax or conventions may be outdated quickly. One thing I wish they'd talk a little more about is actually deploying node apps. I'd still recommend the book.

  • by Horshu (2754893) on Monday December 10, 2012 @05:17PM (#42246009)
    Just what the world needs - tinkering-level programmers utilizing their weakly-typed language skills in enterprise code.
  • by peter303 (12292) on Monday December 10, 2012 @05:23PM (#42246085)
    I learned dozens over the decades. I can start coding in hours after looking at manual.
    To do it well is another issue.
  • Dear God, why? (Score:3, Informative)

    by JDG1980 (2438906) on Monday December 10, 2012 @05:36PM (#42246191)

    JavaScript is a horrid language. Nonetheless, it's the only widely supported language for client-side browser code, so we're stuck with it there.

    But why on Earth would anyone even consider running this abomination on a server, when there are many other, better languages designed specifically for server-side code?

    • Re:Dear God, why? (Score:5, Informative)

      by caknuckle (2521404) on Monday December 10, 2012 @05:50PM (#42246317)
      Some decent explanations here [stackoverflow.com].
    • by mat690 (2568981) on Monday December 10, 2012 @08:32PM (#42247641)

      JavaScript is a horrid language. Nonetheless, it's the only widely supported language for client-side browser code, so we're stuck with it there.

      But why on Earth would anyone even consider running this abomination on a server, when there are many other, better languages designed specifically for server-side code?

      Completely agree with everything you said, Efforts should be made to replace it with something better on the client side rather than helping it spread like some horrific cancer to the server side as well.

    • by magi (91730) on Tuesday December 11, 2012 @06:25PM (#42254783) Homepage Journal

      Exactly so.

      There's a much better alternative - Vaadin [vaadin.com]. It allows pure server-side Java development of Ajax web applications much the same way as you would develop desktop applications with Swing, etc. Vaadin renders the server-side UI in the browser with widgets and a JavaScript rendering engine. However, you can also develop client-code in Java. The Java code is compiled to JavaScript with the GWT Compiler, which is also included in Vaadin. In Vaadin 7, the Java objects are serialized transparently between the server-side and client-side, so you can essentially work with the same objects on both sides.

      So, there is no real reason for node.js, unless you're really good at JavaScript and want to work with it instead of Java, or you have some JS code that you need to run on both sides. If you have already made a client-side JS library, you can integrate it with Vaadin quite easily.

  • by Anonymous Coward on Monday December 10, 2012 @05:54PM (#42246375)

    Node.js is bad ass hipster rockstar tech
    www.youtube.com/watch?v=bzkRVzciAZg

  • by Anonymous Coward on Monday December 10, 2012 @06:24PM (#42246655)

    I say that as a professional web application developer.

    I'd rather go the other way, and have Haskell running on the client too.

    But I guess JS is always good as a toy for the kids. Just like HTML5. (As opposed to XML and basic EBML.)

  • 464 pages (Score:4, Insightful)

    by JustinKSU (517405) on Monday December 10, 2012 @06:52PM (#42246921)
    The title must be a joke. I can't even read 464 pages in 24 hours let alone be able to run the exercises necessary to actually learn it.
    • by Bongoots (795869) on Tuesday December 11, 2012 @10:30AM (#42250220)

      You retard, it's meant to be read in 24 *hours*, not "24 hours". So really they probably meant within a month, if you read a chapter per day.

      It's similar for Sams' "10 minutes" or "21 days" books - each chapter taking 10 minutes/1 hour/1 day. The 21 days books are more in-depth from what I know. The logical steps would be to start with a 10 minutes book to get the nuggets of information you need (like the TY SQL in 10 Minutes book, which is really good as a quick reference), then take it up to 24 hours if you need more, and progress onto 21 days if you're still wanting yet more.

      The official website for this book can be found at http://nodejsbook.io/ [nodejsbook.io] and further info on the series can be found at https://www.informit.com/imprint/series_detail.aspx?st=61327 [informit.com]

    • by void*p (899835) on Tuesday December 11, 2012 @04:54PM (#42253989)

      "Your asynch program is like something from a 19th century gothic horror story. Drunk with your own sense of power, you reassemble pieces of code that were once coherent, stitching them together with event loops and callback functions, until your monster, grotesque and menancing, is ready to be brought to life in a Javascript VM. You throw the switch and the hideous creature awakes, rises, and lurches forward. you're simultaneously elated and terrified that something so unnatural could work at all. When you realize what you've unleashed, the pure immorality of it, your creation reaches out with its bloody, mangled arms, and strangles you."

  • by Frankie70 (803801) on Tuesday December 11, 2012 @11:46AM (#42250887)

    This is the funniest comment I have read about a SAMS Book

    http://groups.google.com/group/comp.lang.c++/msg/c314cb9da94e527f [google.com]

    SAMS Teach Yourself C++ in 10 Minutes advises the following

    Do not use inline functions. The compiler is better at optimizing your code than you think. Avoid using inline functions; let the compiler make your code run as fast as you can.

    This is obviously not good advice.

    One of the responses.

    The advice is reasonable for the level at which the book is
    written. I think there's a consensus in the C++ community that
    one should not use inline functions until one has at least 14
    minutes experience with the language.

    Oh - the good old days of Usenet.

Arithmetic is being able to count up to twenty without taking off your shoes. -- Mickey Mouse

Working...