Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: The JavaScript Way, a book for learning modern JavaScript from scratch (github.com/bpesquet)
545 points by bpesquet on July 27, 2017 | hide | past | favorite | 110 comments

Hi all, author here.

Backstory: I'm a CS engineer/teacher and this book is a side project started in December 2016. You can read a bit more about it here: https://medium.com/@bpesquet/walk-this-javascript-way-e9c45a....

The writing process is now completed and I'm actively looking for feedback to make the book better. Any opinion or advice about content, pricing, or that hastily created Leanpub cover would be greatly appreciated. However, please keep in mind that this is a self-published effort still far from being polished and open to improvement.

I'd also like this thread to stay focused on the book itself, not on the merits/weaknesses of JavaScript or the usefulness of choosing it as a first programming language.

Thanks in advance!

Nice. Thanks for sharing.

Bravo for burrito recipe. I'm convinced I became a programmer in 4th grade. Our creative writing assignment was instructions for making a peanut butter & jelly sandwich. Then our teacher followed our instructions literally. Hilarity ensued.


I think the Intro's link to the local env setup in the appendix is broken.

Anymore, I always check the colophon first, then decide to proceed.

I applaud the online option.

I'm dubious of the local option. "Install the latest XYZ" will bite you (your students). Especially with JavaScript and nodejs. Mayflies live longer.

For future, should tutorials start with Docker images, or scripts, or virtualbox images, or something, to mitigate digital drift? Hoping other commenters will share their ideas, experiences.

> Our creative writing assignment was instructions for making a peanut butter & jelly sandwich. Then our teacher followed our instructions literally.

Did something very similar at an IBM day camp where we did the same thing :) I was 12 when I attended. I distinctly remember the epiphany I had after the sandwich lesson.

On one of the other days we did Lego MindStorm stuff. I was randomly assigned to the "software" team. They gave us a little workbook/journal with questions for us to reflect on the daily activities. One of the questions for that day was what we liked best. I wrote something very similar to "programming because that's what I want to do when I grow up" (I had decided that then and there). I am a software developer now and that workbook is one of my prized possessions.

> Our creative writing assignment was instructions for making a peanut butter & jelly sandwich

The Harvard CS50 class uses this as an example as well - with mixed results that are hilarious, but relatively obvious once you start thinking about coding and recipes.

Here is the video: https://www.youtube.com/watch?v=euFj8D1A1Kw

Re: nodeJS versions, I'd go with something like "Install NodeJS, this book was written with version x.y.z"; I don't think JS will become backwards incompatible in the near future, so as long as the book doesn't contain experimental or unofficial JS features, it should be fine for the next 5-10 years.

Anecdotal I suppose, but I have an app that was written for node 5 and it doesn't work on 6+. I'm sure I could figure out and upgrade it, but it's not too high on the priorities yet thanks to nvm. Oh, and it's not the code, it's one or more of the npm modules.

Odds are that it is a native module. That's unfortunate, but there is a plan in place to make a consistent native module API: https://github.com/nodejs/abi-stable-node

For digital drift: anything content-addressable (e.g. using git and referencing SHAs) is your answer. Continued availability and support, though? If you can answer that question, you should probably quit your current job and use your divination talents in more profitable fields.

I used the Peanut Butter and Jelly one in my classes when I taught programming. I also used "tying shoes". Both of those examples came from a class I took on how to teach general subjects. Before you can teach someone, you need to be able to explain it well. Thus, before you can tell a computer to do it, the same applies.

> I think the Intro's link to the local env setup in the appendix is broken.

The book is written using Leanpub's markdown syntactic sugar it seems.

Side note: That teacher's method is great! That's a hell of a way to have kids remember what you taught them.

I've seen a few comments here suggesting you spend time explaining how to install toolchain etc or version issues.

I agree that having a default VirtualBox VM might be the best way to go so it's a 2 step install and everyone is on the same page regardless of what OS they have. David Swafford at Facebook has been teaching Python to network engineers at NaNog conferences for awhile and does the same .. he hands out a USB stick with everything needed, but I wasn't there so I emailed him and he gave me a dropbox link for everything needed .. e.g. this talk https://www.youtube.com/watch?v=dv328WQlUQg

