Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A book series on JavaScript

github.com

Post reply on HN
Print view View original

71–80 of 111 posts

Re: A book series on JavaScript

#71

Post by spraak »

trgn wrote: post #67
Secretmapper wrote: post #54

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 is surprising.. do you have any examples of memory footprint, crufty-ness, and debug-ability for OO vs functional style JS?

Re: A book series on JavaScript

#72

Post by ontouchstart »

dang wrote: post #68
ontouchstart wrote: post #65

Earlier quoted context omitted.

Quote Alan Perils > A language that doesn’t affect the way you think about programming is not worth knowing. There are many different motivations behind studying a language. You can study it for a job interview, for a job requirement, or for personal enlightment. I had my enjoyment of reading some well written JavaScript books such as the "Rhino book" ( https://www.amazon.com/JavaScript-Definitive-Guide-Activate-...…

I agree with Perlis, but he was championing languages like APL, which offer truly different ways of thinking about programming. The arbitrary ins-and-outs of extrinsically complicated designs are another matter; learning those doesn't necessarily affect one's thinking about programming for the better. I realize that what I'm saying sounds trollish, but it's something it took me many years to figure out.

Being a big fan of APL (and J), I agree with you.

On the other hand, for JavaScript you might want to take a look (beyond technical merits) at its social context. Client side JavaScript is deeply related to the design and implementation of the DOM. Whether we like it or not, the social aspect of browser really makes JavaScript unique in the history of programming languages.

That is the context of "the way of thinking" I am looking at.

Re: A book series on JavaScript

#73

Post by dang »

ontouchstart wrote: post #72
dang wrote: post #68

Earlier quoted context omitted.

I agree with Perlis, but he was championing languages like APL, which offer truly different ways of thinking about programming. The arbitrary ins-and-outs of extrinsically complicated designs are another matter; learning those doesn't necessarily affect one's thinking about programming for the better. I realize that what I'm saying sounds trollish, but it's something it took me many years to figure out.

Being a big fan of APL (and J), I agree with you. On the other hand, for JavaScript you might want to take a look (beyond technical merits) at its social context. Client side JavaScript is deeply related to the design and implementation of the DOM. Whether we like it or not, the social aspect of browser really makes JavaScript unique in the history of programming languages. That is the context of "the way of thinking…

That's quite an interesting take, but I've imbibed too many Alan Kay talks to buy it except as a case study in bloat. The social contexts leading to extrinsic complexity are many; those leading to breakthroughs of simplicity are precious few. I'd rather study the latter—and even better than study, be part of one!

Re: A book series on JavaScript

#74

Post by dang »

callumlocke wrote: post #62
dang wrote: post #53

I've been writing JS a long long time and my strategy has been to never learn the intricacies of 'this', or the other bad neighborhoods of that language (but especially 'this'). I just avoid those neighborhoods. I write functions at the top level, keep all the signatures explicit, and enjoy the things in the language that are straightforward. Once every couple years or so something comes up that forces me to dip a to…

I used to have that mindset and it felt like a strength at the time, but now I see it as something that held me back from being better. Obviously it's best to stick to a high quality subset of the language in your code. But the brain doesn't run out of storage space, and having a deeper knowledge of the whole language brings context and confidence that makes you better at developing. These books have a refreshing, ac…

> But the brain doesn't run out of storage space

I felt that way when I was younger but eventually lost my taste for poring over masses of "just-because" detail, and became more sensitive to the cognitive cost of doing so. It isn't merely that the time and energy could be spent on other things, but that the brain responds to learning by patterning on it. If I spend energy on that, my work gets more like that and my brain thinks more like that, and I don't want them to.

(By the way, I'm not criticizing those books at all. I don't know them, but if they're as good as you say I think that's great.)

Re: A book series on JavaScript

#75

Post by ontouchstart »

dang wrote: post #73
ontouchstart wrote: post #72

Earlier quoted context omitted.

Being a big fan of APL (and J), I agree with you. On the other hand, for JavaScript you might want to take a look (beyond technical merits) at its social context. Client side JavaScript is deeply related to the design and implementation of the DOM. Whether we like it or not, the social aspect of browser really makes JavaScript unique in the history of programming languages. That is the context of "the way of thinking…

That's quite an interesting take, but I've imbibed too many Alan Kay talks to buy it except as a case study in bloat. The social contexts leading to extrinsic complexity are many; those leading to breakthroughs of simplicity are precious few. I'd rather study the latter—and even better than study, be part of one!

Then perhaps we should give these good guys a hand and bring them into 21st century:

https://github.com/jsoftware

Re: A book series on JavaScript

#76

Post by bgnm2000 »

I love these books, and I've also been in corporate JS trainings with the author. I can't express how much more clear Kyle was able to make every aspect of Javascript for me. Javascript has actually become my language of choice thanks to these books (and in-person sessions).

Re: A book series on JavaScript

#77

Post by darth_mastah »

kabes wrote: 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 agree. Having interviewed many people for JS jobs I have realised they actually don't know the language. The pressure these days is on frameworks. Do you know React? Angular? The assumption being that if someone can find they way around a framework they know the language. Not true.

Kyle's efforts to educate people are priceless and he's doing great job. I have watched two of his courses on Frontend Masters, I don't agree with everything he says, but I have great respect for the guy and for his work.

Re: A book series on JavaScript

#78

Post by darth_mastah »

renke1 wrote: post #27
paradite wrote: post #24

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?

I do use double quotes in my JS projects, mostly out of habit though. One reason I can think of why people use double quotes is because JSON only supports double quotes and it's not uncommon to deal with JSON when you program in JS.

And they write stringified JSON in their source code? Hm...

Re: A book series on JavaScript

#79

Post by paulddraper »

grncdr wrote: post #25
paradite wrote: post #24

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?

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)

Re: A book series on JavaScript

#80

Post by fapjacks »

bshimmin wrote: post #20
fapjacks wrote: post #16

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

Someone commented on his free e-book by saying "meh", and he replied: Note that this review not only is completely unhelpful with just the single word "meh", leaving me nothing as an author to do to improve... but also that this review was from the kindle edition, which is FREE. ChrisP got a free copy of my book -- intentionally offered that way at a loss of income to both me and my publisher -- and took the time to…

Yes, he does react poorly elsewhere to comments he should have ignored. For example in response to reviews calling him pedantic, it's almost like someone wrote him hate mail or called his child a name. I think it's in poor taste to take to Amazon to fight bad reviews that are mostly just someone's opinion.
Post reply on HN