30-Day Vanilla JavaScript Coding Challenge
javascript30.com
javascript30.com
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.
The rest of Bootstrap is just css however.
Pick any Javascript forum on the internet, even HN comments, if you'd like. The common comment is "Just use React".
The interesting thing is they are not lying: You'll get a job which will last until the new library de jour arrives.
Maybe this is how the job market answers the high demand. I personally have no idea.
I can confirm this.
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.
All that said, I told her to pay attention in the Udacity backbone class. General framework knowledge should let her generalize using JS.
What did you say here? I've been thinking a lot about this lately -- In my opinion, a websites are a part of an 'app': the client.
* If you use FE JS to implement any of your sites functionality then you have an app.
* If you only use FE JS for just presentation logic then you have a website.
Or Vue.
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).
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
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...
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).
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.
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'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.
I definitely learned something from this.
...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.
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 :)
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.
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.
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.
You don't have to imagine. Just tried it:
http://i.imgur.com/zBNkKTu.png
Netscape IFC, 1996-1997 vintage. Compiles and runs like a champ on JDK 8, current OS X. Just like it did on JDK 1.
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).
On a website I maintain, almost 70% of users use IE7.
We tried to get them to update, but no results.
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.
http://htmlpreview.github.io/?https://github.com/tjbarbour/J...
<audio class="closedhihate" data-key="83" data-stop="audio.openhihat" src="sounds/hihat.wav"></audio>
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.
>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).
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 kid, this is awesome)