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.
At the same time, Bootstrap does include just enough javascript, for animations and the like, to make things enticing and confusing for beginners. I can't think of them off the top of my head, but I believe some features of Bootstrap are even broken without it.
I mean, they'll at least have the job until the project is finished. You're boss probably won't care if another framework comes out. Then there's all of the legacy applications that will need support. There's an entire market for that. In the meantime you can learn something new :)
I work in a large corporate environment and we're rebuilding a legacy application in Angular 1.4. They have no plans of migrating and even talk of moving to 1.5 or even 2.0 I've been told migrating to either 2-3 years away.
The problem I've come to have with this as I get older is... I realize that I have a limited amount of time to learn new things. I still love doing it, but if possible, I'd rather spend that effort on learning portable, enduring, and broadly applicable things than ephemeral arcana involved in learning to do essentially the same thing a different/"modern" way. New learning should be for new capabilities, a better quality of insight, and real advantages.
Oh yeah, I definitely get that. My main point is there's no reason to be outright afraid when a new framework arrives. I would argue there's even time to let it mature and see if it's actually worth learning.
I had a conversation with my wife, who's training to do front end development, just this morning. Our product is going to have Javascript. It's going to have JQuery. After that, probably not too much. I explained to her the difference between an app and a web site (we're making a web site). There is only one app-like section. Even that is vanilla JS.
All that said, I told her to pay attention in the Udacity backbone class. General framework knowledge should let her generalize using JS.
I used an example. An app, that she's familiar with, is Gmail. I said our product is not a desktop application, like Outlook, but for the web. What we're going to do is mostly display static content, refresh the screen on navigation circa 2002, etc. So there are some parts where we need dynamicity, like our menu builder, but for the most part we don't need anything complex. As a result JQuery is fine.
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).
Isn't SIMD a little overkill for a prototype? I mean, unless you already know how to write the data and solver amenable to SIMD ops, it can be some work..
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
But devs should have a firm understanding of Vanilla JS so that when (not if, but when) they need to do something the framework designer never thought of, they'll be able to develop a workable solution.
In fairness to Wes Bos, he says right on the landing page that "these things are great and often needed, but can obstruct learning and constrain initial understanding."
Keep in mind we're not talking just about JS on the web running in web browsers. It runs on servers. It runs as standalone applications. If you are targeting a non-web environment you're not writing for quirks of different browsers, you know the runtime environment you are targeting explicitly. It isn't that bad.
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...
How quickly after learning JavaScript should one consider learning TypeScript? I've used JS for a while now (two-three months) and want to try TS but at the same time not jump ship too quickly.
Typescript is great because it can be gradually added. It's just additions on top of JS, so if you're writing any JavaScript, you're already writing compatible TypeScript (the types just default to "Any"). Then you can add type definitions wherever you like. The whole codebase, or just a few functions that are often confusing (like that damn function which is expecting a "YYY-MM-DD" string instead of Date object).
You only realize most of the benefits though when working on a large/complex project, or on a team where you're not responsible for most of the codebase, or other scenarios where it's hard to keep the entire project "in your head" at once. If you're just using JS to add autocomplete, pagination, other simple things to a page, then TypeScript may just be unnecessary effort.
Basically, how often do you end up with a bug because of improper types. Or how much time do you spend looking up what type you need to use somewhere. TypeScript is worth it when the time spent on those issues is greater than the time spent learning TypeScript (which isn't very much).
You won't be jumping ship at all. Everything you know about JavaScript applies directly to TypeScript. It's a superset of JavaScript. You can even take your existing JavaScript code and start adding TypeScript annotations to it a little at a time.
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.
I'm not saying it's a silver bullet, and it should not be treated like one.
But everyone here is a fairly experienced dev. Working with junior devs is difficult, especially frontend devs who usually lack comp sci fundamentals.
Frameworks provide structure to what would normally be an absolute spaghetti mess, even at the cost of overhead. I would rather have bloated but maintainable code. It's hard to even unit test vanilla js properly. Those who rail against the current framework world forget how bad the vanilla world was...spaghetti code, no real design patterns, terrible class design, no standard lib...the list goes on :(
It's frustrating that the counterpoint to the "framework everything" crowd is the "never framework" pattern. Both are bad for different reasons right? I would never want 10+ devs working on the same project without some kind of framework, either homebrew or open source. But also running react for your tiny little dev blog is equally bad.
I buy your argument about frameworks providing structure. And most software projects are a untestable spaghetti mess, it's not because of vanilla JS though, spaghetti code have been written in many different languages. The problem is inexperienced engeneers, and old design patterns in school books, like Classes ;)
I've been designing software for over 15 years and here's some tips that works well for JS and probably other languages too:
1) Avoid code couplings, if you keep couplings at a minimal, you only have to test the code once and it will never break.
2) Modular code: All dependencies should be contained! Dependencies should be branched, not entangled/complexed
3) Independent functions: Functions should not have any dependencies from the outside scope, not even other functions if possible. Use lexical modules and sub-functions.
4) Event listeners: Have independent "micro services" that listen for events instead of orchestrating.
5) Abstractions: Make it possible to use functions/modules without knowledge about the abstracted code.
6) Avoid state =)
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.
the retro categories are because sceners also enjoyed and used to code demos for the C64 and Amiga platforms when they were popular back in the day.
While you could do some funky stuff with IE6 JS, you also couldn't really do anything. Don't forget how utterly slow JS was back then, not because the computers were slower, but because it was interpreted and run token-by-token in a very inefficient manner. This, and nobody took it seriously then as a language to write actual applications in. If a scener had to do something splashy in the browser, they'd go for Flash (and still groan about its lack of performance).
If you told someone back then about "asm.js", they'd think you were making a joke, and a pretty funny one at that (like if you told them Microsoft would become a platinum member of the Linux Foundation kind of joke back then).
> ...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.
Well, there's rules. There always have been rules. You can't read out default icons, themes, desktop background images from the system folder to obtain some nice stock graphics for use in a 4096 byte demo, either.
If your entry hacks the compo machine and doesn't do it with an extreme amount of grace and style, expect to be booed off stage. With sufficient style and awesomeness, you might just get disqualified :)
the common demoscene platforms and filesize limits bring limits that make the coding fun, exciting, challenging.
IE6 seems to me like an arbitrary limit that just makes life horrible without much gain. i don't think sceners are going to target retro browsers soon.
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.
Not really an apples to apples comparison. With JS and the browser, you are distributing the runtime libraries separately from the application. Imagine having to write a GUI app in Java that would work with every JRE version.
The other thing is that Sun owned the standard. So even if you were IBM and were making your own runtime environment, you couldn't call it Java unless Sun agreed. Imagine if you had multiple vendors supplying a JRE and several of them were intentionally breaking their versions to lock users into their implementation.
Lately the browser vendors have started to work a little bit better with each other, but I doubt it will ever be like Java.
Yes, you are right. I wasn't complaining though, as I understand the reason behind the current state of things. It was more of a wish, to be clear.
However, in the end, we are still getting something close to Java with Web Assembly (Stable byte-code-like platform and potentially many languages targeting it).
I could do it if there was reasonable limits on the viewport size of IE browsers. For instance, if the IE6 window will always be at least 1024px wide. Once you need to give IE6 responsiveness, the only way I could imagine doing it would rely almost exclusively on CSS hacks.
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.
I don't like Internet Explorer either but a website should support all the major players. Edge is surprisingly my daily Window Browser if it isn't my computer.
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!