It's a great idea and I think the world does need a new book for pure JS.

There was a book released about 10 years ago by the guy who wrote jQuery. It started with basic JS and went all the way through to advanced features. It really helped me master JS.

Where I think that book is better then yours is that it focuses entirely on JS where as you spend a lot of time talking about http and the web works. Anyone reading your book to learn js will already know that.

An updated version for the modern day of the book I mentioned earlier would do very well.

I don't mean to sound negative and I applaud your effort and the time you put in to do it and wish you the best of luck!

I definitely wouldn't assume that a JS newbie knows the http fundamentals. That definitely wasn't the case for me when I started learning. You can get a lot done on the web without really understanding what you're doing.

Maybe but it makes this book only good for true newbies. There's plenty of tutorials for complete newbs but no good book for people who want to master modern pure JS

I assume a book titled "X from scratch" requires no previous knowledge for the intended audience. It's hard to talk about writing apis without knowing the difference between POST and GET

Was that John Resig's 'Pro Javascript Techniques'?

It might be too much to ask, but I really liked how the KnockoutJS tutorial was presented http://learn.knockoutjs.com/

You basically live code to learn the basics right in a browser. It would be cool to have something like this for the book

That demo is the reason I picked knockout years ago, never regretted it either, knockout was/is amazing and they understand backwards compatibility and API stability.

I love it, very nice. Clean, modern, concise.

Are there plans for translating it in other languages? I'd love to have time to translate it to spanish, but almost no free time..

I'd be willing to help with a Spanish translation as well.

This is a great idea, thanks!

I need to figure out how this could be organized and will get back to you in a few days.

This is a great idea but ES2017 instead of ES2015 would make it even easier for newcomers. This would allow `await` which is a lot easier for newcomers to follow than callbacks or .then(). Also you really want string.includes() !

Node and all current browsers support ES2017 so you don't really lose anything either.

includes is the same as indexof, what's the big deal in your opinion?

Index of element is greater than minus one is an odd way of thinking about whether an array contains an element.

I think you have to introduce all the CS stuff more slowly. Did you learn everything you know about programming in less then five minutes ? Then how do you expect a beginner to understand any of it ? Don't get me wrong though. The content is good, but it's too dense. Reading it as a beginner will be painfully slow and boring, like reading the TCP/IP spec. just to make a HTTP request.

I skimmed it and think it looks good for a beginner and really like that it focuses on pure JS. One thing I didn't see (and, again, I admit I skimmed) was how to structure a JS project/application. I know this is targeted at beginners, but even beginners need to see structure.

If I missed all this in my skim, please forgive.

I just got home from teaching JavaScript to a room full of people who've never written a line of code in their life.

This book is missing something critical that most intros to JavaScript overlook:

How does the student set up the plumbing and run their code?

It's amazing how much of a hump this is for many trying to get started. It also amazes me how oblivious most of us programmers are to it.

"Just open Chrome Dev Tools" or "put this in a file and run Node" are really strange computer tasks to someone who has never typed and executed code.

Very true. Or things like "download and install git".

Oh wait you're on a mac you need Brew. But you're on windows? You're gonna need X. You're using linux and still don't know? (e.g. Parent installs linux on a computer for their child to learn programming on (e.g. buys them a rpi) )

Lots of "setup" stuff needs to be explained or at least guided through for a from scratch approach, but also needs to be easy to skim and skip if the person learning already knows how to do it.

Sometimes I fantasize about a platform for tutorials on "how to do X using Y if you know Z" where prerequisites would be linked wiki-style, but disambiguated for the learner. If they are on Windows and use cmd.exe as their shell, command-line examples would be adapted to that, while someone using bash on Linux would get fitting examples as well. If they already know how to do a part, they get just a short summary instead of lengthy explanations.

Unfortunately, you'd need a lot of content before something like that would take off, and just specifying a few options while otherwise relying on the reader to figure out any differences is simply easier for a writer and still good enough for most learners.

A few times I've visualised this as a tech tree like you see in some RPGs and RTS games. I'm not an artist but I'd love to try sketching this out for a few "trees" at some point.

