No frameworks, no boilerplate - this is a great idea. I've seen too many junior developers go straight into learning React/Redux, or using bootstrap, or plugging in some library like velocity.js. It's often easier, more efficient, and more maintainable to use plain javascript with web APIs.
> I've seen too many junior developers ... using bootstrap
Bootstrap solves a different problem than jquery. Most developers hate designing (OK most developers I know...) and use bootstrap just to get something halfway decent looking and focus on javascript rather than design/css/quirks.
Very true. I remember wanting to throw my computer out the window when I had errors relative to this, pass by ref, or when a callback gets called when learning js through react/redux. But I think react is what motivated me to learn js in the first place, so it goes both ways.
Indeed, I think the best way to learn a coding is motivation. And the best motivation is making something you cherish. To me, it was a music web app I'm still working on. I had tried to learn JS many times in the past and had never succeeded. React allowed me to structure my code (the wrong way at first, I had everything in react components not just view logic, but gave me structure none the less) and think about my UI in an object manner. Moreover, this way, I ran into problems, looked for solutions and learned this way. As opposed to learning solutions and finding problems they solve.
Little by little I got to see why I might need react-router and redux. Redux made my life so much easier (no need to pass state in a hierarchical way anymore, any component can read and modify state of other components regardless of relative tree position, and in a safe explicit way).
After a year of having learned frontend this way, I consider myself a js coder. I made a fairly simple website the other day (just django + jquery) I'm kinda proud of. This web app was the first and only web project I had ever done, and this jquery website was done in a couple days.
My third ever project (I'm working on it as I'm writing this) is a cfd solver in js using web workers and SIMD for the solver and react/redux/d3 for the frontend. I've tried to learn to code so many time to be able to spin up projects like this (in this case, to review and practice my cfd, not build airplanes), and I was never able to because I never had the motivation to finish learning about ifs and loops of whatever language whenever I started reading a book about it.
The hardest thing about learning js through react is that a js beginner wants to user JSX. I came from HTML (a whiiiile ago), so it made (and still makes) sense for me to use JSX (and it made zero sense to me not to use it). The problem of course, is that I had to introduce myself with babel and browserify (because even the latest Safari doesn't understand JSX). But once that's set up, you've already understood about npm and compilation. So you pretty much already know how to use ES# or SASS if you want to use it. And minifying is just a few lines of code and SO answers away.
I guess this has become the story of "how I learned to code", but I wanted to share how starting with a "it's too complex for a beginner" project and jumping straight into react/redux and skipping over vanilla could be beneficial if one has the motivation to finish the project but not the attention span to go through vanilla beforehand. Because one will have to learn vanilla to succeed at anything anyway, but by making stuff you really care about at the same time in this case.
Btw, I think what got me to say "fuck it, I'll jump straight into react and build shit, fuck all these tutorials" was that I read a while ago a quote about the tumblr guy saying something along the lines of "the only way to learn to code is to make a project you care about" and my older brother telling me "learn django, you'll be able to make websites and you'll have learned some python at the same time" (he's an experienced coder knowing I was not).
Now just remove the framework requirements from all of the job descriptions so the people hiring and the people working are all on the same page about how work is actually done.
Nonononono this is a horrible idea. Vanilla js is the whole reason all these frameworks were created. I guess if you don't care about the 1000+ hacks and workarounds to make your code everywhere you're right.
Might as well call it "vanilla chromescript" if you're going that route. Outright rejecting everything that was built for a good reason is worse than covering up bad skills with a bunch of libraries. At least the libraries actually work
I think I might disagree on 'maintainable' depending on your definition.
For instance, ever since picking up TypeScript my projects have been much easier to maintain. I'm sure the same would apply with a templating framework, depending on your needs...
Not really. JS has no true concrete design patterns, no built in state handling, no built in tooling. Going straight into React/Redux isn't the best, because you miss out on learning JS fundamentals, but it will produce a far more maintainable project due to the assumptions it makes and enforces. It also makes it easier for others to just jump in and make changes, given that they know x or y framework. You could not know any vanilla js and still probably make more long term maintainable code just based on how the framework is designed.
Vanilla js would require the engineer to set patterns and make assumptions, something that junior devs might do incorrectly. You will reinvent the wheel and probably do it inefficiently unless you are a seasoned vet. Not only that but others who are not familiar with whatever homebrew stuff you have cooked up will not be able to just dive in and start putting pieces together without a fair amount of reading. It's not impossible, but hard with a large dev team.
This is why frameworks exist, no? Don't get me wrong I hate the framework bloat and pace of frontend engineering but these frameworks do serve a very legitimate purpose. But this definitely goes against the JS hate trends as of late.
Doing it right now. Great selection of exercises, great videos and it's loads of fun!
What's the name of the song playing in the beginning of each video?
EDIT: This made me realize how much browsers have improved over the years and how much you can actually do with just HTML5, CSS3, ES6 and browser APIs today.
Really helps you take a step back and see your daily use of frameworks and libraries like React, Redux etc. in a different light.
That reminds me of how the demoscene has a JavaScript demo category now, which usually targets the latest browser(s) with all the new JS features. It also has the usual native demos on the latest PC, and retro demos on platforms like the Atari, C64, and ZX Spectrum. Perhaps it should also have a "retro browser" category for IE6, Firefox 2.x, and the like.
...but I feel that someone would just find an exploit in JS, break out of the sandbox, and use that to run a native demo instead.
Like doing the impossible? Create a responsive layout with 3 sections (header, content, sidebar) that will look exactly the same in the given browsers (at the same resolution) while still looking great on mobile, without any JavaScript or even server-side feature detection. Bonus points for minimal number of CSS hacks.
Seriously, remembering the stuff I had to deal with, in today's world of the "modern browsers", I feel like I changed my profession completely. In other words, I'm afraid that me from 10 years ago wouldn't be able to understand so much from the front-end code I write these days and I'm also not sure about the vice versa. The opposite are, although that I don't enjoy the language too much, my Java projects which feel like they are immortal. I wonder if and when JavaScript will be that mature.
This is great! Some of the frameworks/libraries are great, but not always. I've been systematically pulling unnecessary libraries out of plugins for use in my own projects. Here's one I just did, where I pulled jQuery out of the plugin:
As ones who has done Wes's React and Redux course, we have found him to be one of the best instructors out there. He seems to grasp how to teach and not just show by example. All levels seems to get a lot form his work. Funny also... Kudos and highly recommended.
Every junior developer should start out learning nothing but HTML+CSS+JS. It's so beneficial to understand the quirks and gotchas of these three and how they interact, to really appreciate how these technologies evolved.
I have a young son who's coding on code.org and Scratch, and I'd love to get him into pure web development. Kudos to Wes Bos for setting this up.
Hoping this is just a one time issue, but in the first tutorial:
>const keys = document.querySelectorAll('.key');
is provided, but it will trigger an error in the console. As far as the video is concerned this is part of the final code. However, if you look at the starter files, there's a final version of the the code and that line has changed to:
Which of course works fine. Kind of inconvenient to have to turn to the the source files to learn how to do it right from a video. It may be possible that I just missed a video annotation, which is completely possible given my approach to these kinds of things (code while I watch).
Browsers recently added `forEach` methods to NodeLists. Make sure you are using the latest version of your browser. Array.from(...) may make it work with somewhat older browsers.
Great course! I'm using it right now and it's some nice hands-on practice.
One nitpick: In video 14 about references vs copies, around 2:20, you say, "`team` is not the array, `team` is just a reference to the original array, which is `players`." It's a little ambiguous but to me it sounds like you're saying that the variable `players` is somehow special and different from the variable `team`, as if it's not just another reference to an underlying array. This seems like it could confuse newbies.
This scientific programmer (python/R/C) thanks you for an amazing resource. I have been looking to augment my Python knowledge with a new, faster scripting language. Lua(jit) was my first choice, but JS is so fast these days, and is so strong on visualization, that it is now supplanting Lua for me as first choice. But the JS ecosystem is so vast, so full of "offshoot dialects" (jquery, coffeescript, ES6, Typescript, not to mention all the frameworks) that it is quite daunting for a beginner. This therefore is exactly what I was looking for. You've just spoken for my Christmas break!
[+] [-] johnomarkid|9 years ago|reply
[+] [-] chrisan|9 years ago|reply
Bootstrap solves a different problem than jquery. Most developers hate designing (OK most developers I know...) and use bootstrap just to get something halfway decent looking and focus on javascript rather than design/css/quirks.
[+] [-] JustSomeNobody|9 years ago|reply
Pick any Javascript forum on the internet, even HN comments, if you'd like. The common comment is "Just use React".
[+] [-] globuous|9 years ago|reply
Indeed, I think the best way to learn a coding is motivation. And the best motivation is making something you cherish. To me, it was a music web app I'm still working on. I had tried to learn JS many times in the past and had never succeeded. React allowed me to structure my code (the wrong way at first, I had everything in react components not just view logic, but gave me structure none the less) and think about my UI in an object manner. Moreover, this way, I ran into problems, looked for solutions and learned this way. As opposed to learning solutions and finding problems they solve.
Little by little I got to see why I might need react-router and redux. Redux made my life so much easier (no need to pass state in a hierarchical way anymore, any component can read and modify state of other components regardless of relative tree position, and in a safe explicit way).
After a year of having learned frontend this way, I consider myself a js coder. I made a fairly simple website the other day (just django + jquery) I'm kinda proud of. This web app was the first and only web project I had ever done, and this jquery website was done in a couple days.
My third ever project (I'm working on it as I'm writing this) is a cfd solver in js using web workers and SIMD for the solver and react/redux/d3 for the frontend. I've tried to learn to code so many time to be able to spin up projects like this (in this case, to review and practice my cfd, not build airplanes), and I was never able to because I never had the motivation to finish learning about ifs and loops of whatever language whenever I started reading a book about it.
The hardest thing about learning js through react is that a js beginner wants to user JSX. I came from HTML (a whiiiile ago), so it made (and still makes) sense for me to use JSX (and it made zero sense to me not to use it). The problem of course, is that I had to introduce myself with babel and browserify (because even the latest Safari doesn't understand JSX). But once that's set up, you've already understood about npm and compilation. So you pretty much already know how to use ES# or SASS if you want to use it. And minifying is just a few lines of code and SO answers away.
I guess this has become the story of "how I learned to code", but I wanted to share how starting with a "it's too complex for a beginner" project and jumping straight into react/redux and skipping over vanilla could be beneficial if one has the motivation to finish the project but not the attention span to go through vanilla beforehand. Because one will have to learn vanilla to succeed at anything anyway, but by making stuff you really care about at the same time in this case.
Btw, I think what got me to say "fuck it, I'll jump straight into react and build shit, fuck all these tutorials" was that I read a while ago a quote about the tumblr guy saying something along the lines of "the only way to learn to code is to make a project you care about" and my older brother telling me "learn django, you'll be able to make websites and you'll have learned some python at the same time" (he's an experienced coder knowing I was not).
[+] [-] FLUX-YOU|9 years ago|reply
[+] [-] nrjdhsbsid|9 years ago|reply
Might as well call it "vanilla chromescript" if you're going that route. Outright rejecting everything that was built for a good reason is worse than covering up bad skills with a bunch of libraries. At least the libraries actually work
[+] [-] kylestlb|9 years ago|reply
For instance, ever since picking up TypeScript my projects have been much easier to maintain. I'm sure the same would apply with a templating framework, depending on your needs...
[+] [-] jorblumesea|9 years ago|reply
Vanilla js would require the engineer to set patterns and make assumptions, something that junior devs might do incorrectly. You will reinvent the wheel and probably do it inefficiently unless you are a seasoned vet. Not only that but others who are not familiar with whatever homebrew stuff you have cooked up will not be able to just dive in and start putting pieces together without a fair amount of reading. It's not impossible, but hard with a large dev team.
This is why frameworks exist, no? Don't get me wrong I hate the framework bloat and pace of frontend engineering but these frameworks do serve a very legitimate purpose. But this definitely goes against the JS hate trends as of late.
[+] [-] acrynx|9 years ago|reply
Doing it right now. Great selection of exercises, great videos and it's loads of fun!
What's the name of the song playing in the beginning of each video?
EDIT: This made me realize how much browsers have improved over the years and how much you can actually do with just HTML5, CSS3, ES6 and browser APIs today.
Really helps you take a step back and see your daily use of frameworks and libraries like React, Redux etc. in a different light.
I definitely learned something from this.
[+] [-] felixthehat|9 years ago|reply
[+] [-] pvdebbe|9 years ago|reply
[+] [-] userbinator|9 years ago|reply
...but I feel that someone would just find an exploit in JS, break out of the sandbox, and use that to run a native demo instead.
[+] [-] egeozcan|9 years ago|reply
Seriously, remembering the stuff I had to deal with, in today's world of the "modern browsers", I feel like I changed my profession completely. In other words, I'm afraid that me from 10 years ago wouldn't be able to understand so much from the front-end code I write these days and I'm also not sure about the vice versa. The opposite are, although that I don't enjoy the language too much, my Java projects which feel like they are immortal. I wonder if and when JavaScript will be that mature.
[+] [-] shakna|9 years ago|reply
On a website I maintain, almost 70% of users use IE7.
We tried to get them to update, but no results.
[+] [-] opvasger|9 years ago|reply
[+] [-] reimertz|9 years ago|reply
1. hand people an idea that is easy and funny yet complex.
2. give them the tools to be able to do it.
3. make them do it
4. repeat 1-3 thirty times
This is how I learn things and argue that it is the most efficient way to learn something for certain people.
[+] [-] jagermo|9 years ago|reply
[+] [-] tjbarbour|9 years ago|reply
http://htmlpreview.github.io/?https://github.com/tjbarbour/J...
[+] [-] nkozyra|9 years ago|reply
<audio class="closedhihate" data-key="83" data-stop="audio.openhihat" src="sounds/hihat.wav"></audio>
[+] [-] wesbos|9 years ago|reply
[+] [-] a12k|9 years ago|reply
https://a12k.io/reallysimpleweather
[+] [-] TimMeade|9 years ago|reply
[+] [-] wesbos|9 years ago|reply
[+] [-] kasparsklavins|9 years ago|reply
[+] [-] eswat|9 years ago|reply
[+] [-] lobo_tuerto|9 years ago|reply
[+] [-] joeax|9 years ago|reply
I have a young son who's coding on code.org and Scratch, and I'd love to get him into pure web development. Kudos to Wes Bos for setting this up.
[+] [-] toxican|9 years ago|reply
>const keys = document.querySelectorAll('.key');
is provided, but it will trigger an error in the console. As far as the video is concerned this is part of the final code. However, if you look at the starter files, there's a final version of the the code and that line has changed to:
>const keys = Array.from(document.querySelectorAll('.key'));
Which of course works fine. Kind of inconvenient to have to turn to the the source files to learn how to do it right from a video. It may be possible that I just missed a video annotation, which is completely possible given my approach to these kinds of things (code while I watch).
[+] [-] sscotth|9 years ago|reply
https://developer.mozilla.org/en-US/docs/Web/API/NodeList
[+] [-] pkkim|9 years ago|reply
One nitpick: In video 14 about references vs copies, around 2:20, you say, "`team` is not the array, `team` is just a reference to the original array, which is `players`." It's a little ambiguous but to me it sounds like you're saying that the variable `players` is somehow special and different from the variable `team`, as if it's not just another reference to an underlying array. This seems like it could confuse newbies.
[+] [-] rendall|9 years ago|reply
[+] [-] rasz_pl|9 years ago|reply
[+] [-] agumonkey|9 years ago|reply
[+] [-] singularity2001|9 years ago|reply
[+] [-] alexhakawy|9 years ago|reply
[+] [-] clifanatic|9 years ago|reply
(I kid, this is awesome)
[+] [-] vegabook|9 years ago|reply
[+] [-] the_cat_kittles|9 years ago|reply