10 JavaScript Concepts Every Developer Should Know (or should you?!)
Vložit
- čas přidán 14. 07. 2024
- Should you really need to know all of these topics? Let's discuss ten topics in JavaScript and talk about how important they are to know!
Read the original article - madni.hashnode.dev/important-...
*QUESTIONS ABOUT MY SETUP*
Check out my Uses page for my VS Code setup, what recording equipment I use, etc. www.jamesqquick.com/uses
*STAY IN TOUCH 👋*
Check out the Podcast - compressed.fm/
Courses - jamesqquick.com/courses
Newsletter 🗞 - www.jamesqquick.com/newsletter
Follow me on Twitter 🐦 - / jamesqquick
*DISCORD*
Join the Learn Build Teach Discord Server 💬 - / discord
*TIMESTAMPS*
00:00 - Intro
01:20 - Hoisting
02:30 - IIFE
03:35 - Callbacks and Higher Order Functions
05:05 - Callback Hell
05:55 - Promises
07:15 - Async Await
08:40 - Closures
10:20 - Event Propagation
12:30 - Currying
13:10 - Spread Operator and Destructuring
15:10 - Wrap Up
I use hoisting all the time! I put my functions in a "functions" section at the bottom of my files, that way you only see the invocations and the business code at the top, without the noise or implementation details unless you need them. It's a tip I got from Kyle Simpson, and I think it both adds clarity and... it's stylish, and I dig stylish.
Yep, hoisting isn't only var declarations but also function statements, which I'm sure most js devs have used or are using daily.
IIFE is import to understand because under the hood, this is how modules work.
Currying is super useful! Like for creating functions when you don't have all the arguments ahead of time. You must have used Redux and thunk (before RTK) ? Where your action creators return a function that later gets called by thunk as Redux middleware. So you dispatch your action which returns a function, then thunk middleware steps in - sees it's a function that was dispatched and calls that function for you passing the dispatch - That's currying.
Another great example is event listener handlers, you can setup/curry a function that does something and return a function that takes the event object. So you can call your function to set it up (with dynamic unique values perhaps) and it returns a event handler function.
Currying works because of closures, so the two go hand in hand really.
Currying makes much more sense if you understand how functional programming and the lambda calculus (on which it is based upon) works and is especially useful there in the context of partial application and composition. In functional languages, you can compose functions by just connecting their inputs and outputs in order to obtain new functions. To make this work, partial application (which I believe is implemented via currying) is helpful to match arities and types of arguments and return values while “closing up” (→ closure) over values that you want predefined. This can be very powerful and flexible, but I think in JS you need a library like Lodash or underscore.js since this functionality is not built-in (and it may not be as performant). Partial application is also generally useful in higher-order functions like map, filter, reduce, etc.
HOF is a hugely important topic, especially for Functional Programming style. For example, it can cover a similar "constructor" pattern in OOP. Currying relates closely to HOF as well.
Kinda glanced over it lightly here, but really cool and helpful once it's mastered.
Thanks for the videos!
Thanks for the video. Glad to hear your opinion on Currying. I have never used it either and every time it comes up I secretly worry that I should know. Another question that gets asked in interviews sometimes is what is Object Oriented programming and I never really know how to answer that, but I guess that's not specific to JavaScript anyway. Great video!
Destructuring is the most important for me! Followed next by Promises/Async/Await.
Wonderful video
you can't say that you don't use hoisting, it's just happening by itself... that's one of the feature of js
Some of these short punchy explanations were better that those I received on a recent bootcamp!
haha really? That's great to hear!
A lot of these (hoisting, IIFE, etc.) are dated, they were very important when I started working with JS around 2013, but now they only really show up in job interviews where interviewers are lazy and dont update their question pool
That's how I feel! lol
Don't quote me on this but I believe all top-level import statements are automatically "hoisted" for you, because they are being read by the engine before any other code executes. Though that is slightly different to the hoisting you discuss in the video.
Just a quick typo it's IIFE not IFEE
ah wow, fixed in the cover!
I don't use "var" and i think you shouldn't, in terms of stability. I always use const and only if it's not possible, than let.
Samesies!
@@JamesQQuick i believe hoisting is used more for functions if u make a const function u cant call that function until after it has been declared. But if u use the function keyword the function is hoisted to the top of the file and can be used anywhere
@@ononaokisama Yeah i think it's both even though I didn't mention the function part. I also typically don't use the function keyword which explains why I don't think about hoisting with functions either lol
I liked the "or not"
Yeah, I'd never used or seen curry or partial application in a project. That seems like it would be best used in a library or framework rather than solely by itself in a project because of low readability of the what the function is doing.
Logical programming javascript and DOM Javascript. good way to separate the API available only in the Browser platform.
The thing I don't like about promises is that all or most of the examples use set timeout.
The reliance of set timeout explain promises is really confusing because using set timeout in so many examples seems to be like a fundamental part of promises.
It took me a longtime to put it together that it it was just an artficial clock to similate a fetch/xhr request.
Would you use a promise for anything else? Never seen an actual example outside of making a http/fetch request.
Maybe use it to have data processing where it might take more than a few seconds to complete or fail. Idk
That's a great point. It's always hard to find a relevant example for beginners that isn't over simplified but also not too complicated.
In terms of usage for promises, yes anything working with file system, databases, APIs, etc typically use promises. Many of those actions happen over HTTP requests anyways, so that is definitely an extremely powerful example
@@JamesQQuick Same thing with prototypes. Everyone on the internet uses the same two examples to show inheritance. It's either an animal that makes a noise or a car with make, model and color.
I have been doing this professionally for over 5 years, front end, and I have yet to see a practical example of a real world use case.
I am sure prototypes, classes, etc make sense for when you're making a new JS framework but not something I typically need.
One interesting thing about JS async/ await is that you're *yielding* the main thread execution. If there are other tasks waiting in the scheduler (see: Jake Archibald's great talk on the event loop), you're letting the runtime work on something else until that potentially long-running promise has returned.
This is a good way to prevent blocking the main thread, which makes your web app/site unresponsive to user interaction.
Also, f you have a lot of concurrent code, you can really get noticeable performance improvements by firing off multiple functions at the "same" (almost) time and letting the runtime optimize their execution while you await for the end result.
What about classes, abstract classes, inheritance. Do you ever use any of these?
Classes are used heavily in Nest JS and Angular, use Nest myself so lots of classes.
@@lardosian I've tried using classes to make myself feel like I'm doing things "properly" but it just makes things more complicated for many use cases.
I've used classes in Angular but I'm not creating new classes from scratch.
@@AlexvanderValk I did quite a lot with React using functional components 2 years ago, I must say I felt more comfortable using the functional components compared to the class based approach.
Hi James. I hope my question will not bother you because you must have heard it 1000000 times. I am almost 1 year working with a js framework SAP UI5. I dont have any technical university but my big dream was to become a developer. After almost 1 year I still atruggle and face many issues where I am not able to solve the problems alone. I know it requires time and it takes a years. I want to be better but I just dont see the things other people see. Why not? Am I lost case?
I use IIFE for my main app file for personal projects, but that's about it. Also, anonymous functions are not great practice
Thanks for sharing!
I wonder if Madni is getting any of the CZcams revenue for this video. Seems kinda unethical to essentially read off someone's article and not add a lot of commentary or additional explanation beyond what's in the article.
A good chunk of this video was, "I don't use this" or "I'm not really sure about this". That's an odd take on a video titled 10 Javascript Concepts Every Developer Should Know.
hey bro, you have some bad background sound... Something like Zzzzzzzzzz Zzzzz. Anyway video is good!