...and this is where it goes off the rails; teaching JS before HTML is how we will continue to have the ridiculous proliferation of app-sites that shouldn't require a single line of JS instead needing the latest version of $browser (you have a choice of browser - pick one ...) to even show any content at all. Forms don't need any JS to work, yet the impression this gives to beginners is that they do.
But then again, this is Microsoft, which is now firmly in bed with Google in contributing to the Big Browser monopoly, so I suppose I shouldn't have expected anything else. The agenda is obvious to anyone who cares to look.
> The agenda is obvious to anyone who cares to look.
Alternatively: it's just teaching whatever is popular in the industry, for better or worse (similarly to how DevOps people would be taught Kubernetes, even if it can be horrible in certain cases and for smaller projects).
Many sites out there don't need JS. Server side rendering would suffice. And many other sites out there would be well served with minimal JS for enriching a few forms.
Yet, that's not the reality that we live in. The reality is that the majority of the developers out there will simply have to deal with lots of JavaScript, TypeScript and frameworks like Vue, React, Angular (i'm using the term "framework" here because they change the entire direction of the development of your front end, not that it matters at all).
So, that's what curriculums will focus on, since clearly people want to have good employment prospects. It doesn't seem like the linked one gets too caught up with the frameworks, though.
I teach that kind of stuff at university — I would never think about teaching JS before HTML and CSS. Students should understand what ia possible with HTML and CSS alone. Then we look at the server side, and understand infrastructure and how servers can potentially deliver different HTML and CSS depending on the request and then we start introducing JS as a means to replace serverside stuff, to enrich HTNL and CSS or to interact with REST APIs without reloading the page etc.
But understanding the infrastructure is key here. Understanding the "M" in HTML, understanding the "C" in CSS, understanding http etc.
I am trying to finally learn what's going on in the web browser and my biggest hurdle has been CSS. I can read & write rules but the questions are really, which rules and under what circumstances? That plus the different layouts (grid, FlexBox, etc. -- terminology almost certainly wrong, sorry!). Can you please recommend a good resource for learning CSS & layouts?
Come on now! You must be overcomplicating things if you are having challenges digesting CSS. Cascading Style Sheets are probably the easiest thing to comprehend on the frontend.
Team Treehouse is a great resource for learning frontend and backend stuff.
But to master JS tools you want rock solid fundamentals and know about default behavior, writing clean HTML and CSS. I even teach more about networking and HTTP than JS. They actually want to know: what happens when I type an url into the browser?
While I agree with you that knowing the basics is obviously helpful and desired, in the end what gets you your first job isn't "what happens when I type a URL into the browser".
What gets you your first job is you knowing how to use the tools that the companies already use to ship software solutions on the web. If they use react, webpack, graphql, then your best bet at getting your first job is learning enough about those to be productive in a couple of days at the company, and not what happens after you hit enter in the URL bar.
95% of my work as a regular web/mobile dev was about being able to fetch some data, massage it, display it, then handle user interactions to send something back to the server. Some software dev jobs are more complicated than that, but to be honest, most of what we do it not rocket science.
Once you get your first job, you can work "backwards", and learn the basics. This approach also helps you learn what is important as you see it firsthand that it's important. Your team is there to help you learn, you earn money in the process, you make your customers' life easier, and you build your portfolio and gain experience to get your next job (that will hopefully be more challenging than a CRUD app).
I'm not saying that it's great that you learn the tools before the basics, I'm just saying it makes sense if you want to get a job and pay your bills (and set yourself up for long term success as you learn on someone else's dime.
Have we misunderstood each other? I'm talking about teaching web fundamentals to absolute beginners, not people who are already programmers or CS graduates. In terms of content think starting with something of this scope: https://developer.mozilla.org/en-US/docs/Learn/Getting_start... and then building on that.
The fundamentals are clearer and more accessible to teach than frameworks. This inspires confidence and I'm pretty sure you won't save any time if you jump ahead and teach React and especially Graphql. You have a _way_ better foundation to learn and use React if you know HTML, CSS, JS, HTTP that I mentioned but also browser dev tools and I would even put git before that. Also people who are already professionals in some field close to web dev will ask fundamental questions, they want to understand things.
Learning framework X is a piece of cake if you at least roughly understand how it works and aren't on completely shaky grounds, and when framework Y comes along you can ask the right questions right away.
The _vast_ majority of web development doesn't use React or Graphql anyway. I don't even know a single dev who knows React and Graphql but cannot make a website without them or doesn't know what DNS is, what common HTTP headers mean or don't know how to center a div.
I have worked with people who are "fullstack" with Javascript + Typescript, but do not even know what a CPU core is.
Some are even amazed that a basic HTML page can be created with a plain text editor.
Such people are "ReactJS" specialists, not even Javascript/Typescript specialists. One cannot easily engage in a conversation on types with them - not that they are negative or close-minded, but such concepts are in the "unknown unknowns" for them.
Nope. Knowing the fundamentals does not take all that very long and can in fact go a long way in enabling someone to pick up newer technology.
> I have worked with people who are "fullstack" with Javascript + Typescript, but do not even know what a CPU core is.
Now, this is the opposite of the point that you're making, but i have to admit that it's pretty cool on some morbid level! The fact that we have abstractions that are strong enough for them not to leak and make people dig into the details (e.g. the JS event loop being all that they need to think about).
That's also why tens of millions of people out there can work with spreadsheets of text processing software without knowing what a compiler or interpreter is, or even caring much about the benefits of dynamic linking vs static linking.
Similarly, i can write SQL against a DB without knowing anything about the RUM conjecture or really much about anything apart from the very basics of ACID (at least before Oracle fails to plan queries correctly and needs either statistics to be regenerated or hints added for the optimizer, because it's an evil piece of software).
It just works. I'd argue that it's the way things should be - working on the JVM should absolve one from thinking about compile targets and worrying about things like whether the CPU is from Intel or AMD, or what the ASM format is or whatever. Working in the browser might as well absolve one from worrying about most platform minutea as well, otherwise nothing would get done.
Is is still nice to have a bit of curiosity and explore those things, there being some merit to that, which might as well not be immediately apparent? Sure! Is it required for those people to truly be specialists in their own niche and to be safe from people making fun of their other shortcomings online? Absolutely not!
This view that you don’t need JS and can do most things natively is tired and screams of old timers trying to cling on to the past, when web pages didn’t have rich user interactions and good UX. Sure, you can build forms that perform full page refreshes, but ajax requests offer a better user experience.
Native dropdowns have much (much!) better UX and accessibility than most custom dropdowns built with JavaScript. Same goes for native form validation. And there are many more examples. Using JavaScript does not necessarily improve UX.
Use the platform where it makes sense. Extend it with JavaScript where needed. Make it work for everybody and make it better for capable browsers. That is called progressive enhancement. OP did not say that you may never use JavaScript. Just be mindful about it when you do.
When someone has just barely crossed the "hello world" stage, I don't think they should be thinking about asynchronous XHR requests, or be pulling up user experience research to find the optimal shade of red for making input validation errors appear less aggressive to middle aged women with a bachelor degree in communications who are part-time employed in marketing.
Let's start with getting data from the form to your back-end, and once we've got those must-have basics down, then we can start introducing the nice-to-have bits.
I consistently have a more pleasant time with the well-designed, minimal JS websites (which are now a rarity) than even the better designed websites which heavily use JS. And my job is allegedly to 'improve' the internet with more JS.
Please could you inform me how you would build a form that creates, lets say a secondary loan for a company with attached assets. The assets could be zero, or many.
How would you create this form without Javascript? Would you require a user to create the assets before the loan?
Saying that HTML provides everything a developer needs to provide an application to client is so ridiculous, I have no idea why this sentiment is so popular. the vitriol expressed for front end devs from the community seems out of place.
Forms work without JS for the most basic baby forms. the moment you go enterprise, more is needed. which is where JS steps in, What am I missing here?
You would make multiple form, and track state on the server side (user createdvempty/wip loan, user added assets, user reviewed and confirm loan). Probably share state between client and server via a session token (cookie). Optionally share some state via REST - eg loan ID and asset IDs in path).
That said - complex forms is a typical example of when you might want to move from a web "page" to an "app".
Share state? I disagree heavily. There is no reason for the backend to know how many assets a user is trying to add to a loan, or delete, or accidentally load, or add but realize mid-way that it doesn't apply.
Do you belive the backend should know about human incorrect input and track state?
What if a cat steps on a keyboard? every addition to a form is a page reload and a query to the server. then the server sends a response.
Which is exactly the bloat everyone seems to go on about.
Im sorry but living in a world of enterprise apps, the sentiment that JS is a poor language and a bad choice is both out of place and highly de-coupled from real-world usage.
You need to share state. You might only store finished loan applications server side, but often it's nice to allow a user to pick up where they left off. Or keep a list of started, not finished applications, to hand over to sales. Etc.
But sure, application state might not go in the same db/schema as completed transactions.
Well, if you want to allow users to resume sessions from desktop on laptop/phone/tablet - you need to store state somewhere else.
But there are different levels of state: completed transactions (application finished and submitted), partial business logic transactions (three out of five steps completed) and "app state" (field 6 of form 4 partially filled in etc).
They can all be kept diffently in sync (in sync, because the browser will keep partial state via native widgets if nothing else). Even w3m keeps track of inputs in forms before submission.
Seems we are having a different discussion now about shared state instead of whether JS is necessary and capable.
Over used. definitely.
Obsolete and to be derided at every turn. absolutely not.
The initial question (how would you create a form for handling creating multiple dependent resources without using js) - is inherently about various types of state - and if/how to share them between the client and the server.
As I mentioned, I think complex business flows like these can be a great reason to go from "web page" to "web app" - precisely because it enables rich, ephemeral client state with (some) business rules close to the client.
But that doesn't mean you can't do powerful things with just html/http and some form of continuations etc on the back-end.
If you're employed, working at scale and need to do the complicated stuff, you're not a beginner web developer anymore. At that point, you should already understand the fundamentals and start extending on top of that.
Looks like the first few lessons use Javascript to give an introduction to programming and not to web development in general. I don't see any agenda. Just teach programming on the language a web developer will happen to use later.
On a related note: I've had to help train a bunch of Java/C++ devs about web dev over the years. I've also talked to a lot of new devs. One thing I noted is that there wasn't a good resource that tried to explain the key pieces of web dev concepts, terms, and technologies, and how they fit together. So, I ended up writing a "How Web Apps Work" blog series to try to fill that gap:
I just read through your post on servers[1], as I'm currently in a similar boat (webdev working with C++ devs). I think the biggest hurdle for such developers are things like:
- statelessness of the server (REST)
- the lifecycle of a single request
- the lifecycle of a single (server-)app (microframweworks)
OOP devs unfamiliar with server development tend to pollute the app lifecycle with hidden state in some singletons that are swirling around globally. The requirement that servers should be able to parallelize request-processing is mostly an afterthought and hidden app state makes it impossible to parallelize anything.
A sequence diagram of a single request would help there a lot IMHO and a short explanation of how to keep the response times short, by doing long-running tasks in the background with message queues.
I'm an experienced backend developer but always struggled with learning modern web development.
I understand all the core well (html, CSS, JavaScript, etc.), but struggle with choosing the right high level abstraction/framework/technology for ideas I want to implement.
E.g. should I make it a single page app or not? Should I be using ES6 imports? Which build tool? Would I want React or Vue or something simpler here? Should I use SSR? NPM vs. Yarn? Do I need a CSS compiler? Maybe I should be using TypeScript? Wepback?
Basically I'm overwhelmed with choices, but struggle to find useful docs on why a lot of these tools came about, what problems they solve, tradeoffs for using them, etc.
Asking the web devs I know in person doesn't help much (“just use React for everything, it's fine").
Fullstack dev here with more experience in front-end.
I struggle too. I'll tried a lot of different things (ex : puppeteer vs cypress, react vs angular2), and I end up having my own preference.
I'll try to answer some of your questions :
- Should I use SPA ? Slower initial page loading time, but faster to load more pages. Good if typical user stay long on website and navigate multiple pages.
- Es6 import ? Use them when you can, better IDE support than require.
- Build tool ? Start with webpack, oldest tool, with more chance to find answer to your questions on stackoverflow. Although I have little experience on the others (Rollup, etc), so maybe there is one that is simpler to start with.
- React or Vue ? Idk, haven't used view, both are popular and similar, take one you prefer the syntax ?
- Something simpler ? Well, there is too much choice... Vanilla js, another cool library, low code or no code like wordpress...
- SSR ? Less API to build. Faster initial page loading. Roughly. There is quite a lot of library out there with SSR, and it is elvolving quite fast. The future is probably a mix of server and client side rendering.
- npm vs yarn ? I recently played with npm workspaces, and yarn had a feature I needed, otherwise I think sticking to npm is fine. Historically yarn became popular because it introduced .lock file before npm. Npm has since catch up.
- Css compiler ? Minifying, or compiling sass ? You can start without it. Also starter like "create react app" already do these optimizations for you.
- Typescript ? Use it ! Only exception would be your code is too simple to take advantage of typing.
If you’re a backend dev, with solid HTML/CSS and HTTP/REST fundamentals then I recommend you default to using htmx plus server side templates for HTML rendering and interactivity, plus a well documented, simple CSS framework that gives you out of the box components like bootstrap/bulma/semantic.
React/web components etc. is when you need advanced/bespoke UI widgets. If you can afford KISS then they only introduce complexity and cost.
I despise frontend development as a JavaScript/TypeScript developer. Every recruiter out there wants me to do frontend work.
It just occurred on me when I got onboarded on this team (one of the big tech), majority of them are Python developers, that they can't for the life of me, figure out a simple npm errors. These are really smart senior developers.
In the past, I've always thought "its just frontend, anyone can do it".
Then it dawned on me that my JS/TS frontend experience are actually really valuable. Now I no longer take it for granted.
I think sveltekit gets it right most of the time. yes its new tech. but I think its way better than the alternatives already.
You want a frontend server that handles auth and credentials. cleans up queries to and from the main backend server.
Then you want as low-level interaction as possible in the HTML space. HTML doesnt provide everything you need. but it gets close. JS should augment HTML, the closer you stay to HTML the better.
Sveltekit goes a long way in providing this, nextjs and all the others just threw way to much tech at the front end space.
You basically want a way to turn URL's and POST requests into GET and POST responses. SPA is mostly not great and was a sidestep in a useable web.
I recently had a conversation with an "absolute beginner" and it was a stark reminder just how much knowledge I take for granted. It really is extremely challenging to try and build up a base of knowledge starting with no prior experience, and it's great to see examples of this done right.
I find most of what I do in web dev to be trivial to the point of mind-numbing. People smarter than me from different fields try to do what I do and often have far more difficulty than I'd expect.
Job security for me until the ML engineers work out I can probably be mostly replaced by a smarter templating engine!
Modern web development is dumbed down by shared APIs abstracting most of the hard problems into patterns (arguably a good thing as there is way more consistency in web dev than infrastructure), but the concepts are still quite complex. Heck, React alone is a fairly complex piece of software that 90% of its users take completely foregranted let alone understand why it became a popular choice. Low-level front end is no joke
It's no surprise that low level frontend is infinitely more performant, accessible and easier to maintain than framework obscured nonsense of this generation.
It devolves into “here’s this really dumb thing that we deal with, oh and this stupid thing is to deal with Y” - it’s really hard to be cynical with trying to break down the layers of abstraction and how they came to be.
A bit of bikeshedding (and I'm not an educator, so take that with a grain of salt), and I guess different views on a good curriculum are to be expected, but a few things I noticed upon a skimming:
- No basic HTML "hello, world" in the beginning to hook the reader and show that they can easily make web pages. It seems that they should wade through quite a few lessons, including JS ones, before composing the most basic page (assuming no prior knowledge of that).
- The first lesson is somewhat thorough, touching an assembly language (which is nice), yet mixes together shells and terminal emulators (which seems okay for a gentle introduction, but potentially confusing).
- No historical context (at least in the first two lessons), which is common to omit, but I think it helps to learn the motivation and basic ideas behind the subject you are studying, to better understand it all.
- Accessibility is explained before HTML itself, with an HTML-based quiz. I agree it's important, and the lesson looks good, but I imagine it'd be confusing/boring/seemingly unnecessary to read before even the basics of HTML (I'd probably keep thinking of learning how to make actual pages myself). Better understanding of accessibility issues may also come with demonstrations, showing why it's important (otherwise it's probably also easy to dismiss as silly or unnecessary). The lesson also mentions the "Lighthouse" tool, I don't think it's present in Firefox by default (looks like there is an extension).
- Then there's a bunch of JS lessons, before learning to make even basic static pages.
- Then there's finally HTML introduction, but only introducing 'html' and 'body' tags, and with a lot of--likely confusing to an absolute beginner--attributes in the examples, including classes.
- CSS follows those, at which point classes are likely to make more sense.
- Then there are JS-based games and web browser extensions, while we've barely learned to make basic HTML pages (though I don't think we really did).
- Only towards the end there are HTML forms, after all the interactive JS bits.
I agree with all of these and I‘ve been teaching web development to total beginners.
The MDN guides give you a much better template. They focus more on the fundamentals, starting with HTML.
The first thing I do after a short intro and overview is writing a Hello World HTML page with them while saying something about each line.
When they open the page in their browser you can see something in their eyes, which is magical. They just made their first web page!
Also I focus much more on HTML and CSS than on JS. There’s so much to learn just with that, while JS should be used when needed, little snippets for interactivity.
Accessibility is a legal requirement for front-end development in a large number of countries around the world (including the US), so it’s good to get a baseline understanding in early.
One of my kids - 10yrs old - has been wanting to learn basic HTML and "programming". We've been going through the W3C with no trouble, and he's learning at an amazing rate.
This tutorial is way beyond anything he could approach. For example "Pedagogy" - I don't know what that means, and neither does he. Another example, from the beginning "In this section of the curriculum, you will be introduced to non project-based concepts important to becoming a professional developer."
I suspect most of this is translation issues, but given the audience (kids, newbies), this language is super intimidating.
I don't think it's a translation issue, rather I get the impression that this has been written by educationalists for educationalists. So the pedagogical section is written using the basic technical language for that field, because the assumption is that the main target audience will be familiar with those terms.
It's a bit like how I might prepare a document for colleagues and a non-technical product owner, and I need to overall contents to be clear enough (and non-technical enough) for the PO to understand, but I also want to put technical details in for my colleagues who understand jargon like "load testing" or whatever else. I don't need to simplify the section on load testing and remove that sort of jargon, because in principle it's not necessary for the PO to precisely understand those details.
So I don't think it's a translation issue, but rather it's not designed to be directly a tutorial for getting started with programming, but rather a tool for teachers to teach lessons on getting started with programming.
The meta-point is that the usage of complex words is off-putting to those trying to learn something for the first time. There's always an element of "I don't know what this is, so I can skip it" but better to keep topics simple and approachable.
This is what dictionaries are for, seriously. Instead of bending backwards to serve some supposedly alienated learners, we can look the word up. When I learn something for the first time I try to be humble and put in some effort. English is not my first language, but if we start avoiding "complex" words soon we will be communicating in grunts.
What is a 'complex word'? I'm serious. If you google 'pedagogy definition' you get an easy to understand definition. If you're not willing to google things, you aren't ready to be a web developer.
Method names alone will drop you way out of the simple english, top 1k words simplification paradigm.
> usage of complex words is off-putting to those trying to learn something for the first time.
I prefer when I'm learning something new if it treats me like an intelligent person who is ignorant of that topic. So, yes, if you want to teach me something be gentle in the language from that subject. But please assume I do know some things.
The linked document seems pretty clearly addressed to both teachers and students, which might not be a great decision. If they had an entry point dedicated only to students they could probably leave out all the places where they mention pedagogy. That said, I think it’s a bit of a stretch to criticize “pedagogy” as being a complicated term. It’s okay to occasionally need to look up something in a dictionary, especially in cases like this where it’s an incredibly precise and standard word for the concept it’s referring to. You could also find and replace all mentions of “biology” with “the study of life,” but I think using these terms are fine even if a very small portion of readers need to look it up once in the dictionary.
My meta point is, "Don't give up. Everything is learnable!"
My first real tech job was in a country and office where the working language was one I didn't speak while growing up. If I came across words at work I needed and didn't know, I looked them up or asked for clarification and learned them.
We've been using this one: https://www.w3schools.com/html/ He's had no trouble at all following along and using their tooling. I've been mostly hands-off.
I'm about to graduate him from "do it in just the browser" to using GitHub pages. That way he can have an HTML site that's "his" and start putting the pieces together.
Just so you know, W3C is the main standards body for the web; w3schools is an unaffiliated privately-run web site with an intentionally confusing name. A much better general web resource—certainly for any intermediate-or-above learning, but probably also for beginners—is MDN[0].
You may also want to consider a Droplet for his next website. He will learn about the plumbing.
That way, when ever he is filled with self-doubt and needs reaffirmation, he would be able to put things together from the ground up and regain confidence.
Just want to thank you for your kind comments, it's making me happy :) - cheers from Jen, maintainer of these repos and curriculum designer / author at Microsoft
It looks great, thank you. I think it’s great to introduce accessibility early, but wouldn’t it be a good idea to have a brief introduction to HTML before the accessibility section? Or are you supposed to read about HTML on MDN as part of section 01?
Thank you! I've scanned over web development, looks like a well thought out modern curiculum. In 2022, it is tough to pick a good path for a beginner, and I like your choices.
Its probably just me but I guess I teach web dev professionally so I might as well say that I was really excited to see something like this for free from Microsoft but confused to see so much time spent on a canvas app and backend functionality seemingly crammed into the last few sections somehow.
I guess it's fine to just have a frontend curriculum but just confused at why this is noteworthy maybe.
Im sure this is a big deal for some reason and Im just too dumb to realize why. I honestly wish I had time to go through all of this just to get inside their heads in terms of education strategy etc.
Also I kinda hate React but shouldn't they be introducing React or Vue or something? Who's the target audience here? Job seekers? Bored tweens? Time traveling developers from 2005? Me?
Teaching React would introduce people to something out of FB, but teaching Vue they might. Although it is an Open Source project. If they had an MS clone of it, it would have been in this course for sure.
I guess they wanted to have something fun and thought making games is a nice idea, for which they needed a canvas, so they put it in there.
The whole course structure does not necessarily seem to be aiming at the most solid teaching principles.
Looks like a great resource for absolute beginners. I have dabbled in full stack open [1] and I Think that is a great resource for people who have a little cs knowledge under their belt already.
The purpose of Web browsers is to render HTML. Javascript was an afterthought, to make pages dynamic and allow DOM manipulation. It could be Lua, it could be Python.
As such I would start learning frontend web development with HTML. You can have web development without JS, but you can't have web development without HTML.
I think this is by the CTO of reddit? It's an Udemy course on web development
Anyways, here's a slightly dated but really great source of information on web development. I saw the playlist posted in a comment on HN in a similar thread
Arguably the best web development curriculum for children that I have seen from any of the top technology companies. Congratulations.
One question: Did you consider splitting up these pictures into smaller pictures? As an example, look at this page[1]. The picture seems to have a lot of things in there. Did you consider using multiple smaller pictures?
I'm not sure I would recommend this for kids. It seems quite abstract and children often have a hard time with abstract thinking.
The course starts off with seven lessons on tooling and JavaScript fundamentals before you actually do something in lesson 8. That's a lot of theory to process.
Thank you! It's a particular style of sketchnotes that Tomomi, the artist, has perfected. They images all kind of fit together to give a holistic picture of the topic.
One thing, I did a lot of the smaller non-sketchnote art on https://aka.ms/ml-beginners, embedded as infographics. So that was a different art strategy.
Outstanding effort. However, and as usual, some improvements can be suggested. For example, users are asked to execute npm and webpack commands as a part of some lessons. What is npm is explained (by supplying a link), any clarification related to webpack is missing. Those topics could have been expanded upon, perhaps taking the whole space of the lesson devoted to building a browser extension. This subject feels to be more marginal whereas knowing what bundlers do and why is more fundamental.
It's ok if you have observations, considerations, criticism and questions about both the curriculum and the method. But if you consider it outright bad for teaching someone web development, like some commeners did, then why don't you consider it a provocation and build your own web development course and show how it can be done better?
Anyway, it's free and you are not forced to follow the course. You can extract bits you think might be useful.
My sister in law is doing the web dev freecodecamp courses and loving them. She doesn’t have a background in tech but it’s really heartwarming to see her light up when something she envisions in her head can be made to appear on the screen with some HTML and CSS.
A lot of people complaining about a free course from Microsoft? I scanned through it and covers a decent amount of what one wants and needs to know. Plus, it's free. Guess it's impossible to please people nowadays.
Slightly cynical but lesson 2 is already into GitHub and a bunch of terminal commands. Great way to put beginners off web development. I guess it's no surprise Microsoft wants beginners to sign up at lesson 2 of 24.
That example introduces a lot of visual clutter and inconsistency. I doubt anyone can make it from 1 to 24 and not feel exhausted.
Panel 4, "Deep dive into IOT" has an illustration of stick figure diving under water. I'm not sure the concept of "deep dive" requires the explanation.
...and this is where it goes off the rails; teaching JS before HTML is how we will continue to have the ridiculous proliferation of app-sites that shouldn't require a single line of JS instead needing the latest version of $browser (you have a choice of browser - pick one ...) to even show any content at all. Forms don't need any JS to work, yet the impression this gives to beginners is that they do.
https://news.ycombinator.com/item?id=25915313
But then again, this is Microsoft, which is now firmly in bed with Google in contributing to the Big Browser monopoly, so I suppose I shouldn't have expected anything else. The agenda is obvious to anyone who cares to look.