8 ms·

Why I'm Learning Node

79 points by b14ck 14y ago

pyrotechnick 14y ago
browserify (https://github.com/substack/node-browserify https://github.com/substack/node-browserify) is great for providing require() and bundling necessary dependencies for the browser.
- Aaronontheweb 14y ago
  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!
- justicefries 14y ago
  Also, requirejs (http://requirejs.org http://requirejs.org) is great. It's AMD (asynchronous module definitions) based, and it's worth knowing the differences between AMD and CommonJS (which is what Browserify is based off of).
Aaronontheweb 14y ago
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.
karterk 14y ago
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 14y ago
  Thanks, this looks like a really great list. I'm adding these to my reading queue :)
  - zecho 14y ago
    You should add Eloquent Javascript to the list really good JS books, if you haven't already read it: http://eloquentjavascript.net/ http://eloquentjavascript.net/
- 1p1e1 14y ago
  Thanks for the link! There is a lot of useful JavaScript knowledge over there that's begging to get on http://www.tiljs.com/ http://www.tiljs.com/
nnythm 14y ago
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.
- andrewflnr 14y ago
  You could say that, or you could say he's just trying to learn one thing at a time. JavaScript, then DOM.
- lunaru 14y ago
  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 14y ago
    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.
munyukim 14y ago
Congrats,it really sucks having to rely on other people to complete your project.Also you might want to learn Coffeescript and jQuery.
wickedchicken 14y ago
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/Class/csse/csse403/201010/Papers/UngarSmith87.pdf http://www.rose-hulman.edu/Users/faculty/rickert/OldFiles/Cl...
- andrewflnr 14y ago
  I think you have the wrong link there. It goes to a paper about Self.
  - pdk 14y ago
    Maybe he meant this? http://eleventyone.done.hu/OReilly.JavaScript.The.Good.Parts.May.2008.pdf http://eleventyone.done.hu/OReilly.JavaScript.The.Good.Parts...
  - noelwelsh 14y ago
    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://people.csail.mit.edu/jaffer/r4rs_toc.html
- spung 14y ago
  http://eleventyone.done.hu/OReilly.JavaScript.The.Good.Parts.May.2008.pdf http://eleventyone.done.hu/OReilly.JavaScript.The.Good.Parts...
- jdale27 14y ago
  How do I nominate this comment for "Best of HN"?
- chimeracoder 14y ago
  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.
danbmil99 14y ago
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 14y ago
  Have you tried Pyjamas?
gbog 14y ago
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 14y ago
  Huh? What does the statelessness of HTTP have to do with OOP, particularly on the server, but not the client?
  - antihero 14y ago
    I guess because you effectively have to re-initialise most things on a per-request basis or run into race-conditions etc.
  - HeyImAlex 14y ago
    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 14y ago
      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.
hasenj 14y ago
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 14y ago
  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 14y ago
    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 14y ago
deleted 14y ago
[deleted]
devin 14y ago
No justification required for learning another language. I sometimes wonder how often the ends justify the means.
Alexandervn 14y ago
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.
- pestaa 14y ago
  > And then Javascript. Now it will be easy. Famous last words.
- iso8859-1 14y ago
  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.
doc4t 14y ago
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-Guides/dp/0596805527/ref=sr_1_1?ie=UTF8&qid=1333877087&sr=8-1 http://www.amazon.com/JavaScript-Definitive-Guide-Activate-G...
- maga 14y ago
  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.
stcredzero 14y ago
Formatting on this site is terrible for iPhone reading. It prevents zooming, thus forcing a very small font on the reader.
gabordemooij 14y ago
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 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.
smallegan 14y ago
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!
octotoad 14y ago
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.
leephillips 14y ago
The author refers to this seething criticism of node (http://teddziuba.com/2011/10/node-js-is-cancer 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.

79 points by b14ck 14y ago

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

Aaronontheweb 14y ago
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!
justicefries 14y ago
Also, requirejs (http://requirejs.org http://requirejs.org) is great. It's AMD (asynchronous module definitions) based, and it's worth knowing the differences between AMD and CommonJS (which is what Browserify is based off of).

Aaronontheweb 14y ago

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.

karterk 14y ago

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 14y ago
Thanks, this looks like a really great list. I'm adding these to my reading queue :)
- zecho 14y ago
  You should add Eloquent Javascript to the list really good JS books, if you haven't already read it: http://eloquentjavascript.net/ http://eloquentjavascript.net/
1p1e1 14y ago
Thanks for the link! There is a lot of useful JavaScript knowledge over there that's begging to get on http://www.tiljs.com/ http://www.tiljs.com/

nnythm 14y ago

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.

andrewflnr 14y ago
You could say that, or you could say he's just trying to learn one thing at a time. JavaScript, then DOM.
lunaru 14y ago
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 14y ago
  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.

munyukim 14y ago

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

wickedchicken 14y ago

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

andrewflnr 14y ago
I think you have the wrong link there. It goes to a paper about Self.
- pdk 14y ago
  Maybe he meant this? http://eleventyone.done.hu/OReilly.JavaScript.The.Good.Parts.May.2008.pdf http://eleventyone.done.hu/OReilly.JavaScript.The.Good.Parts...
- noelwelsh 14y ago
  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://people.csail.mit.edu/jaffer/r4rs_toc.html
spung 14y ago
http://eleventyone.done.hu/OReilly.JavaScript.The.Good.Parts.May.2008.pdf http://eleventyone.done.hu/OReilly.JavaScript.The.Good.Parts...
jdale27 14y ago
How do I nominate this comment for "Best of HN"?
chimeracoder 14y ago
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.

danbmil99 14y ago

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 14y ago
Have you tried Pyjamas?

gbog 14y ago

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 14y ago
Huh? What does the statelessness of HTTP have to do with OOP, particularly on the server, but not the client?
- antihero 14y ago
  I guess because you effectively have to re-initialise most things on a per-request basis or run into race-conditions etc.
- HeyImAlex 14y ago
  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 14y ago
    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.

hasenj 14y ago

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 14y ago
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 14y ago
  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 14y ago

deleted 14y ago

[deleted]

devin 14y ago

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

Alexandervn 14y ago

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.

pestaa 14y ago
> And then Javascript. Now it will be easy. Famous last words.
iso8859-1 14y ago
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.

doc4t 14y ago

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

maga 14y ago
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.

stcredzero 14y ago

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

gabordemooij 14y ago

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

smallegan 14y ago

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!

octotoad 14y ago

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.

leephillips 14y ago

The author refers to this seething criticism of node (http://teddziuba.com/2011/10/node-js-is-cancer 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.