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.
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.
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'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
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.
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.
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.
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.
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).
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.
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
> "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.
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?
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.
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!
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)
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.
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.
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.
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.
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.
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.
"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`.
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.
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!