I've been reading this book. I'm about 50% of the way through now.
I learnt JavaScript a long time ago so I wanted something to get me up to speed with ES6 and above. The book succeeds admirably here. It is a little bit repetitive in places, but for free I'm not going to complain about that.
If you are reading this Flavio Copes - thank you :-)
This is great to read. I played with JavaScript many years ago (over 10 now I think) and need to get into VueJS very soon. It sounds like this book will help.
I feel the same way...I'm about half way through..been doing tons of Vuejs work lately (vue + laravel), but it does help cement some little things I 'see' in tutorials or stackoverflow and didn't fully grok. It's a good handbook to 'fill in the pieces'....
Thank you! People underestimate how difficult it is to emerge as an independent content producer. It's not the first time I share something in this way and every time someone pops up with this generous offer to the other readers. I don't mind as I might get less throwaway accounts in the list :) but if the topic is of any interest to you, my email newsletter is nothing but more similar content.
I tried to sign up. But when google decides I am not human even after 2 correct captcha, I closed the tab and used the above link. I avoid that google nonsense as much possible.
Good on ya mate. Keep going and remember: the nay sayers simply aren't your market. Just move on from them and only pay attention to the people being positive.
Personally, I'd much rather see a "pay what you want" (even with a minimum of a couple bucks) type of system rather than compulsory email newsletters [0].
You can still have the newsletter of course (and even give away copies for signing up). Just please don't have it as the ONLY way to get the full book :)
[0]: Of course I'm aware of mailinator, but why waste both our time, in that case?
Agreed. Or at least an option to pay, without email registration. It's not that I can't block spam - it's more: I'm not interested in some newsletter - and I don't understand why you want me to sign up. I assume there's some kind of upsell planned - but surely getting paid ten to twenty dollars (or more) for the epub is a viable option? If the alternative is a newsletter that goes straight to /dev/null?
> It's not that I can't block spam - it's more: I'm not interested in some newsletter - and I don't understand why you want me to sign up.
Exactly. I've been burned by the whole "it's free so just sign up and cancel later". Not that this is exactly the case here.
My email address obviously has monetary value to them, so I'm immediately curious as to why, exactly. When I can just pay money, it eliminates an entire class of concerns [0].
[0]: i.e. "what are they doing with my email?", "do they filter out Mailinator?", "am I robbing them of their income if I use Mailinator?"
That's interesting! In my case I'm an independent publisher and this "product" lets me step into a possible group of people that might never know about me otherwise. Someone that might appreciate other work I do, in the same topic, which I distribute through my newsletter (I try to create a useful set of resources every week, as a full-time effort).
I'm more interested on providing value on the long term rather than making a quick buck with "pay as you want". Of course all the usual throwaway domains are then filtered out :)
For many reasons, I would love to hear more about your model.
Just be aware that I (and others) are immediately on guard whenever something asks for email (or any personal info, for that matter). _Especially_ if that info is a barrier to something like a book. For better or for worse, it looks an awful lot like the typical email-harvesting-for-spam techniques.
> making a quick buck with "pay as you want"
If you're writing books and people are getting value out of them, I'd argue you deserve even more than a quick buck. Don't sell yourself short.
I don't think anybody would see pay what you want as a cash grab, either.
I don't get the incessant desire for terseness by seemingly the majority of programmers. Terse != better. I'd much rather see
area = width * height
then
a = w * h
As a simple example but it seems most programmers feel some sense of accomplishment the using the least number of characters and lines possible with no though to readability or maintainability.
I was with you on 1 and 2, but you lost me on 3. In the props example, where it came from is generally not your concern when you are reading or modifying those lines - and when you do have that concern about where they come from, the destructuring version is easy to follow. Personal preferences to be sure though.
I feel many fluent API's are guilty of something similar. You gain terse, one-line magic statements that accomplish a lot; you lose discoverability and meaningful object-oriented class names.
For example, ElasticSearch's NEST API client uses a fluent-style API to setup configuration and mappings. It started out well, but then I got lost in a forest of nested callbacks on various mystery objects. It was a bizarre way to build what should have been a tree of strongly-typed POCO's that have a 1-to-1 correlation with the server-side concepts. Worse, I didn't see a way to dynamically manipulate the (hidden) result. Better to use the low-level API and a little reflection to compose the required JSON manually.
[On the other hand, I can think of successful fluent API's: .NET's StringBuilder works because it is super simple (only returning instances of itself). The IEnumerable extension methods (created to support LINQ) work because their broad-applicability justifies the effort to learn.]
In my experience no one likes seeing single-letter variable names (except for i, but I have even heard criticism of using e to represent an error). As for your second example, whether it provides clarity or convenience is entirely situational. If you have a long render method then specifying that a variable is coming from props may be helpful but the most common standards call for props to be passed to a functional component that has a single responsibility, i.e. destructuring props and rendering its respective values.
Sorry if I missed something but I also don't see an endorsement of bad variable names in the OP's handbook. The comment just seems a little out of place, thought I mostly agree with it.
I prefer a = w * h. I actually wish I didn't, but I studied a mathematics undergrad, and when I see the token 'area' it means, to me, the concept of area, whereas 'a' is a variable which represents the quantity in context.
Indeed, it's more common to write 'let the area be a, the width be w and the height h; then a = w * h' than it is to write 'area = with * height' when expositing in a maths textbook. This is a really hard habit for me to get out of, even when writing code.
Readability is subjective. There's no universal notion of "readability". Code that looks perfectly fine to one person, might looks like pure gobbledy-gook to the other. It's important to recognize that, whenever we're talking about "code readability".
1) I find the description of the different standards (ES2015 - ES2018) to be inconsistent. ES2015 provides a summary of new features as a bullet point list, each item being a jump link to the detailed description. ES2016 and ES2017 do have the summary but no more jump links and ES2018 does not have the summary at all. I think it would be better to navigate if each chapter had the linked summary.
2) I guess in ES2017 the trailing comma description is missing a trailing comma:
This feature allows to have trailing commas in function declarations, and in functions calls:
const doSomething = (var1, var2) => {
//...
}
doSomething('test2', 'test2')
At least I can not see a trailing comma there.
3) Unicode property escapes (p. 33ff) examples do have a comment at the end of each line which I guess is supposed to tell you whether the match will be true or false, but all comments are empty (in the pdf version).
4) The template literal interpolation example on page 69 is invalid syntax
const var = 'test'
const string = `something ${var}` //something test
as var is a reserved keyword and can not be used as a variable name.
5) On pages 76-77, for some reason the formatted code looks different to all other code snippets (and it doesn't look good either as it is too huge and kind of blurred)
Thank you, this was actually tremendously useful for me because you used simple language/short sentences and are quite thorough. My only remark is that if your intended audience is more on the beginner side, they will likely lose focus early on during the initial history lesson. However if your intended audience is actually me, I found it fascinating and appreciate you making this great free resource!
I recommend this iPad-book 'Let's Learn ES6' by Ryan Christiani [1] to bring you up to speed with some of the features of modern JavaScript. It's got videos on it!
Thanks for this - really nice to read, and cleared up a lot of things I have seen and didn't really get.
A couple of typos:
Page 103 of PDF under "Event bubbling and event capturing"
Bubbling and capturing are the 2 models that events use to propagate.
Suppose you DOM structure is
should be
Suppose your DOM structure is
Page 153 of PDF under "Operators > Arithmetic operators"
It shows Division (https://flaviocopes.com/) but should have been the / symbol
I find myself on flavio's site pretty often coming from google when looking up node topics. He puts out a lot of content, publishing every day. You also might be reading his node content as the official getting started guide on the nodejs website, pending this PR's review.
Can't speak for the downvoters, but the omission of Eich is kind of a trivial point to nitpick on. At this point I've probably read the 'Brendan Eich created Javascript in 10 days' story 50 times—and even heard it once from the man himself. I would be perfectly fine if Javascript books from here on out saved a few pages worth of dead trees and simply said "For more info on Javascript's creation, visit https://en.wikipedia.org/wiki/JavaScript"
I agree. This seems to focus on practical information rather than the history of the language itself. How is the name of the language's creator something that you need on hand while working with the language? It is a handbook, after all.
I've been reading this book. I'm about 50% of the way through now.
I learnt JavaScript a long time ago so I wanted something to get me up to speed with ES6 and above. The book succeeds admirably here. It is a little bit repetitive in places, but for free I'm not going to complain about that.
If you are reading this Flavio Copes - thank you :-)
This is great to read. I played with JavaScript many years ago (over 10 now I think) and need to get into VueJS very soon. It sounds like this book will help.
I feel the same way...I'm about half way through..been doing tons of Vuejs work lately (vue + laravel), but it does help cement some little things I 'see' in tutorials or stackoverflow and didn't fully grok. It's a good handbook to 'fill in the pieces'....
Thanks a lot! I'm happy to see you appreciate it!
sadasd
Direct link to the book without having to provide your email address: https://flaviocopes.com/page/javascript-handbook/
Please support the author in their endeavour. Sign up with your email to get the book. It's a small ask for a big win.
Thank you! People underestimate how difficult it is to emerge as an independent content producer. It's not the first time I share something in this way and every time someone pops up with this generous offer to the other readers. I don't mind as I might get less throwaway accounts in the list :) but if the topic is of any interest to you, my email newsletter is nothing but more similar content.
I tried to sign up. But when google decides I am not human even after 2 correct captcha, I closed the tab and used the above link. I avoid that google nonsense as much possible.
Good on ya mate. Keep going and remember: the nay sayers simply aren't your market. Just move on from them and only pay attention to the people being positive.
Sure it is possible but why?
Personally, I'd much rather see a "pay what you want" (even with a minimum of a couple bucks) type of system rather than compulsory email newsletters [0].
You can still have the newsletter of course (and even give away copies for signing up). Just please don't have it as the ONLY way to get the full book :)
[0]: Of course I'm aware of mailinator, but why waste both our time, in that case?
Agreed. Or at least an option to pay, without email registration. It's not that I can't block spam - it's more: I'm not interested in some newsletter - and I don't understand why you want me to sign up. I assume there's some kind of upsell planned - but surely getting paid ten to twenty dollars (or more) for the epub is a viable option? If the alternative is a newsletter that goes straight to /dev/null?
> It's not that I can't block spam - it's more: I'm not interested in some newsletter - and I don't understand why you want me to sign up.
Exactly. I've been burned by the whole "it's free so just sign up and cancel later". Not that this is exactly the case here.
My email address obviously has monetary value to them, so I'm immediately curious as to why, exactly. When I can just pay money, it eliminates an entire class of concerns [0].
[0]: i.e. "what are they doing with my email?", "do they filter out Mailinator?", "am I robbing them of their income if I use Mailinator?"
That's interesting! In my case I'm an independent publisher and this "product" lets me step into a possible group of people that might never know about me otherwise. Someone that might appreciate other work I do, in the same topic, which I distribute through my newsletter (I try to create a useful set of resources every week, as a full-time effort). I'm more interested on providing value on the long term rather than making a quick buck with "pay as you want". Of course all the usual throwaway domains are then filtered out :)
For many reasons, I would love to hear more about your model.
Just be aware that I (and others) are immediately on guard whenever something asks for email (or any personal info, for that matter). _Especially_ if that info is a barrier to something like a book. For better or for worse, it looks an awful lot like the typical email-harvesting-for-spam techniques.
> making a quick buck with "pay as you want"
If you're writing books and people are getting value out of them, I'd argue you deserve even more than a quick buck. Don't sell yourself short.
I don't think anybody would see pay what you want as a cash grab, either.
I find it odd that it starts with ES6(arrow functions), ES2016, etc and then moved to basics like variables and functions.
I guess it works for people with enough experience, but still, I find it odd.
Anyway it is free so I can't complain too much, subscribed.
I don't get the incessant desire for terseness by seemingly the majority of programmers. Terse != better. I'd much rather see
then As a simple example but it seems most programmers feel some sense of accomplishment the using the least number of characters and lines possible with no though to readability or maintainability.I'd much rather see
then ...Even more controversial I'm not sure I like the new common pattern of destructuring as in
vs Because the second style provides more info on each line. I know where the various values are coming from where as I don't with the first style.I was with you on 1 and 2, but you lost me on 3. In the props example, where it came from is generally not your concern when you are reading or modifying those lines - and when you do have that concern about where they come from, the destructuring version is easy to follow. Personal preferences to be sure though.
I feel many fluent API's are guilty of something similar. You gain terse, one-line magic statements that accomplish a lot; you lose discoverability and meaningful object-oriented class names.
For example, ElasticSearch's NEST API client uses a fluent-style API to setup configuration and mappings. It started out well, but then I got lost in a forest of nested callbacks on various mystery objects. It was a bizarre way to build what should have been a tree of strongly-typed POCO's that have a 1-to-1 correlation with the server-side concepts. Worse, I didn't see a way to dynamically manipulate the (hidden) result. Better to use the low-level API and a little reflection to compose the required JSON manually.
[On the other hand, I can think of successful fluent API's: .NET's StringBuilder works because it is super simple (only returning instances of itself). The IEnumerable extension methods (created to support LINQ) work because their broad-applicability justifies the effort to learn.]
In my experience no one likes seeing single-letter variable names (except for i, but I have even heard criticism of using e to represent an error). As for your second example, whether it provides clarity or convenience is entirely situational. If you have a long render method then specifying that a variable is coming from props may be helpful but the most common standards call for props to be passed to a functional component that has a single responsibility, i.e. destructuring props and rendering its respective values.
Sorry if I missed something but I also don't see an endorsement of bad variable names in the OP's handbook. The comment just seems a little out of place, thought I mostly agree with it.
I prefer a = w * h. I actually wish I didn't, but I studied a mathematics undergrad, and when I see the token 'area' it means, to me, the concept of area, whereas 'a' is a variable which represents the quantity in context.
Indeed, it's more common to write 'let the area be a, the width be w and the height h; then a = w * h' than it is to write 'area = with * height' when expositing in a maths textbook. This is a really hard habit for me to get out of, even when writing code.
Readability is subjective. There's no universal notion of "readability". Code that looks perfectly fine to one person, might looks like pure gobbledy-gook to the other. It's important to recognize that, whenever we're talking about "code readability".
On your last point, it's easier to see all props the component depends on when you destructure them upfront like that.
This looks pretty legit. Seems like a good "If you know how to code this is where JS is at right now."
Source: I call myself a "Front End Engineer".
I can see using oversized fonts is a bit of a pattern with this author.
Maybe it's just that they like regular sized fonts on undersized pages?
Those fonts are pretty big.
Source: can read them without my glasses :)
> Source: can read them without my glasses :)
I can't :-p
This isn't (much of) a dig at the author, but yeah: I can't even read "The Javascript Handbook" heading on a 1920x1200 monitor.
I can see ignoring the needs of visually impaired users is a pattern with the parent poster
Well, everyone is free to adapt the font size to their needs but those fonts are pretty huge.
Thanks for the book, its clear and to the point.
A little feedback:
1) I find the description of the different standards (ES2015 - ES2018) to be inconsistent. ES2015 provides a summary of new features as a bullet point list, each item being a jump link to the detailed description. ES2016 and ES2017 do have the summary but no more jump links and ES2018 does not have the summary at all. I think it would be better to navigate if each chapter had the linked summary.
2) I guess in ES2017 the trailing comma description is missing a trailing comma:
At least I can not see a trailing comma there.3) Unicode property escapes (p. 33ff) examples do have a comment at the end of each line which I guess is supposed to tell you whether the match will be true or false, but all comments are empty (in the pdf version).
4) The template literal interpolation example on page 69 is invalid syntax
as var is a reserved keyword and can not be used as a variable name.5) On pages 76-77, for some reason the formatted code looks different to all other code snippets (and it doesn't look good either as it is too huge and kind of blurred)
FYI to the author, Privacy Badger hides the signup elements on the page because it’s served from a third party marketing CDN.
Thank you, this was actually tremendously useful for me because you used simple language/short sentences and are quite thorough. My only remark is that if your intended audience is more on the beginner side, they will likely lose focus early on during the initial history lesson. However if your intended audience is actually me, I found it fascinating and appreciate you making this great free resource!
Great to hear, I'm happy you enjoyed it so far :)
Is there a JavaScript book that only covers the "modern" topics of JS (+DOM API where applicable) My knowledge is probably from 2008
This was posted on HN a few weeks ago...might be somewhat useful in that it does cover some more recent concepts in JS.
https://github.com/leonardomso/33-js-concepts
I recommend this iPad-book 'Let's Learn ES6' by Ryan Christiani [1] to bring you up to speed with some of the features of modern JavaScript. It's got videos on it!
https://bubblin.io/cover/let-s-learn-es6-by-ryan-christiani
Another resource that I like is Wesbos's video tutorials on all things JS. He has a separate course on ES6 which is great! And then there is MDN.
There are few topics more irritating to learn on video than programming... :-)
Maybe the books from Axel Rauschmayer are what you’re looking for.
http://exploringjs.com
Thanks for this - really nice to read, and cleared up a lot of things I have seen and didn't really get.
A couple of typos: Page 103 of PDF under "Event bubbling and event capturing" Bubbling and capturing are the 2 models that events use to propagate. Suppose you DOM structure is
should be Suppose your DOM structure is
Page 153 of PDF under "Operators > Arithmetic operators" It shows Division (https://flaviocopes.com/) but should have been the / symbol
Hey. Thanks for the book.
Btw, page 25. I assume this is some pdf exporting error:
Thank you! I didn't notice it
It would have been great as a normal homepage, the pdf format is a bit hard to read on the phone while on the buss :)
I think this medium post by the author is the same text as the PDF.
https://medium.freecodecamp.org/the-complete-javascript-hand...
I find myself on flavio's site pretty often coming from google when looking up node topics. He puts out a lot of content, publishing every day. You also might be reading his node content as the official getting started guide on the nodejs website, pending this PR's review.
https://github.com/nodejs/website-redesign/pull/105
Thanks, saved me from giving me email and getting spam :)
Spam is mailing you didn't agree to receive. Not this case where the author is pretty clear on what you're getting into.
You can always use ThrowAwayMail[0] when you don't want to give away your email.
[0] https://www.throwawaymail.com
Nice, this was a good refresher on some of the lesser known parts of the newer specs.
+1 for explaining the event loop and job queues
-1 for no semi-colons though (kidding ;))
Ha... I give him +2 for no semicolons.. the only time they hurt me is when I jump back to php and start forgetting to add them... lol
Anyone else getting a bad cert error in Chrome opening this address?
I do, but I happen to know that our corporate firewall intercepts dropbox and other cloud storage sites.
well there's one very obvious ommission: no mention of Brendan Eich?
That's definitely an omission on my part, that's an interesting story and a needed attribution. Will add in a revision soon!
for the downvoters, maybe the author's name should be scrubbed from his little book too? wtf
Can't speak for the downvoters, but the omission of Eich is kind of a trivial point to nitpick on. At this point I've probably read the 'Brendan Eich created Javascript in 10 days' story 50 times—and even heard it once from the man himself. I would be perfectly fine if Javascript books from here on out saved a few pages worth of dead trees and simply said "For more info on Javascript's creation, visit https://en.wikipedia.org/wiki/JavaScript"
I agree. This seems to focus on practical information rather than the history of the language itself. How is the name of the language's creator something that you need on hand while working with the language? It is a handbook, after all.
Link fixed: https://en.wikipedia.org/wiki/JavaScript
im not suggesting a chapter on it, just a basic attribution or citation would be good (ettiquette).
anyway i did enjoy the concise style of the handbook. well done!
don't waste your time with that.
Why??