This is a cool idea. I hope you do this and I happen upon it one day.

I probably should just start an "as yet unimplemented ideas" section in my blog.

I came here to write this exactly. This looks like a nice resource, the tone is friendly and inviting and the topics are introduced at a nice pace. Then I thought about my cousin who I've been trying to teach to program a bit. She's interested and she's smart, she understands how things work at a conceptual level and she can design an algorithm. But if I just give her some JS and ask her to run it she'll stare blankly right back at me.

The introduction needs to talk about prerequisites, setting up for following along way before getting into the topics. Right now it's just a (broken) link to the appendix, which I don't think is good enough.

I like this overall though, it's good stuff. I'm going to try and find some time for a PR to change the introduction into something I think would be better for a newbie, and if translations are welcome I might just work on a Swedish version.

> But if I just give her some JS and ask her to run it she'll stare blankly right back at me.

Exactly. I know how to program, if programming means designing an algorithm to achieve a task and returning the result...but even though I'm most of the way through my CS program, I don't know how to do a lot of the stuff necessary to make that program useful in the real world. I know I'm missing that and I'm learning on my own, but I'm really bothered there hasn't been much emphasis so far on how to deploy the program in a real-world environment and integrate it with an ecosystem of programs, such that laypeople can use it. Algorithms and programming are only a small piece of the puzzle, and a lot of people won't have senior developers to guide them.

I see there's a section on Environment Setup[1] though personally I might be tempted to just link to other tutorials instead (which the author also does, I see).

1: https://github.com/bpesquet/thejsway/blob/master/manuscript/...

> though personally I might be tempted to just link to other tutorials instead

short term, perhaps, but longer term, keeping it in one voice, and making sure those links don't change/disappear is valuable.

Which method (Chrome Dev Tools, Node, etc.) did you teach to your students? Any other online resources you recommend?

Both. Node and chrome dev tools. Mostly VS Code plus some plugins plus node. Easiest way to give them a working, comprehendable and debuggae stack.

You could start with, "type 'javascript:alert(2+2);'" in your address bar

Works in Firefox, not in Chrome (at least on MacOS).

What about



Works in both Chrome and Firefox.

Doesn't work in Chrome (edit: or Firefox for that matter) for Windows either... that's a shame. Abusing javascript: is a really useful trick for lots of little hacks.

It's also an attack vector for hacks. You can enable it on some browsers if you please, but having it off by default is sensible...

Works if you type it out. If you paste it, the "javascript:" part will be omitted.

Above works even if you paste it.

As a teacher myself I know this firsthand and I agree with you.

Unfortunately, text is not a good medium to describe actions. A text-based environment setup tutorial ("double-click on this icon", "create this file in that folder", and so on) is tedious and ultimately inefficient. A screencast is certainly a better solution there. I might create one later.

Coding online with tools like CodePen and Glitch is another quicker and simpler solution for a complete beginner. This option is described in the book appendix.

I agree. Recently started learning to code and I could see how tutorials aimed at beginners assumed I would not only know, but be familiar with stuff like terminal/console, repository, IDE, etc

Shouldn't the answer be obvious?

Every Python tutorial: type 'python' and enter commands into the REPL.

Every Ruby tutorial: type 'ruby' and enter commands into the REPL.

Every Exlixir tutorial: type 'iex' and enter commands into the REPL.

Every Perl tutorial: type 'perl' and enter commands into the REPL.

So for JavaScript: type 'node' and enter commands into the REPL.

Shouldn't the next question be obvious? - "What is a REPL?"

Also, doing things in a REPL usually pretty different.

> "Just open Chrome Dev Tools" or "put this in a file and run Node" are really strange computer tasks to someone who has never typed and executed code.

While not a perfect answer to the issue, I often tend to wonder whether or not we lost something in the transition from traditional microcomputers (Apple IIe, Commodore, TRS-80, etc) to the PC era...?

Actually, even in the early PC era, the PC booted to ROM BASIC; this was how personal microcomputers worked.

