A book series on JavaScript • Hacker News Board

Re: A book series on JavaScript

#101

Post by IIJamesII » Sun, Jun 26, 2016, 11:22 PM UTC

mlvljr wrote: post #11

Can the web use a language, simple enough to not need multiple books to allow to understand its mechanics? As this metaclass / function VS Function / whatever dispatch business is much worse than recently discussed message-passing purism, in its worst forms.

Yes. Kyle Simpson rocks. He is smart and he looks deeply into things. He is opinionated and I like that too. I learn more when I see smart opinionated people disagree with each other.

The fact that these books need to be written to de-mystify JS is evidence that JS sucks. We should not need to know esoteric crap - NOR SHOULD WE BE SATISFIED with programming by rote as many above seem to be advocating. (!?)

Having said that, JS is improving and the future looks bright.

(Disclaimer: this coming from someone self-employed who has never worked on a team.)

Re: A book series on JavaScript

#102

Post by bbcbasic » Mon, Jun 27, 2016, 5:17 AM UTC

ben_jones wrote: post #82

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.

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 foundatio…

I think the books would take you to a basic knowledge of JS rather than expert level. This is the problem - the amount you need to know to be an effevtive programmer is growing out of control, as we attempt to make more ambitious applications than 10 years ago, for a decreasing (in real terms, unless you are in SV) salary. That means more weekends studying (working for free) to keep your place in this industry.

Re: A book series on JavaScript

#103

Post by Gabry » Mon, Jun 27, 2016, 5:41 AM UTC

zappo2938 wrote: post #15

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.

Here is my review for JavaScript coding interviews.[0] I should update the REST API section a little since I learned how to use Swagger. [0]: https://github.com/adam-s/js-interview-review

Thanks for sharing, that's a great list as I'm approaching js related interview questions.

Re: A book series on JavaScript

#104

Post by fapjacks » Mon, Jun 27, 2016, 9:26 AM UTC

_getify wrote: post #87

fapjacks wrote: post #16

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 "fre…

The irony of your comment is glorious. Thank you.

Re: A book series on JavaScript

#105

Post by michaelbuddy » Mon, Jun 27, 2016, 4:06 PM UTC

sethetter wrote: post #34

Secretmapper wrote: post #13

Earlier quoted context omitted.

This is too true. I've had a software engineer complain to me at how unfair his last interview was because they asked "esoteric javascript" questions in a front-end javascript development position. I asked him what questions he found tricky and a lot of them are really simple javascript 'things' (scopes, closure, iife, etc) that would come up sooner or later when you're working with the language

I think there is still a lingering mentality that you don't have to be an expert with JS to do front end work, and that's just not the case anymore.

the way I experienced it was really the word Front End really just went through different meanings. There are a lot of UI jobs where javascript isn't a major focus, though some of it is there. Despite what is heard on hacker news, a lot of dev is happening without angular, react etc.

I used to answer to jobs for Front End developer, but now you see Front end jobs posted with no relationship to design arts. Those positions are now UI Web Designer. Front End now from my perspective at looking at job postings might as well be javascript only or javascript plus SASS.

Re: A book series on JavaScript

#106

Post by _getify » Sat, Jul 02, 2016, 4:43 PM UTC

ninkendo wrote: post #99

Just reading through the first few chapters of the book on the `this` keyword (which, as an aside, is shocking to see that the feature is so confusing that it merits its own entire book), the code snippets could use some serious attention. The variables are all `foo`, `bar`, `baz`, `a`, `obj`, etc. And the values are all just numbers. Sometimes they have a function that takes a value `a`, and they just do `this.a = a…

Just FTR: this is not accidental or lazy on my part. It's highly intentional. But I can certainly appreciate that it frustrates some learners.

There's a principle called "Cognitive Load Theory" [1] which I believe all teachers have to take seriously. Specifically, the "extraneous cognitive load". It's why I choose to introduce concepts with foo/bar style first.

I am concerned by the observations I've made over many years of teaching (JS) that many people tend to get distracted by problem domains and miss out on the underlying concepts. For example, if I am teaching about `this` but I use an example like a login system, it's far too easy for someone to get distracted by what they know -- or worse, what they don't know -- about how login systems work.

It's an overload on the cognitive side because the learner (reader) is having to juggle not only the new concepts but also their knowledge/opinions/baggage about the problem domain.

Cognitive overload is so "dangerous" not just because you might overflow someone's capacity and they stop getting anything out of the teaching, but because it has the tendency to become subtractive and actually cause them to lose what they already knew or had learned about the concept.

So... my approach in teaching, which is also reflected in the books, is to default to teaching a concept first without a problem domain, using generics like foo/bar, and THEN once I feel someone has the concepts, later, you can reinforce those with practical applications in problem domains.

IOW, I'd teach the abstract principles of `this` first, then the abstract principles of the Prototype system, then I'd start to show some examples like a login system that show how you can put those abstract concepts together into a real thing.

Anyway, I understand it doesn't meet your preference, but I just wanted to explain the reasoning behind it from my side.

[1] https://en.wikipedia.org/wiki/Cognitive_load

Re: A book series on JavaScript

#107

Post by askRich » Sat, Jul 02, 2016, 5:14 PM UTC

_getify wrote: post #106

ninkendo wrote: post #99

Just reading through the first few chapters of the book on the `this` keyword (which, as an aside, is shocking to see that the feature is so confusing that it merits its own entire book), the code snippets could use some serious attention. The variables are all `foo`, `bar`, `baz`, `a`, `obj`, etc. And the values are all just numbers. Sometimes they have a function that takes a value `a`, and they just do `this.a = a…

