HN Books @HNBooksMonth

JavaScript: The Good Parts by Douglas Crockford. Note that this was written in 2008 but still holds up well.

https://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfo...

It may be a perfect time for a revision.

⬐ gabrielsroka

"How JavaScript Works" by Crockford was published in 2018.

https://www.amazon.com/gp/aw/d/1949815005/ref=dbs_a_w_dp_194...

https://youtu.be/8oGCyfautKo

⬐ mayank

Please stop recommending this book until it gets an update. It may as well be describing a different language in 2020. It definitely does not hold up well for modern ES6, which is more widely supported than one may think.

⬐ throwanem

It predates ES5, and a revision is imo long overdue. It was an excellent resource in its day, but there are a lot of good parts too new for it to have covered.

I also want to add the great Eloquent JavaScript[0] to this list. While its targeted at learning programming as a whole, its still a wonderful resource, even for seasoned programmers, to learn some ins and outs of the language if you haven't had a lot of experience with it.

I also want to give mention to JavaScript: The Good Parts by Douglas Crockford[1], and his new book, How JavaScript Workers[2]

[0]: https://eloquentjavascript.net/

[1]: https://www.amazon.com/dp/0596517742/wrrrldwideweb

[2]: https://howjavascriptworks.com/

⬐ scruple

> JavaScript: The Good Parts by Douglas Crockford