That said, in the very early history of personal computing, with machines like the Altair, IMSAI, and Sol - these machines "out of the box" (so to speak) didn't drop immediately into a ROM BASIC or "monitor"; they usually had to be "booted" off of some paper tape or other storage media hosting the boot process (I wasn't around during that period, but I wonder if that was only a part - if you then had to "bootstrap" your way up the stack to get to something useful? I know on the Altair, unless you had it set up in ROM to boot from, you had to hand-toggle some initial boot code in just to read the larger boot process from paper tape). All of this process was virtually identical to how commercial and larger systems were booted.

But the Apple changed this, and made the "personal microcomputer" accessible to the general public. Now, they could power it on, and get to a prompt of some sort. It still didn't do much, but it wasn't as arcane. All you had to do was type some stuff...and...you got something in return: A recipe filing system, a calendar, a poem, a maze, a game of some sort (Hunt the Wumpus!), etc.

This continued to be the case for (about) a couple of decades - the first real crack in this was the introduction of the Macintosh, but most people stuck with the other systems, with the Mac relegated to the desktop publishing realm mostly (at which it really excelled). Things started to really change in the late 1980s and early 90s - mainly because of the introduction of more usable versions of DOS and (later) Windows. Thus, the PC era was born.

People began to stop being creators (of software) and started to become consumers instead. Not that this was necessarily a bad thing - there were still creators of course, but this marked a split; there were now two distinct camps being formed.

With this, though, began the difficulty in teaching programming - if you didn't know how to get to the interpreter or compiler, you would have a difficult time learning.

So here we are today. Fortunately, the answer seems to be coming from the web: There are more than a few sites out there that let you examine, edit, and run code all from your browser, for more languages than you might have thought existed (and new ones are added constantly). It isn't the same as it was (from when I was a kid), but maybe in a way it is better: Help - whether from others or from some other resource, is just a few clicks away (no longer do you have to thumb thru magazines or books trying to formulate an answer)...

I disagree with the "People began to stop being [creators/hacker]" part - the existing people didn't change, the market OPENED UP to allow people who were not hackers and computer experts to be computer users. This is a good thing; otherwise computers would have remained a niche hobby like ham radio or woodcarving.

You're right that the average computer owner is not as savvy about the internals as before, but that's just because the pool of computer owners has expanded so much, on account of the simpler and consistent and more learnable interfaces.

Agreed. PCs scaled to billions of users. Programming knowledge scales to a much lower level, I believe there's only millions of programmers or at best tens of millions.

PC only booted into ROM BASIC if it couldn't find a floppy (or, later, hard drive) to boot from. Which was not usually the case, so most users wouldn't be familiar with ROM BASIC even when it was there.

The command prompt, I think, is still essentially programming - you issue commands, they take parameters and produce results. Batch files / shell scripts are outright programs, and any moderately advanced DOS user would have to deal with them.

NodeJS could do with offering a simple UI-based runtime, like a stripped version of Atom or VS Code, preconfigured to just run whatever's on screen.

I think that the best book ever about JS for everyone, especially for those starting from scratch is https://github.com/getify/You-Dont-Know-JS you simply don't need anything else

Completely agree, YDKJS is a great book for learning the language. In my opinion though, it's not the best book for how to practically use JS in the real world. It would be a great supplement for those looking to learn more about language details with the book the OP posted.

You can only learn how to practically use the language by...practicing it in the real world. No book can teach you that because the real world is too complex.

Disagree.. A book could easily show you some basics for project/directory structure, basic code organization, documentation, simple defaults that can really make life easier for a noob. With that he can get used to it and compare code he has to work, or is reading, with what he has already been taught.

I think it's undeniable that we spend most of our time by debugging and fixing the existing code structure, bugs, defects and sometimes adding new features. I highly doubt of existence of a book that can teach how to effectively do that. It's a luxury and real pleasure if you are asked to create the project from scratch in a real job.

Very, very nice. I briefly went over some chapters and I especially admire the 'no framework' approach you've taken. I believe there's a real need for a book like this, kudos to you for making it happen! What inspired you to create this?

Thanks for your nice comment.

I'm currently writing a blog post about this experience. Expect it soon on https://medium.com/@bpesquet.

Another great JS book on github...


This is a pretty great one, and one of the books I recommend for anyone who is learning JS.