Just FTR: this is not accidental or lazy on my part. It's highly intentional. But I can certainly appreciate that it frustrates some learners. There's a principle called "Cognitive Load Theory" [1] which I believe all teachers have to take seriously. Specifically, the "extraneous cognitive load". It's why I choose to introduce concepts with foo/bar style first. I am concerned by the observations I've made over many y…

First I'd like to thank you for your work. I've learned a lot from you and your teachings.

When it comes to "foo bar" examples, as a learner, I think it causes MORE cognitive load not less.

I think this is because, it's hard to make connections between meaningless words like foo, bar and baz

Conversely, most of the "aha" moments come from your ELI5-like explanations of concepts

The concept of a "promise" made sense to me when you used buying a hamburger at a fast food store in your workshop on asynchronous javascript.

Re: A book series on JavaScript

#108

Post by dwltz » Sat, Jul 02, 2016, 5:22 PM UTC

askRich wrote: post #107

_getify wrote: post #106

Earlier quoted context omitted.

Just FTR: this is not accidental or lazy on my part. It's highly intentional. But I can certainly appreciate that it frustrates some learners. There's a principle called "Cognitive Load Theory" [1] which I believe all teachers have to take seriously. Specifically, the "extraneous cognitive load". It's why I choose to introduce concepts with foo/bar style first. I am concerned by the observations I've made over many y…

First I'd like to thank you for your work. I've learned a lot from you and your teachings. When it comes to "foo bar" examples, as a learner, I think it causes MORE cognitive load not less. I think this is because, it's hard to make connections between meaningless words like foo, bar and baz Conversely, most of the "aha" moments come from your ELI5-like explanations of concepts The concept of a "promise" made sense t…

I agree with this, foo/bar/baz stuff is abstract and means nothing. This means the learner need stop associate something they don't know with nothing which is really hard. An analogy of something the learner knows is way easier to grasp..

Re: A book series on JavaScript

#109

Post by braythwayt » Sat, Jul 02, 2016, 5:22 PM UTC

_getify wrote: post #106

ninkendo wrote: post #99

Just reading through the first few chapters of the book on the `this` keyword (which, as an aside, is shocking to see that the feature is so confusing that it merits its own entire book), the code snippets could use some serious attention. The variables are all `foo`, `bar`, `baz`, `a`, `obj`, etc. And the values are all just numbers. Sometimes they have a function that takes a value `a`, and they just do `this.a = a…

Just FTR: this is not accidental or lazy on my part. It's highly intentional. But I can certainly appreciate that it frustrates some learners. There's a principle called "Cognitive Load Theory" [1] which I believe all teachers have to take seriously. Specifically, the "extraneous cognitive load". It's why I choose to introduce concepts with foo/bar style first. I am concerned by the observations I've made over many y…

TL;DR: When teaching nuclear physics, do not place a bike shed on the diagram.

Re: A book series on JavaScript

#110

Post by abhisack » Sat, Jul 02, 2016, 8:45 PM UTC

_getify wrote: post #106

ninkendo wrote: post #99

Just reading through the first few chapters of the book on the `this` keyword (which, as an aside, is shocking to see that the feature is so confusing that it merits its own entire book), the code snippets could use some serious attention. The variables are all `foo`, `bar`, `baz`, `a`, `obj`, etc. And the values are all just numbers. Sometimes they have a function that takes a value `a`, and they just do `this.a = a…

Just FTR: this is not accidental or lazy on my part. It's highly intentional. But I can certainly appreciate that it frustrates some learners. There's a principle called "Cognitive Load Theory" [1] which I believe all teachers have to take seriously. Specifically, the "extraneous cognitive load". It's why I choose to introduce concepts with foo/bar style first. I am concerned by the observations I've made over many y…

Instead of getting lost in the jungle, 'foo', 'bar' style helps understand the concept. To the ones who say it's not an effective way; What if a learner is coming from non 'web-dev' background e.g. from a mathematical one who wishes to create complex alogorithms and geometries, interfaces etc. with JS, Won't he, on seeing 'login' code, wish that it were of his interest? After all JS is not only used to just create typical sites. What if learner was going to use JS on iot, robots etc.? So stereotyping the code with some particular 'web-dev' usecases is not useful (atleast not at the beginning). 'foo', 'bar' style helps focus on what it's really important to learn at first.

It's like -- 'a human without makeup is the most real'