Why I'm Learning Node

Not many people know this, but Javascript: The Good Parts is available online as a PDF, for free! <a href="http://www.rose-hulman.edu/Users/faculty/rickert/OldFiles/Class/csse/csse403/201010/Papers/UngarSmith87.pdf" rel="nofollow">http://www.rose-hulman.edu/Users/faculty/rickert/OldFiles/Cl...</a>

The problem with node is it decreases your productivity tremendously.<p>The most important thing about the choice of programming tools is productivity. Node.JS does <i>not</i> 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.<p>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 <i>do</i> increase your productivity, but, <i>only on the client side</i>.<p>If you're looking for performance and non-blocking IO, use Go, it's much better at that.

<i>After reading so many negative things about nodejs, I'm completely surprised to report that it is actually pretty damn cool.</i><p>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.<p>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: <a href="http://kishorelive.com/2012/02/23/my-javascript-reading-list/" rel="nofollow">http://kishorelive.com/2012/02/23/my-javascript-reading-list...</a>

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.

<i>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.</i><p>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.<p>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.<p><a href="http://www.amazon.com/JavaScript-Definitive-Guide-Activate-Guides/dp/0596805527/ref=sr_1_1?ie=UTF8&#38;qid=1333877087&#38;sr=8-1" rel="nofollow">http://www.amazon.com/JavaScript-Definitive-Guide-Activate-G...</a>

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.<p><a href="http://www.gabordemooij.com/articles/jsoop.html" rel="nofollow">http://www.gabordemooij.com/articles/jsoop.html</a><p>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.)<p>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.<p>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.<p>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 <i>then</i> start adding CSS and JS. Learn why &#60;b&#62; is wrong and &#60;strong&#62; isn't. Make sure you're HTML validates.<p>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.<p>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.<p>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.<p>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.

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

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.

The author refers to this seething criticism of node (<a href="http://teddziuba.com/2011/10/node-js-is-cancer" rel="nofollow">http://teddziuba.com/2011/10/node-js-is-cancer</a>. 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.<p>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 (<a href="https://github.com/substack/node-browserify" rel="nofollow">https://github.com/substack/node-browserify</a>) is great for providing require() and bundling necessary dependencies for the browser.