I've been wondering lately, as I'm moving (back) into a JavaScript-heavy stack (it's been... 4-5 years for me), is this book still relevant in the face of 12 years of JavaScript language development?

⬐ agentultra

The code in it will still run and work but there are much better patterns and features now that help you write more succinct and less error-prone code.

ES6 and ES7 are widely supported now and are much better languages IMO.

⬐ scruple

Thanks, that's kind of what I thought. I recently, finally, took it off of my book shelf and stuffed it into a box in the garage, but it's been in the back of my mind a few times as I've been going through other resources. It's good for the historical understanding but I couldn't see it being terribly relevant today.

⬐ piyh

As a noobie, Eloquent Javascript was much better for me than The Good Parts. The Good Parts was a book of how not to program, followed by the right way of doing it. Eloquent was a guided path to understanding the language without being shown all the dead ends.

Knowing the dead ends and the history behind them is nice, but I spent a lot of brain power on the dead ends that Eloquent put towards better use.

We're also talking a small book vs a tome of knowledge, but the philosophy is different regardless of size.

⬐ fidelramos

Unless the book has had an updated edition it's missing all the ES6 good stuff. It was good to avoid the pitfalls of JavaScript in the past, but nowadays you should be using ES6, strict mode and, if that strikes your fancy, TypeScript.

⬐ squeaky-clean

I personally never really liked that book even when it was new. It's good if you wanna get up and running with JS fast while coming from another language, and are forced to use JS in places but it's not the main language of your project.

But it doesn't really give a strong foundation on understanding the language. It's more like "I know mainstream C-inspired languages, and JS often burns me with its weird quirks like how the this keyword works, I just want to avoid getting burned". But it doesn't really embrace JS itself, just sort of acknowledges that you will be forced to use it in the web so you may as well at least learn the "good" parts.

It's still decent at that purpose, but for really strong competency in JS I can also vouch for the Eloquent JS book and the You Don't Know JS series (I've only read the first edition, a new edition is partially complete and available online).

⬐ kqr

> it doesn't really embrace JS itself, just sort of acknowledges that you will be forced to use it in the web so you may as well at least learn the "good" parts.

I'm sure you know this, so I'm just pointing it out for completeness sake: that was indeed the only sensible approach to JavaScript back when that book was written.

⬐ mxschumacher

Given the publication date of May 2008, isn't "JavaScript The good parts" deeply outdated at this point? Would you still give it to a beginner?

⬐ hajile

It's a subset of modern JS, but a subset you cannot escape from as all modern features are layered on top of it.

⬐ nogabebop23

I would not give it to a beginner, but definitely to an intermediate-plus developer from a non-JS background. The best parts are the reasonable but strong opinions and the admittance of very bad parts. The code is less valuable today but as mentioned above, still runs fine.

Today this book makes a good companion but not a great single source reference.

⬐ benrbray

I would like to take this opportunity to point out that the author of "Eloquent JavaScript", Marijn Haverbeke, also created both CodeMirror and ProseMirror [1], which are both extremely well-regarded open source code/text editing tools. I can especially recommend ProseMirror after spending a lot of time with it recently. It's an actually sane wrapper around contenteditable.

[1] https://prosemirror.net/

Something to keep in mind: Javascript has a lot of obscure language idiom that aren't used in practice. This has to do with how the language was rushed into production, and has gone through quite a lot of revisions.

This point is made in the (now very outdated) book "Javascript: The Good Parts," https://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfo.... Crockford, the author, brings you through the best way to write Javascript in 2008.

Related note: I once attended a talk from Crockford in 2010 where he was rather religious about how async code was significantly better than threads. I pointed out that async code is significantly harder to write due to the mess of callbacks, and his answer was quite rude. Now Javascript has async-await, which fixes the madness that comes from callbacks.

⬐ 101404

And in between callbacks and asyncawait, it had Promises. I still often prefer those over asyncawait.

⬐ pintxo

The value is in knowing when to use which.

⬐ eyelidlessness

Async/await is semantically just sugar for promises (though implementations don't necessarily operate that way).

⬐ fjp

I never wrapped my mind around the Promises API, but I have always async/await is much easier to grasp in any language

⬐ pintxo

Maybe because it should have looked like this (personal opinion):

    waitForPromise()
        .then(handleResolve)
        .fail(handleReject)
        .catch(handleException);

But actually looks like this:

    waitForPromise()
        .then(handleResolve, handleReject)
        .catch(handleException);

⬐ csnover

waitForPromise().catch(foo) is exactly the same thing as waitForPromise().then(undefined, foo). Your first example is essentially the same as:

    waitForPromise()
        .then(handleResolve)
        .catch(handleReject)
        .catch(handleException);

With the exception that if `handleResolve` also throws then that will be picked up by `handleReject`, whereas in `waitForPromise().then(handleResolve, handleReject).catch(handleException)` it won’t.

⬐ pintxo

And you last sentence is exactly describing the issue I have. This merging of exception handling and rejection handling into one function call feels like a bad idea.

As initially I thought catch() is only handling promise rejections. Then suddenly I ended up in the catch() although the Promise resolved fine, just to learn that my handleResolve code threw an exception. Unsurprisingly my handleReject code was not prepared for this.

⬐ threatofrain

In my mind callbacks abstract events and it's better to toss events into a more composable async pipeline than it is to write a body of code to ad-hoc handle a problem right there.

JS is going to be so different in 2019 that I'm expecting a revised version of "The Good Parts"[1]

[1] https://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfo...

⬐ eropple

That book is of an era and hasn't been particularly relevant in quite awhile. The rise of classes as prototype sugar made a lot of the navel-gazing of object creation mostly moot. The rise of rigorous linting took care of the rest.

TypeScript helped a lot, too.

⬐ jcadam

I do not use the 'class' keyword in Javascript and I never will.

I mean, I don't like using it in Java either, but it isn't really optional there...

⬐ stevula

Not optional for React devs. Well... maybe now with hooks.

⬐ Roboprog

Some of us consider “class” a bad thing.

I would rather work in a language/style that draws its inspiration from Scheme than Simula 67.

Too bad more places are picking up TypeScript rather than ClosureScript.

⬐ eropple

You can consider it a bad thing, but 1) it's a really thin layer on top of prototypical inheritance, 2) it makes JavaScript more accessible to people who are used to conventional styles of language, and 3) it won, indisputably.

ClojureScript didn't win, and never had a chance to win, because it's written for the small minority of Clojure people. It wasn't written for the overwhelming majority of developers. TypeScript was. So sorry that the existence of those day-to-day programmers puts a crimp in your utopia, but, enh. Personally, I'm glad we have tools to make it easier to write libraries to help that majority be more productive and to make their code safer and more correct!

⬐ nine_k

Classes are fine! Inheritance isn't. You can mostly avoid using it, though.

JS lacks homoiconicity and thus can't have a lot of nice things a Lisp dialect would, notably macros.

With what we've got, I have more hope on JS eventually migrating towards a (more) statically typed language with ML influence; typescript sort of leans towards it, slowly.

⬐ sli

You're right about Lisp features, but CLJS macros are kind of bad at the moment. I have a fairly simple macro that works just fine in Clojure but does not compile in ClojureScript and I can't figure out why. It's probably a side-effect of how macros are handled in CLJS (they're part of a different compilation stage and must be written in CLJ or CLJC, hence :require-macros instead of just :require).

If you're looking for an ML, check out ReasonML. It's really quite good, its output is quite good (and hotfix friendly), and its type system is far better than TypeScript's will ever be. Mostly because TS wants to stay close to JS. Too close, in my opinion.

⬐ sli

It really is a shame because ClojureScript is an absolute joy to work with. TypeScript and Javascript feel so incredibly tedious to write after using CLJS for a few months.

I would really love to move into PureScript as well, but I haven't quite wrapped my arms around Haskell as a whole, yet. So maybe I should tip my toes back into Elm for a bit.

⬐ orangecat

I would rather work in a language/style that draws its inspiration from Scheme than Simula 67.

Then you should push for WebAssembly improvements so you can use whatever language you want. As long as JavaScript is a de facto requirement for web development it needs to be as approachable as possible to a wide developer audience, and that means looking more like Java than Lisp.

⬐ jcadam

> and that means looking more like Java than Lisp.

No.

(No (No (No (No (No)))))

⬐ BigJono

Or we could've considered it an opportunity to move people away from classical inheritance and towards something that's conceptually much simpler? (which both prototypal inheritance and functional programming are)

⬐ boomlinde

JS is and always was prototype based. The class keyword is as far as I know just syntax sugar that creates a prototype chain and a new-able function that assigns the prototype to self.

⬐ jwalton

The '#privateVar' syntax means that classes are no longer simply syntax sugar, unfortunately.

⬐ eropple

Private variables could always be simulated with IIFEs. I'm pretty sure that's actually how TypeScript does it if you compile down low enough.

⬐ pjmlp

Yet all successful functional programming languages do support doing OOP as well.

Counterpoint to Doug Crockford, JavaScript: The Good Parts. https://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfo...

Buried inside JavaScript is a nice small language. And then there is the rest.

I used this books. Secrets of javascript Ninja - https://www.manning.com/books/secrets-of-the-javascript-ninj...

javascript : good parts - https://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfo...

Read this https://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfo...

That's really all you need to get started.

⬐ gpayal

thank you :)

