Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

samzenpus posted about 2 years ago | from the read-all-about-it dept.

Books 112

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.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.

cancel ×

112 comments

Sorry! There are no comments related to the filter you selected.

Yup (3, Funny)

gazbo (517111) | about 2 years ago | (#42245541)

Before node.js it was literally impossible to use JS on a server. Thanks Node!!!1

Re:Yup (5, Funny)

Samantha Wright (1324923) | about 2 years ago | (#42246091)

Pfft. So archaic. You should see the new JS frameworks [html9respo...trapjs.com] . They're a blast.

Nope (1)

Anonymous Coward | about 2 years ago | (#42246131)

Classic ASP ran JScript on server in the late 1990s. A nice feature was you could declare methods like:

function MyClass.prototype.myMethod(myArg)
{
}

For those who are going to squawk JScript!==JavaScript, JScript==JavaScript && that was good enough.

Re:Nope (1)

poizan42 (1689384) | about 2 years ago | (#42246837)

Whoosh

Re:Yup (2)

TwezerFace (2788771) | about 2 years ago | (#42246247)

literally impossible...how is that different from plain ole impossible?

Re:Yup (1)

gazbo (517111) | about 2 years ago | (#42246297)

It's more sarcastic. Please try to keep up.

Re:Yup (1)

Samantha Wright (1324923) | about 2 years ago | (#42246303)

Perhaps it was possible in some non-literal sense? An anonymous poster pointed out that classic ASP could run JScript on the server-side. You could call that figuratively running JavaScript on a server due to the language differences. Or you could run a web browser on your server, but I guess that would actually be a very literal sense too, in which case the GP is wrong.

You guys are spoilt (1)

Frankie70 (803801) | about 2 years ago | (#42250917)

Back in the old days we had to walk 24 hours (12 hours each way uphill) to just a buy a book.

Does book include configuring host os? (1)

Anonymous Coward | about 2 years ago | (#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.

Re:Does book include configuring host os? (2)

Synerg1y (2169962) | about 2 years ago | (#42245885)

so basically... unfit for production environments is what you're getting at...

Haven't done a whole lot of work with python, but I'd expect it to be fairly bug free at this point given how long it's been around and what it's used for typically.

Re:Does book include configuring host os? (1)

dintech (998802) | about 2 years ago | (#42246913)

I don't know, usually the most shitty and unreliable stuff in the whole stack is MY code.

Re:Does book include configuring host os? (1)

etash (1907284) | about 2 years ago | (#42247033)

the problem with node is that it's trying to be both a chef and a waiter: both a server side language AND a server. wrong in my opinion. it's like having PHP also assume the role of apache. Yeah i know, "use nginx or apache as proxy in front of it" blah blah blah. Node would be a better choice of you had some proven, tested, real web server with configuration and just used node as your language of choice.

Re:Does book include configuring host os? (2)

corychristison (951993) | about 2 years ago | (#42247401)

Just a quick note, as someone who has been fiddling with Node.js, they specifically say not to use Nginx or Apache as a front end proxy.

Varnish seems to be the "just works" go to for Node.js proxies.

Re:Does book include configuring host os? (1)

rioki (1328185) | about 2 years ago | (#42249984)

If you want to write a vanilla web application you are right, node.js is kind of funky, because you need to think about all the scalability issues that are implemented in apache or nginx. But then again you also need to solve these issues along multiple web servers once you outscale one machine, so with node.js that is solved at that point. But the power of node comes from somewhere else, it is a general purpose programming environment with an ingenious asynchronous execution model.
I have built a bunch of useful applications and utilities in node with incredible speed. Node is now part of my programmer / admin toolbelt and has replaced perl and python. (I am a C++ programmer by trait.) It is sad that node is often reduced to web applications; it is a great programming environment that happens to do web.

Re:Does book include configuring host os? (1)

etash (1907284) | about 2 years ago | (#42250471)

you are right. the async model is good, and yes node is useful elsewhere ( not web ) for fast prototyping i.e.. However for heavy number crunching the async model has some deficiencies as the async model is good for high I/O without much cpu processing.

Re:Does book include configuring host os? (1)

putaro (235078) | about 2 years ago | (#42248685)

The problem is that we have novice programmers trying to "whip up" something that scales. It used to be we made novice programmers do maintenance programming until they actually learned something.

or.. (2, Funny)

tracius01 (2541214) | about 2 years ago | (#42245565)

how not to learn node.js in 24 hours

Re:or.. (2)

multicoregeneral (2618207) | about 2 years ago | (#42245801)

Or how about, how to make your http requests stand in line for a half hour while they're parsed individually?

Re:or.. (0)

Anonymous Coward | about 2 years ago | (#42246169)

Isn't the very point of node.js supposed to be that it's non-blocking?

That said, I have no idea why a person would want to use javascript as a server side language.

Re:or.. (1)

AaronLS (1804210) | about 2 years ago | (#42248211)

I wasn't going to be the one to say it, so I just scrolled knowing I'd be satisfied with seeing someone else say it.

Re:or.. (1)

rioki (1328185) | about 2 years ago | (#42250012)

Right, or python? Who would want to use ruby? The only certified web languages are perl and php, because they are such efficient languages.

Re:or.. (1)

TwezerFace (2788771) | about 2 years ago | (#42246251)

what do you mean?

First Post (0)

Anonymous Coward | about 2 years ago | (#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.

frist^ stop (-1)

Anonymous Coward | about 2 years ago | (#42245605)

to work I'm doin6, with the laundry from within. LLok at your soft,

Benefits (1)

schneidafunk (795759) | about 2 years ago | (#42245663)

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

Re:Benefits (4, Funny)

Spy Handler (822350) | about 2 years ago | (#42245719)

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

Re:Benefits (1)

dintech (998802) | about 2 years ago | (#42246931)

Sorry boss, can't do work today. Adblock.

Re:Benefits (0)

Anonymous Coward | about 2 years ago | (#42245721)

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

Wrong question to ask (2)

betterunixthanunix (980855) | about 2 years ago | (#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?"

Re:Wrong question to ask (3, Insightful)

Anonymous Coward | about 2 years ago | (#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.

Re:Wrong question to ask (4, Insightful)

Unnngh! (731758) | about 2 years ago | (#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.

Re:Wrong question to ask (1)

VoidEngineer (633446) | about 2 years ago | (#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..

Re:Wrong question to ask (1)

AaronLS (1804210) | about 2 years ago | (#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.

Re:Wrong question to ask (1)

rioki (1328185) | about 2 years ago | (#42250070)

"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".

Re:Wrong question to ask (0)

Anonymous Coward | about 2 years ago | (#42246341)

That sounds like PHP or Python, except for the part about using the same language the UI guy is copy/pasting in.

Re:Wrong question to ask (1)

MightyYar (622222) | about 2 years ago | (#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! :)

Re:Wrong question to ask (1)

K. S. Kyosuke (729550) | about 2 years ago | (#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.

Re:Wrong question to ask (1, Interesting)

epine (68316) | about 2 years ago | (#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.

Re:Wrong question to ask (1)

Xest (935314) | about 2 years ago | (#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.

Re:Benefits (1)

shdowhawk (940841) | about 2 years ago | (#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.

Re:Benefits (2)

multicoregeneral (2618207) | about 2 years ago | (#42245827)

Yeah, but you're suicidal if you put it on anything with traffic.

Re:Benefits (0)

Anonymous Coward | about 2 years ago | (#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

Re:Benefits (1)

rioki (1328185) | about 2 years ago | (#42250186)

Case in point, github's SSL proxying of external resources to prevent mixed mode warnings is implemented in node.js. If that is not "traffic" I don't know what is.

Re:Benefits (1)

VoidEngineer (633446) | about 2 years ago | (#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.

Re:Benefits (3, Insightful)

i kan reed (749298) | about 2 years ago | (#42245781)

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

Re:Benefits (2)

multicoregeneral (2618207) | about 2 years ago | (#42245843)

Dude, if Javascript is your only skill, you're in serious trouble.

Re:Benefits (2)

Kergan (780543) | about 2 years ago | (#42246343)

Dude, if Javascript is your only skill, you're in serious trouble.

The trouble is, this actually describes many a web developer's skill set happens to be. And it's a self-taught skill set at that.

Re:Benefits (0)

Anonymous Coward | about 2 years ago | (#42250699)

I have programmed in a number of programming languages, but I am now completely javascript. Actually coffeescript.

I run my own consulting business, and javascript is a dead serious language. It actually helps me personally that so many people still fail to see how valuable it is.

Re:Benefits (0)

Anonymous Coward | about 2 years ago | (#42246453)

I don't think you quite understood what the parent was saying.

Re:Benefits (1)

I Mean, What (2778851) | about 2 years ago | (#42248171)

Thanks for being so mature about this.
http://www.youtube.com/watch?v=PqQ62B8xdJc

Re:Benefits (0)

Anonymous Coward | about 2 years ago | (#42245783)

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

Re:Benefits (1)

Synerg1y (2169962) | about 2 years ago | (#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.

Re:Benefits (0)

Anonymous Coward | about 2 years ago | (#42246171)

Maybe to let UI only devs write for the server side?

Ticking time bomb here we come!

Re:Benefits (1)

steveb3210 (962811) | about 2 years ago | (#42248727)

I write code for both sides, there's no reason people need to live in their ivory towers...

Re:Benefits (1)

Trepidity (597) | about 2 years ago | (#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 (4, Interesting)

VoidEngineer (633446) | about 2 years ago | (#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.

Re:Benefits (1)

Fallingcow (213461) | about 2 years ago | (#42246025)

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.

Re:Benefits (0)

Anonymous Coward | about 2 years ago | (#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.

Re:Benefits (1)

akeeneye (1788292) | about 2 years ago | (#42246363)

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.

Re:Benefits (1)

rioki (1328185) | about 2 years ago | (#42250361)

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... ^_^

Re:Benefits (2)

jellomizer (103300) | about 2 years ago | (#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.

Re:Benefits (0)

Anonymous Coward | about 2 years ago | (#42246153)

Casuals think it's cool

Re:Benefits (4, Interesting)

Kergan (780543) | about 2 years ago | (#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.

Re:Benefits (2)

arkhan_jg (618674) | about 2 years ago | (#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.

Re:Benefits (1)

amaupin (721551) | about 2 years ago | (#42246311)

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 (3, Funny)

arkhan_jg (618674) | about 2 years ago | (#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 'vanilla' javascript - and node.js javascript is all about using the event model and your own callbacks to handle files, database queries and interacting with other modules, so the end-result code looks quite different, even when you're the same guy coding front and back (as I am for my own apps for my team). Under that ugly looking syntax is something really quite elegant and powerful.

And if the syntax is getting in your way, then coffeescript compiles to vanilla javascript and is much more ruby like and clean looking, and is quite popular.
I'm growing to like coffeescript purely due to it's implementation of a class+constructor syntax on top of javascript's prototype system, which is a bit odd looking to my C++ educated eyes.

But in the end of the day, it works in quite a different way to java, ruby or python. With socket.io especially, it adds a pretty powerful tool to your box, even if you don't write your entire app in it.

And frankly, no matter javascript's flaws, it could hardly be worse than PHP...

TL;DR (1)

kc67 (2789711) | about 2 years ago | (#42245687)

Poorly written and organized. Somehow recommended for newbies dispite the scathing review.

Re:TL;DR (1)

Desler (1608317) | about 2 years ago | (#42245735)

So pretty much the typical review from MichaelJRoss. He'll point out lots lf flaws and still give it a 7-9 score.

Re:TL;DR (1)

CannonballHead (842625) | about 2 years ago | (#42245875)

Lots *of* flaws. Modded insightful. ;)

Re:TL;DR (2)

Fallingcow (213461) | about 2 years ago | (#42245947)

Are you talking about the book, or NodeJS itself?

Time for the Fad Dance, kiddies! (2, Insightful)

Anonymous Coward | about 2 years ago | (#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.

Re:Time for the Fad Dance, kiddies! (0)

Anonymous Coward | about 2 years ago | (#42245789)

Yes, but techies have cooler community sites. Can you even imagine dentists talking to each other the way we do?

Re:Time for the Fad Dance, kiddies! (4, Funny)

SJHillman (1966756) | about 2 years ago | (#42245879)

News For Molars, Floss That Matters

Re:Time for the Fad Dance, kiddies! (1)

milage (881680) | about 2 years ago | (#42245987)

News For Molars, Floss That Matters

Why would dentists care about Free/Libre/Open Source Software?

Re:Time for the Fad Dance, kiddies! (0)

Anonymous Coward | about 2 years ago | (#42246179)

I hope you die a painful death.

Re:Time for the Fad Dance, kiddies! (0)

Anonymous Coward | about 2 years ago | (#42247073)

I prefer News For Roys, Moss That Matters.

Livewire (1)

The Asmodeus (18881) | about 2 years ago | (#42245853)

Ever heard of Netscape Livewire? (Google it kids)

And yes it sucked.

Solid Read (0)

Anonymous Coward | about 2 years ago | (#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.

Re:Solid Read (0)

Anonymous Coward | about 2 years ago | (#42246027)

Thanks mom.

Great (2)

Horshu (2754893) | about 2 years ago | (#42246009)

Just what the world needs - tinkering-level programmers utilizing their weakly-typed language skills in enterprise code.

Re:Great (0)

Anonymous Coward | about 2 years ago | (#42246201)

I was arguing with one of those people about compile time type safety, and he said, "That's what testers are for!"

Face palm.

I havent taken that long to learn a new language (3, Insightful)

peter303 (12292) | about 2 years ago | (#42246085)

I learned dozens over the decades. I can start coding in hours after looking at manual.
To do it well is another issue.

Re:I havent taken that long to learn a new languag (0)

Anonymous Coward | about 2 years ago | (#42246243)

Good for you. Congratulations.

Re:I havent taken that long to learn a new languag (1)

flimflammer (956759) | about 2 years ago | (#42247517)

We all get to that state after we've learned a few languages. Once you understand the basic flow, you can follow code you don't fully understand pretty easily, and replicate it easily enough.

Re:I havent taken that long to learn a new languag (2)

LordLucless (582312) | about 2 years ago | (#42248703)

Good for you. Sadly, node.js isn't a language - it's a framework. And most languages have been through a *lot* more testing before they're shoved in front of a developer than the average framework.

Frameworks aren't really like languages. All computer languages tend to be really, really similar - even outliers like Lisp have more in common with say, C, than most frameworks have with each other. If the framework you know and the framework you're learning both use a comprehensible, intelligent pattern (say, Django or CodeIgniter) you can get over the hump pretty easily. If, on the other hand, you're dealing with a steaming turd shovelled up by a decade of inbred development (say, Zend) you're not likely to be able to start coding in an hour after looking at a manual (presuming such a beast exists).

Dear God, why? (2, Informative)

JDG1980 (2438906) | about 2 years ago | (#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? (5, Informative)

caknuckle (2521404) | about 2 years ago | (#42246317)

Some decent explanations here [stackoverflow.com] .

Re:Dear God, why? (0)

Anonymous Coward | about 2 years ago | (#42246801)

1) Because you can easily write non-blocking asynchronous code that is hard to write in thread based server languages (e.g. java): e.g. you can get data from 5 backend databases concurrently and combine the results into a single response.

2) Because you can execute multiple services withing the same memory space (e.g. two IRC servers and HTTP server) and hook them up very nicely so they can share data.

Re:Dear God, why? (0)

Anonymous Coward | about 2 years ago | (#42247881)

Writing asynchronous web services is not that difficult in Java and it's trivial in both Scala and Clojure.

Re:Dear God, why? (1)

mat690 (2568981) | about 2 years ago | (#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.

Node.js is bad ass hipster rockstar tech (0)

Anonymous Coward | about 2 years ago | (#42246375)

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

More like NOPE.js (0)

Anonymous Coward | about 2 years ago | (#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 (3, Insightful)

JustinKSU (517405) | about 2 years ago | (#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.

Re:464 pages (1)

Bongoots (795869) | about 2 years ago | (#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]

Re:464 pages (0)

Anonymous Coward | about 2 years ago | (#42250817)

that's only ~19 pages an hour or 1 page every three minutes which is approx. 266 WPM assuming a worst case 800 words per page (roughly equivalent to the number of words that fit on letter sized paper, single spaced, 1 inch margins with 12 point font). And that's falsely assuming that all 464 pages have actual content.

Average adult reading speed is 300wpm. -> you read slowly.

probably not (0)

Anonymous Coward | about 2 years ago | (#42247349)

probably can write a script in 24hrs
probably cannot read a book in 24hrs.
this book is probably a fail.

It's easy to hate on Javascript but (0)

Anonymous Coward | about 2 years ago | (#42247441)

Node JS solves some problems really well. For scalable server-side apps, it works.

You will soon be irrelevant (0)

Anonymous Coward | about 2 years ago | (#42247615)

Most of the comments here remind me of the old programmer that knows it all, but for some reason or another never learned anything new and thus got pigeon holed into working on the same or similar project for the next 10-20 yrs. sure, you're a know it all, but your projects are boring and suck and you are no longer relevant. This is how the future happens. The same people flaming JavaScript have probably been flaming it over the last decade as it continues to gain in popularity. Like it or not, node will only become more popular as the real time stack evolves. Evolve or be that bitter programmer no one wants to talk to.

Funny comment about a SAMS book (1)

Frankie70 (803801) | about 2 years ago | (#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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>