My favorite book to recommend though is Eloquent JavaScript (also free). Just a fantastic, readable, intro to programming and JS.


Eloquent is good if your have prior programming experience. It starts easy but the 4th chapter goes quickly to a level above what I'd expect a beginner to understand without some exposure to programming or general CS theory. The exercises include a recursive list and recursive deep comparison.

I love the async book in that series. Really opened my eyes about Promises.

If you ask me all that you need to know about modern JavaScript is that it exists mainly to sell online learning material.

But I may be a bitter old man and your resource looks pretty good.

Saw this on Reddit last night, poked around on a few pages. It's great! Love the movie list example on this page: https://github.com/bpesquet/thejsway/blob/master/manuscript/.... Going from "for" loops into map/filter/reduce concepts is an excellent way to teach!

This is great!

I am fairly familiar with programming having done both AS, Lingo and PHP I understand code when I see it. I am however not a programmer but more a technically oriented product designer and so I don't get to practice as often.

I have been trying to get into javascript and while I understand all the fundamentals it's still not something that I feel comfortable doing which is a shame as it's kind of the language of the internet.

Skimming through this books it looks like the perfect way for me to spend my next two weeks of vacation so thank you so much.

Is there a way to to donate to you?

Having made something as comprehensive as this you need to think about how to break it up so that you keep users engaged and so that you cam maximise your revenue. Selling books is mostly a spike and then long slow ramp towards halt so make sure you keep your content alive.

If I may come with two suggestions.

1. Make a forum for your readers perhaps in the form of an online reading group so that you have someone to go through the book with.

2. Make a step by step email course where you go through the book and have people turn in assignments perhaps even in forums.

3. Let people hire you as a private teacher perhaps build up . a network of private teachers. (Ok that was three suggestions)

These I think would be great ways to monetize.

Thanks for your nice comment and for these suggestions.

You can support my work by buying the ebook version on Leanpub: https://leanpub.com/thejsway.

Monetization is not my #1 priority right now, but that might change later ;)

What all these tutorials omit is the tradeoffs JavaScript and node incur in order to be simple and friendly.

- In JavaScript: no type annotations, numbers are floating point numbers, garbage collected, no multi-threading in the language spec. There are some ways to workaround these limitations, but they're not a part of the language.

- The concurrency model of node, based on libuv event loop. This dictates what node is good for and what is not good for. Short lived tasks = good. Long lived tasks = bad (service degradation + cascading failures bad)

I love the tl;dr section. It's basically what I have do when reading books, in order to recall the essential information without having to read the entire chapter again. Well played.

Should one learn ES2015 before learning ES5? Is there any value or need to learn ES5 if you're not maintaining an old codebase?

It's the same language. ES2015 is just syntax "sugar" for doing the same thing, it's mostly opinionated and for convenience. So I suggest both looking at the old style and the new style and write your code in a way that make most sense to you! Then when you join a company, there will be style guides and "linters" to enforce it. But if you have to choose, start with the old style because that's how JavaScript have been looking like for 15 years and a lot of code looks like that. Also I'm not a big fan of "trans-pilers".

If they are writing in Node, I'd say there's no need to learn ES5 as they should be using a node version with LTS. If they are writing JS in the browser? Then yes, they should learn ES5 as it's quite likely they will be debugging transpiled code at some point.

Not all browsers support ES2015 so knowing ES5 first is helpful.

All current browsers support ES2017.