I know this book isn't free, but I really can't recommend it enough http://shop.oreilly.com/product/9780596517748.do http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...

JavaScript is kind of ugly in some ways, but not really complicated. You could easily pick up the basics in that time frame.

I've heard people say good things about this book:

http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...

But I've never read it myself.

⬐ reesdreesd

That's encouraging. Thanks for the reference.

I've had the exact same concerns as the person you replied to. I just want to make sure since the title differs from the one you stated. Is this the book you were talking about: http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor... And how/why did the book improve your opinion about the language?

⬐ callum85

It's an opinionated book that sets out a subset of JavaScript that you should use, avoiding all the 'bad parts'. This subset is what tools like JSLint and JSHint were designed to promote - they flag you up if you use a bad part. It's a seminal work. These days I find some of its rules a little dogmatic (for instance I like the 'new' keyword now), but I'm glad I went through a phase of sticking to it relgiously for a while. It taught me to stop bitching about the weird parts, just avoid them instead. And when you do this, you end up loving the language and making cool shit with it. Which is a good situation to be in, because it's the most widely distributed runtime in the world.

⬐ Havvy

But `new` is a bad part. Just an optimized bad part... You could replace every usage of it with `var instance = Object.create(Ctor.prototype);` (and change every `this` to `instance` in your code), and actually explicitly return `instance` -- and then never use `new` again. Your code will become more readable to boot, as there is less action at a distance.

⬐ callum85

Where is the action at a distance when I use new?

⬐ Havvy

The `new` is used at the call site while invisible at the function declaration.

You may have to learn to put up with it. It's not the end of the world. It's just a scripting language, just suck it up and deal.

There are any number of js frameworks which will probably abstract away most of the headaches you might have, and depending on what you're actually trying to accomplish, you may not need a lot of js at all. If you don't want to use client-side templating, for instance, and there's no reason to, then just skip it. Push as much of it to the backend in the language of your choice as you can.

But javascript, when you need scripting in the browser, is kind of unavoidable.

Also consider http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor... - your expectations from working with other languages may be getting in the way of your writing javascript properly and effectively.

(or do what a lot of other people do and work with a language that compiles to js and you can pretend you live in an alternate universe where you're not working with javascript even though you really are.)

Yes. I believe such a book exists (or should at least) for every language as well.

Effective Java — http://www.amazon.com/Effective-Java-Edition-Joshua-Bloch/dp...

POODR (Ruby) — http://www.poodr.com/

Javascript the good parts — http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...

There is of course also the gang of 4 language agnostic classic on design patterns http://www.amazon.com/Design-Patterns-Elements-Reusable-Obje...

Code Complete 2 [1] was one of the first coding books I've read. As with anything else, it's good to look around (HN is a good place) for people who have problems with the book. I think I learn as much reading the commentary people make about books like that as I do from the book itself.

I think I've listened to every podcast on software engineering radio a few times [2]. The older ones are especially nice because they usually pick a specific topic and cover the high points. I liked that I could listen to it while I was driving, or otherwise not in front of a computer.

It's specific, but Javascript: The Good Parts is probably the most used book I have on my shelf. It has such a perfect amount of usable information in it. It's pretty great. Again, it's definitely worth looking up critiques and counterpoints.

I've also got Introduction to Algorithms, which I use as a reference, sometimes. I switched over to The Algorithm Design Manual [5] after I saw it referenced in an older Steve Yegge post [6]. I read through the intro and it seemed like a book that would be more appropriate from an autodidactic standpoint. I really have no idea if that's going to pan out, since I'm not that far into it, but we'll see, for sure. Doesn't kill me to have an extra algorithms book laying about, though, and I've always got intro to algorithms for cross reference. I've found that I really need to have as many sources available as possible when I'm learning alone. Usually I don't get something until the fifth person describes it from the tenth different angle.

That's most of what I can think of off hand. I really enjoyed The Joy of Clojure [7], though haven't checked out the newer version. Programming Collective Intelligence [8] is a fun book, and is what made me want to go back down the maths route to get more into machine learning.

And of course habitually reading hacker news for an hour or three every night :)

So that's my totally inexpert list of random stuff that I enjoy

[1] http://www.amazon.com/Code-Complete-Practical-Handbook-Const... [2] http://www.se-radio.net/ [3] http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor... [4] http://www.amazon.com/Introduction-Algorithms-Thomas-H-Corme... [5] http://www.amazon.com/Algorithm-Design-Manual-Steven-Skiena/... [6] http://steve-yegge.blogspot.com/2008/03/get-that-job-at-goog... [7] http://www.amazon.com/Joy-Clojure-Michael-Fogus/dp/161729141... [8] http://www.amazon.com/Programming-Collective-Intelligence-Bu...

In addition to what Isiebert said, if you're a book person, read javascript, the good parts http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor....

⬐ kachhalimbu

or if you prefer watching instead of reading, watch Douglas Crocford talk about JavaScript early years in this talk http://www.youtube.com/watch?v=JxAXlJEmNMg

I would of course add "The good parts" by Crockford to the list.

But maybe that is just par for the language course, before one even starts to wants to master Engineering :)

JavaScript: The Good Parts - http://www.amazon.com/gp/product/0596517742/ref=as_li_ss_tl?...

Here's a few other good ones:

Functional JavaScript: Introducing Functional Programming with Underscore.js - http://www.amazon.com/gp/product/1449360726/ref=as_li_ss_tl?...

Secrets of the JavaScript Ninja - http://www.amazon.com/gp/product/193398869X/ref=as_li_ss_tl?...

Javascript Allongé (free to read online) - https://leanpub.com/javascript-allonge

Javascript Spessore (free to read online, but currently work in progress) - https://leanpub.com/javascript-spessore

Here's a good one about Angular, my favorite framework:

Mastering Web Application Development with AngularJS - http://www.amazon.com/gp/product/1782161821/ref=as_li_ss_tl?...

I would of course also recommend the Egghead videos for any Angular aficionados: http://www.youtube.com/playlist?list=PLP6DbQBkn9ymGQh2qpk9Im...

PS. The Amazon links are affiliate links.

⬐ drallison

No one should do anything serious without having read Doug Crockford's Javascript: the good parts. There is a nice OO -language hiding in the closet.

I second JavaScript: The Good Parts[1]. It is very well-written and very dense, so you can read and reread it multiple times, each time gathering something new. Along with that I would recommend the Mozilla Developer Network JavaScript reference[2].

[1] http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...

