So, I literally teach all of this, and I think the biggest thing to get people to understand is that -- the stack you use right now is a product of evolution, not intelligent design.<p>It's a minimum of THREE languages to get anything going using the presently most popular programming language; and that includes the stupid fights over whether all three of those are ACKSHUALLY languages.<p>The environment feels almost hostile to onboarding by design, so you have to STRONGLY distinguish theory from practice.
The new approach in mind is how many of us who learned basics of programming as kids have done it, or learned anything at all. Makes sense to me.<p>Learning immediately about for loops, functions, variables, parameters, and any other concept you might consider basic, is putting a mountain of abstraction in front of someone that most are not prepared for.<p>As such i think within the context of your web course that new approach is going to make it a lot easier to get started. And I’m sure there are plenty of places for hooks for those students that want to go deeper :)
I've been teaching web dev for ~10 years, I learned early on that with JavaScript, the programming fundamentals need to be introduced in bits and pieces. The class hits a wall otherwise. As much as I would like to focus on programming fundamentals first, a class of adults needs to know and get hands-on experience with the <i>why</i> asap to keep them engaged. So I introduce some DOM basics early like the author outlined (except for the last two items).<p>It also really depends on the profile of the students themselves. I teach at a coding bootcamp now where we also have short courses on just front end web development. The bootcampers are typically more amenable to a front-heavy, bottom-up, fundamentals-first approach. The short-course students need more hand-holding.
Fundamentally, this stuff takes a certain shape of brain to get. Either it clicks, or it doesn't (not that it can't take a good while to click). I have seen the specific thing that most people won't get inaccurately described as 'variable assignment', I think it's more about looping, but either way, you can do it or you can't.<p>You always read about someone who's trying a new method of easing students into it, confused why everybody else puts stupidly hard concepts up front. Then, later, they post about their rather high failure rate, and possibly lament that there are not enough battle-tested educational resources that are designed for this tack and that's why they failed.<p>What's really going on is that when you put something 'hard' up front, the class self-separates into people who get it, people who think they can get it but don't yet, and people who are not going to get it, and the latter group quits.<p>Being able to code is a lot like a Hogwarts letter: there is a lot of learning to do, there is a lot of variation in ability, you cannot do much without being taught, but there is also a baseline of being able to do it at all which most people fall short of. If you wind up with a class that cannot necessarily all do magic, the earlier you say 'now, let's all make some magic sparks', the more you have time to teach the students who can.
Teaching Javascript as part of a core curriculum (i.e. a course everybody has to take) would be a lost cause, because the syntax makes it completely unapproachable.<p>And that's before you have to explain how some interactive functionality exists in plain HTML/CSS (accordions, hover states, animations), but in order to attach them to button clicks, you suddenly need a programming language with a largely unforgiving syntax (an errant comma after the final object property) and behaviours (event.preventDefault).<p>And if you manage to wade through all that, and are ready to build a modern program, you would then be told to learn about React, the shadow DOM and server-side JS, another 3 things that don't look like anything you previously learned.
I’m very much teaching the same thing - an eight week introduction to JS (after 6 weeks of HTML/CSS).<p>My approach was to lead with one week of unplugged programming just introducing the concepts of CS. Then introducing the fundamentals of variables loops etc using a block based language.<p>The following week we transition to JS doing one week of fundamentals and after that moving on the DOM and events.<p>So far I think it has worked out pretty well. A key part is to work both bottom up and top down at the same time until things eventually click.
Why not Logo as a first introduction to programming? Why muddy the waters with anything other than writing little programs to make a turtle draw flowers?<p>I know, it’s not web development, but it does present the broader concepts in a way that fully digestible!<p>I just don’t see how someone with no experience at all with programming can ever be expected to make an interactive web page in just 6 weeks.
JavaScript as used in the web seems tough. I wouldn't recommend trying to teach the DOM internals.<p>IMO an intro course is about fundamentals--loops, functions, parameters, etc. Everything else is just obscuring what is important.<p>It's unfortunate that webdev, undoubtedly the most popular development today, is also the most obtuse.
They should teach one thing to solve in JavaScript (cannot be done in css, useful without impacting accessibility).<p>Code must pass jslint.com with no warnings. And all the things used like loops and branching should be explained with a few examples.<p>And you don’t tell them about the other ways to do the same thing. You tell them the one way that uses spaces, double quotes, i+1 and === (they’ll find out about all the wrong ways on their own later). And obviously no Dom shenanigans in these initial lessons.<p>People must solve something and understand how they did it so they feel good. It’s very easy to teach and nobody does it like this. So people get scared and want typing and OO classes for their <i>this.JavaScript</i> later.
People learn differently so I won’t pretend my method of learning is the Best Way but for me I learn best “on the fly”. I learn best when I have a task I want to accomplish and I learn enough to take the next step, then the next step, then the next. I’m fine taking “breaks” to learn new concepts as they are needed but I need to see incremental progress to keep up my “steam”.<p>At least when I’m doing something completely new. If I’m doing something I’ve done many times I can write the entire front and backend and not see real results until the very end but if any part is new then it’s imperative that I get something basic working and iterate on that.<p>When I’ve been asked “how did you learn programming”/“how should I learn programming” all I can give is what worked for me. My first foray into programming was my TI-84 SE calculator, mostly so I could make “games”. Then a Java course in HS and then my real explosion in programming: learning PHP on my own. You have to have a goal/desire to propel you forward. With my calculator it was making games, with the Java course the addition of so many control structures (vs TI BASIC) was mind blowing, then with PHP it was the ability to create something that anyone could see anywhere in the world (with an internet connection). But with PHP (and later JS) my learning was in fits and starts as I needed to learn more to accomplish bigger/better things.<p>So my advice on learning a language is simple. Have a goal of some piece of software you want to make and take baby steps towards that learning what you need in the moment to get a tiny step closer. Yes, you will write shit code. Yes, you will probably rewrite or want to rewrite code as you learn more. Yes, your early attempts will seem childish in retrospect. None of that actually matters though, this is about learning, not creating something with 10 9’s of uptime that runs flawlessly.<p>The method of teaching all the concepts up front has never worked well for me. A short explanation and examples of how something can be used is powerful since even if I don’t need or understand it today I will remember that it’s possible and come back to it later when it solves a problem I actually have. Nowadays I do at least scan through docs on languages/frameworks/libraries. Not to absorb every bit but to “prime my index” for later. However none of that would have interesting or compelling to me when I first started programming, I had to see something come alive and iterate on that instead.<p>I still remember the first time I got PHP to spit out “Hello, Josh” and “Josh” was nowhere in the code, instead it came from a GET param. Pure magic. Yes it was stupid simple but that drove me to learn more, to learn about POST, to learn about cookies (you can store stuff!?), to learn about databases (holy shit you can store more stuff! And it can be private!), to sessions, and more. It all started with a GET param and that sense of wonder/magic/excitement.