Why I'm Learning Node | Hacker News Reader

Why I'm Learning Node

rdegges.com

79 pointsb14ck60 comments

Not many people know this, but Javascript: The Good Parts is available online as a PDF, for free! http://www.rose-hulman.edu/Users/faculty/rickert/OldFiles/Cl...

I think you have the wrong link there. It goes to a paper about Self.

Maybe he meant this? http://eleventyone.done.hu/OReilly.JavaScript.The.Good.Parts...

It's a joke, except it points to the wrong link. It should be have been to http://people.csail.mit.edu/jaffer/r4rs_toc.html

http://eleventyone.done.hu/OReilly.JavaScript.The.Good.Parts...

How do I nominate this comment for "Best of HN"?

I read through most of J:TGP, but the problem is that it doesn't really focus on the DOM at all (which I knew when I picked it up). Unfortunately, the DOM is the entire reason I'd realistically want to use Javascript anyway.

Most 'popular' languages these days are descendants of C in some form, which means that the differences between any two are very small, in the grand scheme of things. (I'm talking about programming paradigms here - I understand that things like running time and library support are real factors, but to me those define the implementation of a language, not the language itself).

Javascript may be different from most C-derived languages in that it promotes certain paradigms that others don't, but to me, it doesn't offer anything as a language that other languages that I like (and use) don't. Prototypal inheritance is familiar to me from Python (yes, you read that right), and functional paradigms (including first-class/higher-order functions and closures) are familiar to me from Scala and Lisp.

If we want to talk about actual implementation and the runtime environment, I'm still not convinced that Javascript has any real inherent advantages over other languages for most of the non-DOM tasks that people try and use it for. Maybe it promotes familiarity with a single language, but I see that as a detractor, not an asset.

So in the end, while Javascript may be 'more than just the DOM' these days, for me, that's still where its use case lies. Just because I can use it for other things doesn't mean I want to; for anything that I want to do other than manipulating the DOM, I can find an environment that suits me much better.

The problem with node is it decreases your productivity tremendously.

The most important thing about the choice of programming tools is productivity. Node.JS does not promise you any productivity gains. Node sells itself as a solution to "slowness" caused by "blocking IO". What's the solution? All I/O is evented! This means you have to write everything with callbacks.

You may see some very nice libraries/tools coming out around node.js, like jade, coffeescript, and stylus. These are all nice and good, and they do increase your productivity, but, only on the client side.

If you're looking for performance and non-blocking IO, use Go, it's much better at that.

I disagree. Firstly, CoffeScript is not confined to the client-side. Besides, there are some modules like socket.io for which you will hardly find any substitues in other eco-systems.

You're also discounting the effects of context shifts between two separate languages - one on the client side, and the other on the server side.

Lastly, I would like to know what you find productive about Go, that's not the case with either CS/JS on Node.

The decrease in productivity with node comes from having to write everything with callbacks. Programming asynchronously is crazy, it makes very simple algorithms very annoying to write.

I'd say it's almost like writing in assembly. You have to write your code in some pseudo code first, synchronously, then translate that into the asynchronous callback spaghetti than node requires.

> Lastly, I would like to know what you find productive about Go, that's not the case with either CS/JS on Node.

Not having to write everything asynchronously?

I haven't actually used go, but the way goroutines communicate (and synchronize) with channels suggests to me (from what I've read/seen) that this callback spaghetti problem is non-existent in Go.

It cracks me up that you haven't tried Go but you're still recommending it, is there a web framework?

Edit: Found web.go. Screw it it's a long weekend, I'll give learning Go a go.

I haven't had a pressing need for using it, and I'm considering it as something I want to learn on the side for now.

As for frameworks, it seems the http package comes builtin with a server and a url router. Also, Google's AppEngine supports Go.

You don't really need a web framework with go. net/http is just fine for most use cases.

web.go is still not compliant with the recently released Go1. I'd recommend anyone interested in Go but not in a hurry to wait a month or two until the Go1 dust settles.

> I'd say it's almost like writing in assembly. You have to write your code in some pseudo code first, synchronously, then translate that into the asynchronous callback spaghetti than node requires.

This is a sign of a not-fully-adopted paradigm shift. Like, when someone first learns a new (spoken) language, they translate it to their native language in their head.

Fluent speakers don't translate, they simply understand. Similarly, when you fully grok functional programming, coding with callbacks will cease to feel unnatural.

That said, it does take some getting used to, which is a real cost that needs to be considered when choosing Node.

> Similarly, when you fully grok functional programming, coding with callbacks will cease to feel unnatural.

A minor remark from my experience with functional programming, continuation-passing style is actually something I prefer to avoid.

> Similarly, when you fully grok functional programming, coding with callbacks will cease to feel unnatural.

I don't understand this comment. Javascript, while having first-class functions, does not have call/cc. This is the source of complaints that Javascript encourages callback-spaghetti. As people have mentioned elsewhere, continuation-passing style is meant for compilers, not humans.

Thanks! I couldn't have phrased it any better.

This is why I said it's like writing assembly.

> The decrease in productivity with node comes from having to write everything with callbacks. Programming asynchronously is crazy, it makes very simple algorithms very annoying to write.

I know exactly what you mean, because that's what I thought a year ago. I was going on and on about this to everyone. Mea culpa.

Then I actually tried node and learned the functional side of JavaScript (I don't mean the semantics, which are very simple; I mean powerful LISPish design patterns). Now I don't think about callbacks anymore, because I have a functional toolkit that mostly hides them.

You say asynchronous coding makes simple algorithms annoying to write. So let's have an example. Read two files -- in parallel -- trap I/O errors and warn about them, otherwise merge and sort the files by line, write the result to a third file, and warn about I/O errors there as well. Simple enough?

My solution is 8 lines, formatted. It was very pleasant to write.

  fork(
    ['lines.txt', 'lines2.txt'].map(function(name) {
      return fs.readFile.bind(fs, name);
    }),
    check(console.warn.bind(console), function(a) {
      fs.writeFile('linesOut.txt', a.sum().split('\n').sort().join('\n'), check(console.warn.bind(console)));
    })
  )

If you've seen enough JS to deduce what the lib definitions for fork() and check() might be, then this code will seem obvious -- almost trivial. Otherwise, you will probably claim shenanigans or 'spaghetti' because it doesn't look like insert favorite programming language/framework here.

So it saddens me to hear people whining about this aspect of node -- partly because it recalls my own naivety, and partly because I know from experience that they're missing out on something great.

So your point is that it's hard until you spend a year working with callback-based JavaScript, and then it becomes easy and intuitive? A year of investment may as well be an eternity for most.

That's good to know though. As it's pretty easy to waste a year learning framework X.

To be fair, the OP did not exactly say that it took 1 year to learn it. I personally took less than a few days. Every framework has a learning curve.

Red herring. Node can increase productivity as well. It's all about your requirements and workflow.

> The problem with node is it decreases your productivity tremendously.

People say this over and over, complaining about nested callbacks and what not. I can tell you from experience that it is not true. I've been working on a Node application for a few weeks now. It is our first server side Javascript endeavour as a company, I had only tinkered with it in my own time before this. And the experience is pretty good. Writing in a more functional style makes me more productive and makes quite some problems more straightforward to describe (implement).

Or Haskell, Erlang or various other languages that have better solutions for non-blocking I/O.

Or C, C++, Java, Python or Ruby.

Every language has solutions for non-blocking I/O, even the boring ones.

C doesn't have a good solution for non-blocking IO. Managing callbacks and their lexical scopes manually is quite painstaking.

User-level threads are non-standard, and ordinary threads are too heavy. All forms of threads lose much of C's benefit due to the relatively heavy stack allocation per thread.

I very much agree on the drop in productivity. I was just contracted to help with a Node project and just getting up to speed has been difficult. This is not all node's fault since the callbacks and such could have been handled differently.

The better examples will be in a few years when programmers have more experience with Node and the projects' code reflect that.

I won't be returning back to Node after the project though because it reminds me of earlier days writing XML with Spring.

If "This is a revolution" hadn't been patented by Apple years ago, I'd be using it right now. Hell, Node invented / brought us:

- The Reactor Pattern, a never-been-before paradigm.

- V8 and its mind-blowing speed.

- Evented I/O, a game changer.

- It also allows you to program all that with the best language known to man, Javascript, ON - THE - EFFIN - SERVER (zomg).

Hats off to the Node community though, they're getting good at emulating Rails' PR tactics of buzzwords, fluff and overblown hype.

After reading so many negative things about nodejs, I'm completely surprised to report that it is actually pretty damn cool.

Most of these negative things were (are being?) written by people who target Node's shortcomings without giving due concern to the areas it shines in.

Good Parts is definitely a good read. If anyone is looking for more reading materials on JavaScript, I had written a post about it recently: http://kishorelive.com/2012/02/23/my-javascript-reading-list...

Thanks, this looks like a really great list. I'm adding these to my reading queue :)

You should add Eloquent Javascript to the list really good JS books, if you haven't already read it: http://eloquentjavascript.net/

Thanks for the link! There is a lot of useful JavaScript knowledge over there that's begging to get on http://www.tiljs.com/

If the point is to learn front-end development, it seems like you're still sticking to your strengths instead of challenging yourself and delving into actual front-end DOM manipulation stuff.

You could say that, or you could say he's just trying to learn one thing at a time. JavaScript, then DOM.

Agree. It seems the OP is just moving from one language to another rather than from one domain (back-end) to another (front-end).

If you're learning JavaScript to get familiar with front-end and UI, Node.js is just a distraction. Instead, my advice is to learn raw HTML/CSS/JS without frameworks.

You know those cheesy web-based "OSes"/Desktops that no one really uses? Building one is actually quite helpful to developing JavaScript skills. Try building a Window manager in HTML/CSS/JS. You'll go through the entire gauntlet of what JavaScript has to offer (e.g. closures, prototypes) while dealing with a practical front-end problem (DOM manipulation, CSS styling) while learning a lot about why the modern js frameworks are so useful (e.g. jQuery for DOM, backbone.js for MVC). You'll also start getting exposure to some basic decisions that make up the foundations of a good UI sense. I consider this sort of exercise much more appropriate for polishing front-end skills.

Other possible exercises include re-implementing common jQuery UI components - drop-down menus, trees, tabs, etc. But do them without jQuery. It might sound like reinventing the wheel, but learning fundamentals sometimes requires retreading worn out paths.

Sure. Then he will want to kill himself when trying to use of all those inferior and mismatched technologies for any kind of complex application (achieving crossbrowser support will ensure many nights of fun!). He will then go back to coding server-side where at least you can use sane language and tools so you can be as productive as possible. However, he will be thinking about this glimpse of hell for the rest of his career.

If you're an experienced programmer looking to learn Javascript, you probably can't do any better than reading Javascript: The Good Parts. It's extremely short, concise, and enjoyable to read. Highly recommended.

Any experienced programmer should definitely start elsewhere so he can make up his own mind about Crockfords ideas about how programming should be. While the book is ok-ish almost half of the material is about Crockfords personal preferences for coding style and can be applied to any language.

JavaScript - The Definite Guide by David Flanagan is in my opinion the best book on the subject. No other JS book comes even close in clarity and thoroughness.

http://www.amazon.com/JavaScript-Definitive-Guide-Activate-G...

Agree. Moreover, the Good Parts is a bit dated since it's written in 2008 and things had changed noticeable with ECMAScript 5 in 2009. The last 6th edition of The Definitive Guide covers ES5 and has a chapter explaining Crockford's ideas.

Javascript can be quite daunting. I have seen many disasters with Javascript applications. This is why I now teach Javascript differently, I have written down a minimalist JS approach. This way of writing Javascript allows you to implement almost any OOP design yet it only uses 10% of the Javascript language thus shortening the learning curve. I wrote this initially for co-workers but because it's such a success I've decided to put it online.

http://www.gabordemooij.com/articles/jsoop.html

This approach also makes it possible to treat JS more like a traditional OOP language and it does not require external libraries, sugar code or new browser technology. It works in the most ancient browsers.

The author echoes many of the same reasons I really dived into Node - I'm a strong C# back-end developer but really hadn't had much experience designing web UI (HTML5/CSS/JS.)

I can say without a doubt that my experience with Node has translated to some upside in terms of my front-end JavaScript abilities - being able to really master the ins and outs of JavaScript language itself has made it much easier for me to work with even some pretty nasty front-end bits.

In addition, you pick up a lot of tools in Node that are translatable to client-side JS development. Many of the unit testing frameworks work just as well at testing client-side code as they do server-side.

Starting with Node is a very poor choice if you want to learn front-end. But you can't go wrong with The Good Parts and you at least now know what's all the fuss about Node. But now let's really start learning front-end.

Begin with semantic HTML. It's really the basis. The best front-enders I know first write all the HTML for a project, and only then start adding CSS and JS. Learn why <b> is wrong and <strong> isn't. Make sure you're HTML validates.

Now go to CSS. It's really easy to add some colours or fonts. You learn CSS as you go. But there is one hurdle here: the box model. Learn about float:left, position:absolute, display:block and how they entangle.

This will be harder than you think. You will need to learn some tools to debug this. Install Firebug and the Webdevelopers Toolbar in Firefox and see how you can fix your layout. Browsers aren't that scary.

We're only learning here, so skip IE for now. That one is actually kinda scary. Though if you really want to learn front-end, it's all about browser differences.

And then Javascript. Now it will be easy. Stick with jQuery and connect with your Node instance with socket.io. Learn Backbone if you want to make snappy web apps. There's a lot to learn in this 'grey field' between back-end and front-end. But at least you now know front-end.

> And then Javascript. Now it will be easy.

Famous last words.

Might as well make sure you're grammar validates too.

Anyway, I don't understand why the front-end is relevant at all. It's not the same problem, and the fact that most people do both doesn't mean that learning to do a good front-end will teach you to do a good back-end.

As a longtime Python guy, mostly back-end (but I knew JS pretty well) -- I did a quick demo site recently in node, and was surprised by how it felt. There was much less context-switching as I went back and forth between the client and server. That sounds obvious but it was kind of a shock.

I always wanted Python on the client (here's looking at you, Jython!) -- js on the server may be the closest thing I'm going to get.

Have you tried Pyjamas?

As noted somewhere else learning node is not learning front-end. Something that bothered me recently is that on the back-end we are used to big oop frameworks when in fact the stateless nature of http do not match oop so well. On the front end however we have a gui so oop is a good paradigm.

Huh? What does the statelessness of HTTP have to do with OOP, particularly on the server, but not the client?

I guess because you effectively have to re-initialise most things on a per-request basis or run into race-conditions etc.

Because most server side languages take a "throw away the world" approach to web programming; none of your objects persist in memory through requests, which means every time a request comes in you have to reload a part of the user's world from the db, service the request, and then destroy the world you've just created. For structural things like MVC, objects are great, but you really don't see much of the "object as vehicle for data encapsulation" that's drilled into every new programmer when they're first taught OOP.

The client, on the other hand, can persist data and objects through requests, and the only time it needs to be fully refreshed is on a full reload.

Ah. But that isn't an issue of language or object-orientation. There are server-side frameworks that don't throw away the world, and client-side frameworks that do. (Notice how your javascript state is thrown away everytime you load a new page in the browser). That's a design decision that's made possible by the statelessness of HTTP, but not required by it.

Certainly, but throwing away the world is natural on server side code and it means that your carefully crafted object don't live long and many of them don't need too be objects, they are micro namespaces for a set of methods. I never tried node.js for real but one good side off it could be that you are not pushed towards objects like you are with Python, Ruby, Java, etc.

The author refers to this seething criticism of node (http://teddziuba.com/2011/10/node-js-is-cancer. html), that I've seen before, and then just soldiers on without addressing it. I'm not well versed enough to know whether Dziuba's analysis is not the mark or not. What do the javascript/node experts here have to say about it? The criticism, after all, would seem to be so damning that it either needs to be refuted or to stand as a definitive reason to never seriously consider using node in a real project.

Just read around two thirds of 'The Node Beginner Book'. I've only briefly played with node.js before now and I still don't really have an immediate use for it personally. I could see myself using it to whip up rough scaffolding to support prototypes of personal projects written in other languages.

I did learn something from its event-driven callback system though. Made me realize I was approaching things the wrong way in a libevent-based daemon I'm developing in C.

Congrats,it really sucks having to rely on other people to complete your project.Also you might want to learn Coffeescript and jQuery.

No justification required for learning another language. I sometimes wonder how often the ends justify the means.

I like the though process but I think where you may fall short is the UI Design aspect. HTML/CSS/Javascript isn't all that hard, it is creating a good looking and highly usable user interface that is challenging. Good luck!

Formatting on this site is terrible for iPhone reading. It prevents zooming, thus forcing a very small font on the reader.

browserify (https://github.com/substack/node-browserify) is great for providing require() and bundling necessary dependencies for the browser.

Thank god for this - I've been doing a lot of work with some NPM packages that I want to use on the client but for the life of me couldn't figure out how to do it. This looks like it'll do just the trick. Thanks!

Reply on news.ycombinator.com