[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Javascript: the good parts <http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor....

Eloquent Javascript <http://eloquentjavascript.net>.

These two are a great start.

⬐ iends

These are excellent beginner books.

⬐ grobertson

And when you're done those, JavaScript Patterns is something you'll refer to often.

http://www.amazon.com/JavaScript-Patterns-Stoyan-Stefanov/dp...

If you're just getting started with Javascript, I'd say learn Javascript and jQuery. Here are two good books:

    http://www.amazon.com/dp/0596517742
    http://www.amazon.com/jQuery-Action-Second-Bear-Bibeault/dp/1935182323

If you want to use Javascript/Ajax in a Rails application, this is a good introduction to how Rails' "remote" forms/links work in a jQuery context:

    http://www.alfajango.com/blog/rails-3-remote-links-and-forms/
    http://www.alfajango.com/blog/rails-3-remote-links-and-forms-data-type-with-jquery/

I would get to the point where you understand all that before tackling Angular, Ember, or Node.

I haven't found a use for a lot of these features, a lot of them just seem very ad-hoc additions to the language. A class based object oriented model would have solved a lot of issues relating to the myriad ways to implement object orientation in javascript. The schizophrenic like approach we have right now isn't being helped by incremental changes driven by the lowest common denominator of what can be implemented in a web browser development cycle.

Knowing the [Good Parts](http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...) helps but you just can't keep adding parts that you think may be good.

⬐ thingification

Here is the context that makes these features not seem ad hoc:

http://www.infoq.com/interviews/ecmascript-5-caja-retrofitti...

Many of the additions (including object.freeze) and changes were made for the purpose of making JavaScript usable as an object capability language. Mark Miller explains the background and some of the changes in the video linked above.

While I think GWT is a pretty good project and has some way to go before it can be categorized as failing, some of your other remarks make me think that you have not given appropriate consideration to the alternatives to its approach.

First and foremost, you can write javascript in such a way that your code does nothing weird and only what you intended. A good place to start is still "JavaScript: The Good Parts"[1]. Then I suggest finding some examples of nicely written javascript code on GitHub or some such site. I personally think underscore.js[2] and backbone.js[3] are rather nice.

If you have really given javascript a fair shot, and still strongly dislike it, there are many other languages that compile into javascript, but match its style more closely that Java does. I have been enjoying working in CoffeScript[4]. There is an excellent interactive book[5] that shows the javascript generated by the constructs in the language, which is also a good resource for discovering idioms to do things that are not obvious in javascript, like creating classes. TypeScript[6] and Dart[7] are both interesting languages with syntax more familiar to Java. There are a lot more languages that compile to javascript that I haven't mentioned[8].

It's possible that GWT and Java are the best fit for you, but don't pigeonhole yourself by thinking that they are the only good options out there.

[1] http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor... [2] https://github.com/documentcloud/underscore/blob/master/unde... [3] https://github.com/documentcloud/backbone/blob/master/backbo... [4] http://coffeescript.org/ [5] http://arcturo.github.com/library/coffeescript/02_syntax.htm... [6] http://www.typescriptlang.org/ [7] http://www.dartlang.org/ [8] https://github.com/jashkenas/coffee-script/wiki/List-of-lang...

> The scope of a parameter, local variable, or local function declared within a function declaration (including a constructor, member function, or member accessor declaration) or function expression is the body of that function declaration or function expression.

This thing claims to be meant for "application-scale" JavaScript, and yet doesn't repair even JavaScript's most notorious error?

A suggestion to the authors. Purchase this book:

http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...

... then go through the book with a fine-tooth comb, and every time it describes something as a "bad part" or an "awful part", delete or fix that misfeature in TypeScript.

⬐ AdamTReineke

Except then you would likely lose the attribute of being a superset of JavaScript.

Everything other than http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...

⬐ dkersten

I have not read the book, but I'm told that (despite being only 176 pages) half of that book actually talks about language flaws and bad parts and only half of the book is actually about the good parts. Again, have not read it, just what I was told.

⬐ mattdeboard

There is are a couple appendices at the end that discuss the truly terrible and the simply bad-but-work-aroundable parts. Most of it is discusses the subset of the language that is powerful and expressive. He starts the book off by saying "Javascript is a steaming pile of good intentions" which pretty much sets the tone for the rest of the book.

You should read it. It IS very short and can be read in one sitting. Then you wouldn't be left to trust the word of others.

I've heard that same argument for a long time from PHP people. Yea, these are all but tools we use for the job. But bottom line is, some tools are just worse than others at pretty much any real practical use. [1] You make it sound like you've read the Javascript: The Good Parts book [2]. I've read it too, and it's a great book I recommend for anyone who must work with Javascript and have no way out of it. But keep in mind that an important premise of the book is aid those who are in this position where they can't run away from Javascript. As shown by this thread of languages that compile to it, it's often perfectly possible to dodge the shortcomings of JS by just not using it. You shouldn't torture yourself for no good reason. If you are in a position where you must work with JavaScript. Then I recommend reading this book to learn to stay away from the bad parts, as you said. But if you can work with any of the compilable languages, I highly recommend you stay away from JS as much as you can.

I would repeat the exact same argument for using SASS or LESS instead of CSS. There is no good reason to torture yourself with CSS instead of these better languages. It's very clear that there is such thing as one language that is much better than another in every practical sense.

[1] http://www.flickr.com/photos/raindrift/sets/7215762949290803...

[2] http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...

⬐ tikhonj

His argument wasn't that "it's just a tool for the job" but that JavaScript is actually a rather cool language. And it is. At any rate, I certainly like it more than most other "scripting" languages, except maybe for Lua.

I would never suggest using most of the languages on that list over JavaScript. In fact, the only ones I recommend are Lisp, Ocaml and Haskell. Maybe something like Ur/Web as well. Coffeescript is good too, but it's basically lightly improved JavaScript. I find JavaScript simpler, more expressive and generally nicer than most of the other languages listed (ignoring the ones I've never seen or used).

