Live data from Hacker News

A book series on JavaScript

github.com

81–90 of 111 posts

Re: A book series on JavaScript

#81
post #33
post #6

I can highly recommend these books. They're one of the only books that do a real deep-dive into the language. I often have to interview people for javascript jobs. It's astonishing how few of them actually get how the `this` keyword, closures, prototypes etc work. So the title of the series may be arrogant, but not wrong.

I fully agree, those books are awesome if you want to truly understand JS. I would, however, not say that understanding JS will help you become a better programmer and the time invested in fully understanding JS might be better invested somewhere else. Some parts of "understanding JS" is just understanding a (insert your swearword) designed language, unfortunately. You might just not fully understand those parts and…

Even if you do understand how things like prototypes work, you will also need to understand how efficiently a compiler can implement changes to them. And how consistent/predictable the resulting code will be in terms of speed.

Re: A book series on JavaScript

#82
post #6

I can highly recommend these books. They're one of the only books that do a real deep-dive into the language. I often have to interview people for javascript jobs. It's astonishing how few of them actually get how the `this` keyword, closures, prototypes etc work. So the title of the series may be arrogant, but not wrong.

The problem is that there are a lot of developers who have obtained an 'expert' level understanding of some corner of software development who then wrongly gain the perception that that understanding is both necessary and reasonably expected among the general population of developers. It's not far away from interviewing an English teacher in Japan and expecting them to understand Latin because "latin is the foundation of English".

Re: A book series on JavaScript

#83
It is good stuff but I think it would be even better if there was a precise opinion on what parts to use, JavaScript the good parts + Jslint not only teaches you Js, but also how to write good quality js (avoid the bad parts) which is something that is more beginner friendly.

Re: A book series on JavaScript

#84
post #50
post #47

Earlier quoted context omitted.

I think "JavaScript: The Good Parts" is outdated now, in particular the way it advocates handling object-oriented programming and inheritance with a "roll your own" method. It was great for its time, but especially with the advent of ES2015, modern JavaScript is going in a different direction.

My point was, it's not outdated. Javascript 2016 just got new featured that oviously aren't covered. The class syntax is just a syntactic sugar and it's important to understand how it's working under the hood. JS has prototype based inheritance, which is more powerful and flexible than class based inheritance. JS is therefor different to grasp than Java and C#. There are still many coding JS and don't get it.

I don't recommend using the class syntax and I would even advise to favour composition over inheritance.

Re: A book series on JavaScript

#85
post #67

Earlier quoted context omitted.

Funny. JS is my main language, and I personally also don't know most of the intricacies of JS, and we seem to share the same mindset. I mean, I do know common pitfalls and I can use `this`, etc., it's just that I find it's easier to avoid them entirely and leads to more readable code IMHO. In a way my JS tends to just be very scheme-like.

I find JS works well as an OO-language, and falls short as a functional one. Not only when writing it, but also when it's executing. Dumb-as-rocks object oriented JS-code tends to have a smaller memory footprint, is less crufty, and is easier to debug. Functional JS-code tends to spam the heap, difficult for the JIT to optimize, and when writing it you have none of the compile-time safety of a true functional languag…

This may indeed be true, but I've found the performance penalty to be acceptable for my use cases.

There ARE times where I had to optimize though (HTML5 game developer, and we target mobile so this is expected) but for the most part 'premature optimization is the root evil'.

Re: A book series on JavaScript

#86
post #25

Earlier quoted context omitted.

There is no difference in JavaScript, they have the same semantics & meaning. However, single quotes have two advantages (IMO, since this is obviously subjective): 1. can be typed without shift on US keyboard layout 2. I use double quotes inside string literals (e.g. for quoting bad input in error messages) more often than single quotes (mostly used for contractions) so not having to escape double quotes by default i…

Also, double quotes are in HTML attributes, and JS can be embedded in HTML attributes and vice versa (though it's less common nowadays)

HTML supports both single-quotes and double-quotes.

Re: A book series on JavaScript

#87

If you search Amazon for these titles, you'll see the author reacting poorly to bad reviews.

First, I think it's disingenuous for an author to revel only in the positive reviews and "just ignore" the negative. An author should take all feedback and do the best with it he/she can. I read all reviews, and try to find anything I can in there to get better. That's why I'm sending this reply.

You probably think I should just "ignore the trolls" and you probably also think that anyone's negative expression is "freedom of speech" and that it shouldn't be countered.

I don't see it that way. The public ratings on my books are how a lot of people figure out if the books are worth looking at. No matter how legitimate or crazy a negative review may be, the one star hurts my overall rating exactly the same.

Furthermore, if I let a negative review go unanswered, I've lost an opportunity to show other readers a different perspective, and I've also lost the opportunity to (perhaps) engage in productive discussion that helps either that reviewer, or myself, or both, get better. Yes, this has actually happened before on a couple of occasions.

I don't think I'm reacting poorly by trying to find useful stuff even in the negative reviews. And I also don't think it's wrong to point out that unhelpful reviews are unhelpful.

I'm sorry this comes across as off-putting. But it's because I care so deeply about improving JS education through these books.

Re: A book series on JavaScript

#88

Earlier quoted context omitted.

Also, double quotes are in HTML attributes, and JS can be embedded in HTML attributes and vice versa (though it's less common nowadays)

HTML supports both single-quotes and double-quotes.

True, and XML as well. But double-quotes are by far the norm. (Why? I don't know... :)

Re: A book series on JavaScript

#89

From what I read, the author uses double quotes for string literals, "some string". Most of the style guides and linters recommend using single quotes, any idea on the advantage of each?

The latest version of JSLint recommends using double quotes. It complains unless you use the Single option.

Re: A book series on JavaScript

#90
post #51

Earlier quoted context omitted.

NP, it's so common an occurrence on HN, I think it's self reinforcing. :) (Using 'i.e.' when meaning 'e.g.' is similarly frequent.)

Ah, I'm alright with those as I know the Latin! It's only everyday English words I seem to have a problem with ;-)

You and me should be friends, for I also don't have any problems knowing when to use "i.e." and when to use "e.g." but if I were to post what you did, I too would have incorrectly said "disclaimer".
Post reply on HN