

Why I'm Learning Node - b14ck
http://rdegges.com/why-im-learning-node

======
wickedchicken
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...](http://www.rose-
hulman.edu/Users/faculty/rickert/OldFiles/Class/csse/csse403/201010/Papers/UngarSmith87.pdf)

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

~~~
noelwelsh
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>

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

~~~
karterk
_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._

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.

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

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

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

------
karterk
_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...](http://kishorelive.com/2012/02/23/my-javascript-reading-list/)

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

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

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

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

~~~
4as198sGxV
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.

------
doc4t
_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...](http://www.amazon.com/JavaScript-Definitive-Guide-Activate-
Guides/dp/0596805527/ref=sr_1_1?ie=UTF8&qid=1333877087&sr=8-1)

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

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

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

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

~~~
iso8859-1
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.

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

~~~
jdc
Have you tried Pyjamas?

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

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

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

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

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

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

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

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

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

------
smallegan
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!

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

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

~~~
Aaronontheweb
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!