Ultimately, JavaScript is a nice language with some warts. But, for whatever reason, the warts are blown out of proportion compared to other languages--in my experience (out of the languages I've used significantly) Python, Perl and Java all have more significant shortcomings. I think the main reason is that JavaScript position in the browser forced a lot of people to use it against their will, which leads to more complaining.

⬐ Joeri

I think javascript's main "problem" is the combination of duck typing with prototypal inheritance. People coming from a classical strictly typed OO language are very put off by that.

Ofcourse, my problem is I'm so used to javascript's duck typing that I now feel horribly constrained by a strictly typed environment.

That's right! I love the discovery part of these visualizations. It helped me to find proper books many times - the graph drawing library is a result of such discovery.

I wanted to learn JavaScript. So I read a book recommended by my old Silverlight-based visualization, and developed the library.

I believe recommendation was successful. The book is Crockford's "JavaScript: The good parts" - http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...

1. Learn JavaScript (the language)

http://eloquentjavascript.net/ http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...

2. Learn jQuery (a JavaScript library)

http://jquery.com/ http://www.amazon.com/jQuery-Action-Second-Bear-Bibeault/dp/...

3. Learn SQL (the language)

http://www.amazon.com/Sams-Teach-Yourself-SQL-Minutes/dp/067...

4. Pick an implementation

MySQL, PostgreSQL, SQL Server, Oracle

----------------------------------

After that, most application development languages are just syntax. Pick what feels best.

Learn how to use Ajax to tie client-side requests to server-side requests and you're marketable.

⬐ charliepark

Agreed on points 1 and 2, but for front-end development, 3 and 4 are unnecessary and will pull you away from more relevant lessons, or (even more important), applying what you've learned to new problems.

Effective Java is the best book for general Java that I know - http://www.amazon.com/Effective-Java-Programming-Language-Gu... It's not a tutorial, but a collection of recommendations that could take you from just-learnt to competent.

Very slim, and very good - Javascript: The Good Parts http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...

For a C reference, Harbison & Steele is excellent - http://www.amazon.com/Reference-Manual-Samuel-P-Harbison/dp/...

⬐ lemming

I don't know Harbison & Steele, but both Effective Java and Javascript: The Good Parts are really excellent. Worth noting that they're both really only about the language, not the accompanying libraries/environments.

⬐ andrewcooke

H&S is what I thought K&R would be, but wasn't. It's an obsessively detailed description of the C language and standard libraries, in readable english, that describes everything from "traditional C" through ISO, to C++ compatible. When I'm working in C I use it as much as I use man pages, to help me keep the code as standard and cross-platform as possible.

"Steele" is Guy Steele, btw - http://en.wikipedia.org/wiki/Guy_L._Steele,_Jr. (author of "Common Lisp, The Language", developer of Fortress, etc etc).

besides by "doing it" I say bulletproof web design is a good book to start with. http://www.amazon.com/Bulletproof-Web-Design-flexibility-pro...

javascript- the good parts could also be helpful http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...

www.jquery.com smashingmagazine.com ajaxian.com

all helpful

JavaScript: The Good Parts, http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...

Watch Crockford on Javascript at ydn: http://developer.yahoo.net/blogs/theater/archives/douglas_cr...

Watch @ryah on nodejs at ydn: http://www.yuiblog.com/blog/2010/05/20/video-dahl/ (and the other javascript related videos linked on that page)

⬐ rlmw

+1 for JavaScript: The Good Parts

⬐ dawson

Tempted to buy the Kindle edition. Any reasons for or against, compared to the printed?

⬐ uptown

For tech books, I prefer to be able to hold a book, flip around quickly to sections I'm interested in, and mark things with a bookmark.

⬐ siculars

Buy the printed book off amazon for 20 bucks. Personally, I'm not sold on the ebook experience for a number of reasons.

⬐ tjpick

the ebook experience is great for stuff you just want to read and not have hanging round. Like autobios, novels etc.

It's not yet great for tech books, stuff where you have to jump around randomly rather than reading linearly, books with deep TOC.

⬐ kroger

I have a kindle edition of "Javascript the best parts" (I bought the ebook bundle, a mobi + pdf, on O'Reilly) and it's good enough. Usually when the book doesn't have long code examples it's fine to read on the kindle. OTOH, sometimes they will convert code to images, which is not so good (e.g python essential reference).

I hope the quality of programming books on the kindle will improve in the future, but now it's not too bad if you buy the mobi/pdf combo. You can always use the pdf on your computer if you need to check something quickly and your kindle is not nearby.

For me, the biggest advantage of having programming books on the kindle is that you can easily carry a few 1000+ pages books around and get some reading done when you have some unexpected down time.

I feel that programming books on the kindle are particularly good when you're learning something new and want to read sequentially. It's not so great for reference as you'd need to jump around and that's not kindle's forte. (although I do use the pdf as reference)

Edit: I forgot to mention that O'Reilly has a 7 day return policy on ebooks. I only wish they had a ebook sample like amazon has.

If you like this article, you'll love the book "Javascript: The Good Parts":

http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...

I like Douglas Crockford's opinions and advice on many aspects of JavaScript:

http://javascript.crockford.com/

Conventions:

http://javascript.crockford.com/code.html

and his book "JavaScript The Good Parts" is well worth a read, even to experiences JS developers

http://www.amazon.com/exec/obidos/ASIN/0596517742/wrrrldwide...

Thanks, I totally forgot about the Resig book since it was announced. Just bought.

I really liked _Javascript: The Good Parts_:

http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...

Particularly because it's purely about style and code organization, and not about the best way to get consistent DOM access between Gecko, WebKit, and IE.

⬐ tyrmored

That book is outstanding. Crockford's JSLint validator is also superb. Highly recommended for any script of more than a few lines in length.

Crockford's "Javascript: The Good Parts" is also a nice little read.

http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...

Note that there's a lot of bad webdev information on the web. Go to the experts and the sources. Avoid random blog's advice on javascript especially.

HTML: http://www.w3.org/TR/html4/ http://www.sitepoint.com/books/html1/

CSS: http://www.sitepoint.com/books/cssdesign1/ http://www.css-discuss.org/

JS:

See this timeless rant for a tiny example (countering all the bad advice you see on a trivially easy feature): http://youngpup.net/archived/popups.html

You may wish to do some JS dev without a framework just to get a taste for the terrible truth. Then get jquery or one of the other excellent tools.

JS quirks: http://www.quirksmode.org/

Books: http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor... http://www.amazon.com/Pro-JavaScript-Techniques-John-Resig/d...

Also, some good tools: wget curl firebug wireshark (neé ethereal) yslow

webby python code libs: http://codespeak.net/lxml/ http://code.google.com/p/httplib2/ http://code.google.com/p/simplejson/ http://labix.org/python-dateutil

Relevant validators: http://validator.w3.org/ http://www.jslint.com/ http://jigsaw.w3.org/css-validator/ http://feedvalidator.org/

⬐ jdunck

Also note that requests and responses are bits on the wire.

Do not assume you can trust client data. Do not put client data directly into SQL or back on the page. This includes headers. Nearly all aspects of a request can be forged.

Security info: http://www.slideshare.net/simon/when-ajax-attacks-web-applic...

After you get security and basic dev down, you can start to worry about scaling. It's important, but it's a nice problem to have. Deal with it later.

It is embarrassing to have to admit that I'm only halfway through a book as compact as JavaScript: The Good Parts. But so far it is a very good book.

http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor...