YUI Blog

As someone who has spent the last six months coding in Node.js, I completely disagree with this notion.

One of my favorite advantages of Node is in fact that it is based on javascript. When building my application I can share code between client/sever side (string formatting methods for example) and don't need to do any mental context switching when it comes to languages. I've developed in javascript for years and all that I have learned doesn't go out the window here, all I need to do is learn how to use a few libraries.

The "faults" of javascript are primarily inexperience with event looped architectures that use callbacks (people complaining about having to use callbacks and the spaghetti code messes they make), people remembering the past horrible browser implementations of it (where something would work/be fast in one browser and not another ... Internet Explorer I'm looking at you) and confusion over how prototypical languages work vs. standard OOP.

Callbacks aren't that bad and a few extra nesting levels shouldn't create chaos in your code. Since its based entirely off of one javascript implementation (V8) the cross browser stuff is gone. How it handles OOP is different, just watch these videos first and you'll be fine: http://www.yuiblog.com/blog/2007/01/24/video-crockford-tjpl/

As far as speed goes it gets huge benefits by being javascript. Every time the Google coding machine feels like making V8 a little faster, Node gets faster too.

Yes its different,…

Crockford has good recommendations on when to use `new`, or not, in his 2006 post on the topic[1]. I like most of what the author says re. classical OO in JS, but would stop short of not using `new` at all. Its a long-established standard and the open/close principle[2] is probably not enough of a concern in most applications to warrant using a different / slower / sometimes unsupported method. And there are functional programming libraries for extending objects[3]. Just encourage people to use idiomatic JS and then layer on solutions when and if they become a problem.

The article uses stories of obscure bugs as justification. These stories get used an awful lot to justify dogma on everything from strict typing to Promises to whatever. I feel that's misguided - there will always be enough rope to hang oneself with in any language, and those errors should have been mitigated by diligent use of static code analysis (linting) and unit testing. The author's book Programming JavaScript Applications[4] (which looks excellent otherwise) doesn't cover testing, either, but devotes a chapter to using logging for debugging. I'd rather advocate using lint-on-save, test-driven development, test coverage, and continual integration.

Also, for a deep dive into OO criticism, Thomas Neimann's article Nuts to OOP! is a must-read. [5]

[1] http://yuiblog.com/blog/2006/11/13/javascript-we-hardly-new-ya/

[2] http://en.wikipedia.org/wiki/Open/closed_principle

[3]…

Thank you for this article. I recently started teaching my sister how to program and chose Python thanks to articles/discussions on HN similar to this one.

If you are taking pull requests here are a few suggestions:

* "Honing Those Skills"

+ http://hginit.com (Free, Web)
[Why? I found it a wonderful intro to distributed version control in general and Mercurial specifically]

+ http://yuiblog.com/crockford/ (Free, Video+Transcripts)
[Why? Provided great context and in-depth details in a very efficient manner]

* "Gettin’ Paid, Makin’ Money"

+ C# / .NET (Large job pool)

* "Things You’ll Need"

+ Ability to take constructive criticism
[Why? Get better faster. Appreciate user feedback.]

* "Not Another Neckbeard"

- Teh Womenz
[Why? It's obvious from your comments that you do not feel this is sexist nor did you mean it to be. I would have to log this under "taking constructive criticism" however. You point out that you know women who don't mind but there are some women who are bothered by this and taking it out would not impact the goal of the article. If you can make 1 person feel better about your writing by removing it to avoid any misunderstandings while not altering your meaning, it seems like a win for all.]

I wouldnt be put off reading The Good Parts by that post, although it does raise some valid points IMHO. The point is, the author of that blog post probably wouldn't have even known about those things had they not read the book. Whether something is 'good' or 'bad' is somewhat subjective. Check out Crockford's YUI Theatre lectures (http://yuiblog.com/crockford/) to get a taste of what you'll be in store for in that book.

At some point in those videos he mentions a book called The Little Schemer - I haven't read that but the reviews on Amazon look decent and if Crockford calls it out as useful you should probably not ignore it.

I found a really good book to be Object Oriented JavaScript from Packt (http://www.packtpub.com/object-oriented-javascript/book). Unlike most other js books, it spends a good few hundred pages without mentioning browsers. I seem to recommend their books a fair bit, no I do not have anything to gain from doing so :)

Finally, once you start getting stuck into things go hang out in the #node.js IRC channel. IRC is still probably the best technical resource out there as far as I'm concerned, especially when the community is as friendly as the #node.js regulars are.

HTML is not complicated at all, that's why it became a success - pretty much anyone could learn to write a basic web page in a few weeks.

Web pages became complex over the years as people wanted do things that HTML was never meant to do. Like page layouts: Early on, people would use invisible images for spacing, humongous nested tables to "hack" a page layout in a language that didn't support page layouts, and pictures of text rather than actual text for example for non-standard fonts or text shadows.

The primary problem is that HTML was never designed for the kinds of things we use the web for today. See the Crockford Javascript presentation for a history of HTML and Javascript, I recommend Episode IV: http://yuiblog.com/crockford/

Designing an "HTML killer" is no simple task, all attempts so far have failed - from Java applets to XML.

But even today you can use applets or Flash to embed more complicated programs. The web protocols turned out to be eminently hackable, and with server-side page generation, forms, CSS, Javascript and now canvas it is "good enough" for more and more tasks, so I expect it is safe to say that HTML will be with us for quite a while longer.

I'll assume this is for client side js, since that's what most people use =)

Most of the js I write involves jQuery. As such, I find it's very useful to separate reusable components into jQuery plugins in separate files. If you don't use jQuery or another library which allows plugins, then it's best to create your own namespaced module.

See the "Module pattern" for more info:
http://www.yuiblog.com/blog/2007/06/12/module-pattern/

Depending on the complexity of your code, you might want to look into javascript build systems -- there's at least one for every major web framework.

Here's some advantages they offer:
- Allow bunding of many js files into one mega js file. (reduces HTTP requests for faster page loading)
- Specify javascript dependencies using special syntax. (easier maintenance)
- Versioning support (so users don't get an old cached version of your code)

When bundling js files, I try to aim for a maximum of two js files per page. One contains code which is global to the whole site (this is cached on subsequent views), and the second which contains page specific code.