As you might or might not know, I’ve expressed my frustration with the sad state of JavaScript tutorials in the past. Since the universe has not seen fit to fix this problem on its own, I’m finally at the point where I’m working up an actual TOC.
Attention conservation notice: over 900 words collecting some thoughts about a JavaScript book / tutorial for non-programmers.
- There are a tremendous number of people who know at least some HTML and CSS, but who don’t know any programming languages per se.
- Included in that count are people who know at some HTML and CSS, and a smattering of jQuery. This is not a knock on jQuery — quite the contrary, I actually think it’s very impressive that jQuery enables non-programmers to sprinkle in UI effects, etc.
- Still, those who know a smattering of jQuery would also be well-served if they understood JavaScript-the-language.
- Oddly, although JavaScript seems like it would be a natural next language for people who know HTML and CSS, there isn’t a single JavaScript tutorial out there for non-programmers.
- Or at least, there isn’t one that’s any good. As previously discussed, searching for JavaScript tutorials brings up a wasteland of confusing, outdated, incorrect crap.
- It’s actually worse than the situation for HTML, where if you look hard enough, you can find something possibly worth reading.
- Thus, the actual path people follow is: learn HTML and CSS, learn Ruby, PHP, or Python, and then go back and learn JavaScript.
- For experienced programmers, good JavaScript resources exist, if you know where to find them.
- But a lot of what people throw out as introductory resources (MDN, Eloquent JavaScript, The Good Parts) are really introductory resources for programmers.
- Eloquent JavaScript is the closest thing I know of that kinda sorta works for non-programmers. It’s very well written and covers lots of critical topics. I really, really like it.
- The wrinkle is that it’s still too complicated. Chapters 1 and 2 work for non-programmers, but after that the book quickly veers off into functional programming geekery and other advanced topics. I feel safe recommending Eloquent JavaScript to programmers, and possibly science or engineering majors with little or no programming experience, but I just don’t think it works as an introduction to programming itself.
- Writing a guide that teaches non-programmers how to program is tricky, but not impossible. Some people do it brilliantly.
- What the world probably needs is a Learn JavaScript the Hard Way. But Zed Shaw hasn’t written that book yet, and I’m not sure if he cares to.
- In any case, a hypothetical Learn JavaScript the Hard Way couldn’t be a straight port of Learn Python the Hard Way, for reasons mentioned below…
- Problem 1: Printing. Unlike just about every language you can think of, JavaScript in the browser does not have a dead-simple way to write text to the screen. And without a dead-simple way to write text to the screen, it’s awfully hard to get started.
- There’s
alert()— um, no. - There’s
document.write()— also, um, no. Any guide that trains newbies to usealert()ordocument.write()should be set on fire. - There’s
console.log()— better, but I’m not keen on explaining to people that they have to open some inspector or console to see what’s happening. And people who know HTML and CSS really want to be manipulating the page. - Or, you could ask people to install Node.js. Node.js is great for backend programmers who want to learn JavaScript — particularly because it decouples JavaScript from the DOM. But it’s nice to not have to ask people to install software to get going. More importantly than that, I think people who know HTML and CSS want to be mucking around with the DOM. That’s the touchpoint between programming and what they already know.
- Eloquent JavaScript cleverly works around this whole “print” mess by, well, providing a damn print function.
- In any case, I think there is a way to bootstrap around this. It means we won’t be starting with “Hello World.” Or even, “HELLOSKI.”
- Problem 2: The most interesting early concept to teach is event listeners. That’s a huge part of why client side JavaScript exists, and it has everything to do with why an HTML/CSS jockey would want to branch out into JavaScript.
- But this is not simple. You need to know what a function is — this is a mind blowing concept for non-programmers. You need to know what a callback is!
- Most JavaScript tutorials teach event listeners using the
onclickattribute. Partly this is because most JavaScript tutorials were written in 1997 and are total dogshit. But partly this is because usingonclickshort-circuits the problem of having to grab the element and then attach the listener: complexity is reduced. - In a Python or Ruby tutorial, you have the luxury of discussing fundamentals like primitive types, etc. before eventually working their way up to callbacks.
- I don’t think this traditional approach cuts it when it comes to client-side JavaScript. I think the reader wants to learn how to click a button and have some interesting stuff happen, ASAP. Then you can start sneaking in numbers, string manipulation, booleans, loops, and so on.
- I think there is a straight line from zero to event listeners that cuts out most of the fat. But I’ll need to try it on some real readers to see if it works.
Nice post!
Looks like the link to HELLOSKI is not correct.
https://www.goer.org/2010/05/Should be. helloski.html
For decades, my standard HELOSKI string has been “Hello, sailor!”.
This is because I’m pretending that the computer had as much fun parsing the data files of old INFOCOM games as much as I had playing them, and the computer and I are sharing an old, obscure reference, and thumbing our noses at commandment #12594.
I haven’t written for beginners for a long time, and I’m not up on my modern JavaScript (I was barely up on 1997 JavaScript). But this will not stop me from writing a long-winded comment.
When writing for beginners, I’ve found there is usually a tradeoff:
– Teaching the best practices of experienced programmers from day 1.
– Using possibly bad practices as part of an extremely gentle introduction, and then correcting those practices as the tutorial goes on, as soon as is feasible.
The problem with #1 is that often teaching really beginning programming AND best practices can be an awful lot of stuff to ingest, and you run the significant risk of confusing and/or driving off true beginners with too much detail.
The problem with #2 is of course that the bad practices are bad, and if your beginning reader doesn’t get far enough into the tutorial or skips around they won’t learn not to use the bad practices. Also experienced programmers tend to get VERY OFFENDED if you use bad things for teaching at all, and say mean things on the internet.
I have always written with philosophy #2, on the theory the less I can do to discourage beginners the better.
Obviously the ideal is to teach good practices without being overwhelming at the start, which is usually very, very difficult. Your output/printing example is a clear example of this ? as you describe, without a really simple way of printing really simple output, it is hard to get started.
This is my long way of saying I don’t see anything wrong with alert() for bootstrapping beginners on very, very basic code, but moving away from it as soon as possible and explaining precisely why it is bad once you do move on.
I do really like how Eloquent JavaScript has the “display in console” interactive boxes, although typing code code in the right side of the console isn’t working for me. I’ve found from watching beginners that interactive consoles work really well, as long as they work reliably and have reasonable feedback for errors (a hard problem).
Another way I’ve seen to cover this is to provide a fairly complete and complex sample using best practices at the very beginning, but to focus on very tiny parts of that sample at the start and expand the user’s knowledge of the parts of that sample over the course of the tutorial. This also seems to work reasonably well, depending on the size and complexity of the sample.
One thing I personally dislike is to have boilerplate framework code and to say “copy and paste these new lines into the existing code, there, now you’ve learned about X.” Copy and paste is not learning (IMHO).
Dodo — Oops! I’ll fix the bad link when I next log in. 🙂
Laura — Great explanation of the tradeoffs. I’m not so concerned about experienced programmers saying mean things on the Internet. But I do worry about the bad practices sticking in the reader’s mind.
This problem strikes me as analogous to writing English prose: the English language provides constructs that enable you to trade local sentence clarity for overall paragraph cohesion (or vice versa).
Using an interactive console is a great way to go. I thought long and hard about using a magic console widget, or just getting the reader to install Node.js and use the REPL. That solves a ton of problems. But instead, I’d rather try to keep things in the browser and stick with common, native constructs.
Don’t worry. I can’t do Hello World, at least in Lesson 1. But I do have A Plan.**
** and not like the Cylons, who didn’t actually have one.
It’s why non-programmers can learn jquery faster. Ya, selectors, callbacks and events are complicated.
But…
$(“#calendar .next-button”).click(function(){
$(“#calendar”).css({
left: ‘200px’
});
return false;
});
Has issues, but looks not bad if you know CSS.
JS tutorials need to start with the simple kind of things that people find snippets for.
The codecademy team is doing a good job, but I think you need to attack the DOM sooner, rather than later.
I agree, Rob.
I think that what many people end up doing is that they take a small jQuery snippet like the one you included, throw it on their page… and then sometime later they go back and manage to reason through how it works. Even though it has scary callbacks and other programmer-y things in it.
I’m debating whether it makes more sense to start totally bottom up (this is a literal, this is a variable, this is a function, …) or to do what you and Laura are getting at — start with a interesting snippet and work backwards. I was thinking the former, but I’m kind of leaning towards the latter right now.
Excellent! You’re writing another book.
I personally found it extremely tough to learn JS as a non-programmer. I found the terminology confusing and it felt, at times, that this was almost intended in a way. Callbacks, event bubbling, sugar methods, implementations, etc – very difficult indeed to get my head around.
Understanding what a piece of code was actually doing I didn’t find so hard, strangely. The language and terminology describing it, I did find a bit obstructive.
‘Plain English’ explanations of these confusing terms are needed for non-programmers (its certainly what I needed). Thankfully, I found a bit more of this in the excellent videos on YUITheatre, especially the Douglas Crockford series.
Good luck with your new book Evan!
Thank you, Tocacar! 🙂
i think there must be some other way of teaching.
the biggest problem in my opinion is getting the info to stick.
you can only read a beginner book so many times and then saying f**k it.
all i know is that most books that teach a programming language teach it the same way.
also stop wasting everybodys time with the history of the language its just paper filler.
if you have talk about the history then make little comments.