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!
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.
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.
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
The book is written using Leanpub's markdown syntactic sugar it seems.
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
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!
You basically live code to learn the basics right in a browser. It would be cool to have something like this for the book
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..
Node and all current browsers support ES2017 so you don't really lose anything either.
If I missed all this in my skim, please forgive.
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.
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.
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.
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.
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.
1: https://github.com/bpesquet/thejsway/blob/master/manuscript/...
short term, perhaps, but longer term, keeping it in one voice, and making sure those links don't change/disappear is valuable.
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.
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.
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)...
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.
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'm currently writing a blog post about this experience. Expect it soon on https://medium.com/@bpesquet.
My favorite book to recommend though is Eloquent JavaScript (also free). Just a fantastic, readable, intro to programming and JS.
But I may be a bitter old man and your resource looks pretty good.
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.
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 ;)
- 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)
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 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.
Why? Where does this mindset come from?
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://...')Here's a code example from an npm package I was looking at, vs how I would rewrite it in modern JS:
https://gist.github.com/scf4/8157abd755eb9c232e87dcc342b78b4...
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.
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 === undefinedif(..) { ... 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.
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.