Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?

Book Review: Sams Teach Yourself Node.js In 24 Hours 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.
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

    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 b

    • 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.
      • by dintech ( 998802 )
        I don't know, usually the most shitty and unreliable stuff in the whole stack is MY code.
    • by etash ( 1907284 )
      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.
      • 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.

      • by rioki ( 1328185 )
        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 u
        • by etash ( 1907284 )
          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.
          • by rioki ( 1328185 )
            I never got this: "node.js is not good for heavy number crunching" Why do people repeat this?! It is like saying a "Porche 911 is bad at trucking large loads"... Node.js uses Java Script and that is an interpreted language. Yes, V8 is a great piece of technology, but it remains the fact that there is still a layer of abstraction required to actually make Java Script run on the CPU. What are people expecting? If you look at ALL common web technologies, PHP, Pyhton, Ruby or perl, each and every one is interpr
    • by putaro ( 235078 )

      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.. (Score:1, Funny)

    by tracius01 ( 2541214 )
    how not to learn node.js in 24 hours
  • 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.

    • 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: (Score:3, Insightful)

        by Anonymous Coward

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


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

              • by rioki ( 1328185 )
                "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 lo
            • 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.

          • Re: (Score:2, Interesting)

            by epine ( 68316 )

            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

          • by Xest ( 935314 )

            "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

            • by nzhavok ( 254960 )
              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 its
    • 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.
      • Yeah, but you're suicidal if you put it on anything with traffic.
        • 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.
          • 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 )

              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.

            • 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 l
    • 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!"

      • Dude, if Javascript is your only skill, you're in serious trouble.
        • by Kergan ( 780543 )

          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.

      • Thanks for being so mature about this.
    • 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. v
    • by Trepidity ( 597 )

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

    • 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 t

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


      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.

      • 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 synchronou

    • by amaupin ( 721551 )
      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 )
    Poorly written and organized. Somehow recommended for newbies dispite the scathing review.
  • by Anonymous Coward

    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.

  • Ever heard of Netscape Livewire? (Google it kids)

    And yes it sucked.

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

    • 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, Dj

  • 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 )

      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 )

      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

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

    • by void*p ( 899835 )

      "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

  • 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

Today is a good day for information-gathering. Read someone else's mail file.