If supporting IE or out of date mobile devices is worth your time (it might be, it might not be - consider CSS grid won't work, flexbox won't work, webcrypto won't work, HTML5 clipboard won't work, and you'll need double the time to deal with them and their awful devtools) transpiling is a good option.

Except on almost any serious project you should be using a transpiler anyways.

Agreed, but I find it helpful to understand the transpiled code. The "clean" ES5 output was a large reason for using TypeScript https://blog.asana.com/2014/11/asana-switching-typescript/

I agree to an extent, but any modern transpired should also emit source maps which should shield most people from needing to look st or understand the "low level" generated code.


It converts your ES6 code into Javascript that can run on all browsers. It's how you can get advanced Javascript features before the browsers fully implement them. Look up Babel.

Converts modern JavaScript to ES5

It is a portmanteau of translater + compiler

Looks great. I love modern JS, and the faster everyone can move on, the better!

I didn't see any async/await stuff though, is there a reason for that? I'd imagine it would make some code much easier to follow.

If OP wrote using ES2015 then it wouldn't be included, async is defined in 2017

> and the faster everyone can move on, the better!

Why? Where does this mindset come from?

Direct style is easier to reason about. Control passes onto the next line consistently, for both async and sync operations.

Do you really prefer callbacks or just use them because they were once necessary? Are they so good you'd use them for sync operations too?

   add(a, b, function(sum){
Personally: that seems like a waste of time. I'd rather just do:

  var sum = a + b;
Likewise I'd rather do:

  var response = await superagent.get('https://...')

Why would you want to use callbacks?

Here's a code example from an npm package I was looking at, vs how I would rewrite it in modern JS:


Some of it may be preference but a lot of it is objectively simpler to reason about.

I don't understand why anyone would choose to make things unnecessarily complex.

Didn't know "var" was outdated. Good stuff, thanks!

You can technically still use var if you wish, but I'm not sure of any reasons to do so.

When switching to let/const, bear in mind the difference in scope:

var is function-scoped:

    (function () {
      var x = 1;

    var x === undefined
let/const are block-scoped:

    if (true) {
      var x = 1;
      let y = 1;
      const z = 1;
    x === 1
    y === undefined
    z === undefined

I find function lexical scope more natural for JavaScript which is very function orientated, where you pass functions around and use closures a lot. I also find it a PITA having to declare variables before the block, instead of where they are first used. Ex:

if(..) { ... huge block of code .. var foo = 1; }

Means I do not have to scroll back and forth to declare and set the variables at different places.

That's probably because you're a more experienced Javascript developer and happen to know about it - and have experienced the pitfalls already. Most people, including myself (and I'm a fairly experienced JS developer myself) find block scoping to make more sense. Less prone to bugs and whatnot too.

In strict mode JS runtimes will hoist the `var` declaration to the top of the declared scope anyway. So `foo` would be declared at the start of the containing function scope, regardless of where you appear to declare them.

That is not specific to strict mode, in fact. It will always be hoisted.

What I think he means is that if you "use strict" you will get an error if you reference a undeclared variable, but due to the hoisting you will not get an error if you use a variable before it has been declared - if it's declared later in the scope. But if you use let, you will get an error! Such errors are trivial to detect even for beginners though ... Something more nasty is when you have an undeclared (undefined), maybe misspelled object property, then neither "use strict" block scope, or even const will help. It's also hard to find such bugs via static analysis, Typescript nor Eslint will detect it! This is a feature in JavaScript though, and has nothing to do (but often confused) with block scope vs function scope, or loose type vs strict types. In other languages you would need several lines of boilerplate just to do something like "foo.bar=1", and I think the convenience outweigh the possible hard to debug errors, and I'm also working on a static analysis tool that will detect some of those errors.

The only reason I can think of is if you want hoisting for some reason. For example, if you want to call functions before they are declared. Personally, I don't like that style, but some people do.

Function declarations work like this

  typeof myFn === 'function'; // true
  function myFn() { }

let / const are both hoisted though, they're just hoisted to the top of the current block scope instead of function scope.

From the MDN docs:

"In ECMAScript 2015, let bindings are not subject to Variable Hoisting, which means that let declarations do not move to the top of the current execution context."


Sort of, but the effect is very different due to the "temporal dead zone." Attempting to access a variable declared with `let/const` or const before the declaration will throw an error, vs just getting `undefined` for a variable declared with `var`.

I'm a bit confused. What does "hoisted" mean in this context if accessing the variable before declaration will throw an error?

This is incredible.

GF wants to learn to program, she has a strong math/finance background and I think she'd be good at programming but the web can be a bit overwhelming in totality.

I went over a few chapters this afternoon and really enjoyed what you've put together. I'll definitely recommend it to friends who ask me about learning to code.

This is really good! And I like the dig at 9gag :)

this looks promising. I like how it teaches the concepts using plain Javascript without focusing on a tool or library. Kudos.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact