this is all fairly subjective. i moved back to named functions as i find them easier to read. Others would have had the opposite experience. if you are a new developer do not take this video seriously. do what works for you - best practice is usually just personal preference.
Named functions can also be called before they are declared, which can be seen as a good or bad thing. I think it’s good because it allows developers to organize code more freely.
Don't do what works for you, follow the coding style guide for the project you are working on and be consistent with the existing code base. If you are the sole dev the do what floats your boat, it's your codebase.
I typically use named functions for functions that I specify on the global scope and use arrow functions for anything that's inside a function or prototype and especially for anonymous functions.
You only talked about one use case of "this" in JavaScript. In this case we can sometimes get rid of it, but we need "this" a lot in object-oriented programming in JS. For example, when we have a "Circle" class and refer to a radius of a Circle instance inside of a class method, we write this.radius. This use case is also less confusing and will probably not go away any soon.
You're right however, JS is not an OOP lang by nature. Of course, it is a matter of preference, and if you go with the classes, then expect to use "this". In my experience, JS is absolutely turning into more like an FP style language (which I prefer too), just look at the functional pattern improvements in the last couple of years. I think classes are interchangeable with functions in all cases without exception. But again, it is a matter of preference. People coming from Java/.Net world, tend to use more classes. Interesting fact though, they tend to turn into FP shortly :) James' video highlights the issues of "this" in the context of functional style, which is quite real and been here in the last 25 years or so.
One of my favorite things about Javascript is the ability to add new methods to existing objects via _prototype_ functions. Which often require use of "this".
@@the-suspect For one you don't really need OOP in JS and I find it much simpler to just avoid it. It'll most likely also lead to better code once you escaped the OOP mindset. Nowadays it's all about clearly typed objects & functions in TS, I haven't met anyone who uses OOP JS outside of web development classes.
Re: “self-documenting code”, Code commenting is more valuable if it describes “why” rather than “what”. I don’t need a code comment to just translate into English what the code is doing, but explaining the _intention_ of the programmer serves to double-check that the code is doing that it’s _meant_ to do. In that regard the comment is just as much for the original programmer as it is for the “reader”. If the programmer writes their intention, the code tends to be easier to write, with bugs and flaws becoming apparent. If you can’t describe both _what_ and _why_ you’re writing a line of code that way, it’s a red flag that you haven’t thought it through. Debugging both your own and others’ code is much easier with “why”-style comments. Turns out, after decades of commenting this way, I’m now being rewarded by better results from GitHub CoPilot too :)
I disagree somewhat in this case. You should explain 'why' something should or should not do something. In this case, though, it's a data structure (object literal). It doesn't do anything, it just 'is'. Given that, i think it's good to just define exactly what it is. I usually use 'By' as a convention, though. In this case, the example would be `usersById`.
Agreed that the example in the video isn't the best for this point. Saying that, I do over-comment my code intentionally -- most statements get a comment; or at least, every _action_ gets a comment. The reason being that if I just commented sections I thought needed commenting, I'd miss out those that seem obvious to me, but might not be to others. Admittedly it does feel a bit stupid writing those comments at times, but if everything else is diligently commented it looks weird. I usually just throw in a joke or some self-deprecation instead. A colleague once summed it up as making comments "a good director's commentary track rather than an audio-description track."
When getting large data sets, the classic "for" loop will outperform forEach.. etc. So if performance is struggling, this is one of the first changes to make. Maybe this will change in JS over time, but forEach, etc. have lagged behind for years.
Not only that, but in place of using reduce (and forEach), a for loop is often more readable. Especially when using iterator (`x of y`). I prefer using for loops for readability in complex transformations, filtering and/or reduction.
I don't think the difference is meaningful even in huge datasets. Benchmarks don't show that it sbetter. But the benefit of forEach is that it's more clear what's happening and has less boilerplate.
Came here to say this, thank you! Also, defining a function inside another creates closure for ALL variables in outer function and that's (can be) very memory inefficient
For self-documenting dictionary/Map pairings of key => value, I usually use 'By' as a name convention. In this case, the example would be `usersById`. Object literals in JS can go either way depending on how you're using them. If you're using them as a Map, with dynamic key values, then the convention above works. It's less applicable, though, when using the object like a class-instance or struct where you have hard-coded references to expected property names.
Re: For loops….You may want to note that array methods (map, forEach etc) dont work inside generator functions, you have to use for…of loops in generator Fns to iterate arrays ie. in a [Symbol.Iterator] method.
For the commenting code one, I always and have always tried to be nice and specific with my naming. However coming from a data scientist/R background, I also still think commenting is important throughout the code. What's obvious to you from a name might not be obvious to the next person as knowledge bases can vary, so nothing wrong with a little 5 or 6 word descriptor for a section of code. Plus, in the RStudio IDE you can collapse code via comment headings and have markdown heading levels to give a full document outline to your code, so it's just a good habit I'm in to keep my code clean, organised and navigable, even in web-based coding.
@@JamesQQuick For me, the steps are three: a) make it as obvious as possible what your code is doing, b) don't comment what is obvious, c) comment on the not-so-obvious facts about your code. In my experience, there are a lot of those cases, where you need to explain the "why" but not the "what".
I generally avoid commenting "what" my code is doing. If I have to explain what it's doing, it's too complicated. Sometimes, however, I need to do things that are a bit weird, a bit off standard practice, a bit new, or I simply can't think of a way to write the code that isn't hard to understand. This is when I will at least start with a comment indicating "why" I wrote the code that way. This way the next dev who comes along (possibly me), will know the reason I had for writing this and that will give insight into how to fix it, if possible. If it's overly complex, then I will add a `TODO:` in the comment to indicate that this code needs some love when we figure out how to provide it. I've found that code that is riddled with too many comments becomes very distracting and it actually becomes harder to read with all the commentary around it, so I avoid comments when possible.
Great list. My favorite trend is is getting away from function parameter lists, and just passing one object that can then be deconstructed. It's great because all parameters are named, making them "self documenting".
I make apps for engineering calculations and I do the same.When all input is complete I create an "item" object that I can feed to multiple calculation steps. Each step grabs its own input and adds its output. The main challenge is finding meaningful and non-conflicting names for all properties.
5:16 Given your point about increased use of typescript, plain functions still play a major role when defining function overloads in typescript. Overloads do not work with arrow functions.
Well yea. You don't overload functions you overload methods. You don't define a method using the traditional "function" syntax OR arrow function syntax in the first place.
@@peteredmonds1712 you are conflating overload and override. Override is something you do to change the behaviour of a method, in a subclass I.e. you are overriding the default inherited behaviour. The parameters and return type stays the same. Overload can only be done to functions. A function overload declares an alternate set of parameters and/or return type for that function. For example, a function that could either take a string or an array could have two overloads: one which has a parameter type of string and another which has a parameter type of array. The function implementation still stays the same, but the overloads serve as a hint to the user of how they can call the function. A language like javascript will not be able to do overloads because it has no type system to disambiguate the overloads, however most typed languages have this feature, including typescript. Before typescript, it was up to the author of the function to include in their documentation that this function can take two types of parameters, but now with typescript and overloads, the code becomes self-documenting.
One can shorten the for loop example code even more like this 02:30 - For Loops names.forEach(console.log) This will pass in the item from the array into the function which is console.log Useful for cases like, listOfItems.filter(Boolean) filters out falsy values
Of course, the problem here is that console.log takes variable arguments. And the callback for forEach is actually supplied 3 arguments. In other words, it will print the name, but it will also add the index and the initial array as well.
2:36 There is also the for...of loops which can act as an alternative to foreach loops. I think typescript even converts forEach loops to use for...of when targeting es6 and above. For of loops are particularly useful for working with generators.
Regardless of of what features are outdated and not in common use, still, I think every developer, especially beginners, should learn, understand and familiarise themselves with these concepts (var, plain functions, for loops, this keyword etc.), before starting implementing the new alternatives.
@Tim Davis I agree that this is not necessarily a best practices list. So much of it is opinion based which is fine as long as it works for your. BUT I would highly cautious taking it upon yourself to determine what/who "real" developers are.
I must admit I am old school and still do most of these things: I still write vanilla Js, I still use a lot of For loops, still write full Functions and only sparingly use arrows F, still comment code (Using JSDocs), I use minimal optional chaining as I still find a need to do something if a value does not exist, and I still heavily use console log to debug, although I am progressively leveraging Vs code built in tools. The only thing I have stopped doing 100% is the use of var.
I prefer using every() without side effects (as the name says - to check every element for something).. same principle as map() etc. If I need to use break or would have side effect in function I actually prefer a for loop (usually for..of). When I think about it, I dont even like to use forEach(). I use map() (even for working with object as a map using Object.entries and Object.fromEntries), then some(), every(), sometimes reduce() and for..of. It does all the work and looks the most readable for me.
@@LazyGod840 I'm curious why you prefer to not use side-effects. I get avoiding them when they might cause confusion, but imo breaking an .every() is easier to write and just as easy to read. No judgies, just wondering.
@@ontheruntonowhere That's interesting. I don't find it intuitive to use. Just the name "every" doesn't play well for that usage. But to clarify I don't have any strong arguments against it and I think everyone should write code that way and compare it to something like for loop to really see if it makes sense or not. For me it just doesn't seem "right" in this case. Also I would like to add one other thing I find even more important when working on a project and that is consistency. If I want to write some iteration with a break I would choose one way to do it and stick with it at least in that project. Still you want to use the most suitable way, but if it's just about picking one or another, pick the same one everytime. It helps both when writing and reading the code - one less thing to think about.
You can break & continue forEach loops as well, but it's very cryptic (one of them is `return true` and the other is `return false`, and I always confuse them and so will probably everyone reading the code)
I'm still pretty new at JS having just taken a freecodecamp course, but I found that with all the different looping methods they made me learn (recursion, forEach, for...of, .map) there were these particularities that made them useful, but for less situations than a general for loop. I found myself falling back on them when my attempts at an alternative failed. It became a sort of "if in doubt, for loop it" situation.
Just to add more options to the for loop. Hope that’s fun 🤩. We might also use `list.forEach(console.log);`. In some cases, you can’t pass in a function like that but you can in this case (e.g. where `this` isn’t used internally). We might also write ‘for (const item of list) console.log(item);’. I prefer this way as I could also use ‘await’ if the context is marked as ‘async’. And I don’t need the index value most of the time
I'm all about `for ... of` loops. They're criminally underrated. EDIT ignore the rest of this comment. I stand corrected in the context of the JavaScript implementation of forEach (though it could be made to work with a custom implementation as it does in other languages). See the following comment or two from other writers. Good call on the 'point free' version. `console.log` is already a function that can accept a single string argument-- there's no need to wrap in an arrow or anonymous function just to pass it to forEach().
My apology 🙏 The point-free one should work. BUT 😅 we will be logging whole lot more stuff because these are the signatures of the functions…. 🤪 console.log(obj1, /* ..., */ objN) array.forEach((element, index, array) => { /* ... */ })
I would be interested in hearing what people think/ use regarding async/ await vs thenables and promises. I know the "community" seems to have a lot to say about it but are people really using sync/ await. and if so to what extent? in new code only, or going back and refactoring old code as well... or maybe not at all?
async/await and then both are used in different use cases. it is not recommended to use async await on server. it is not good to block thread on server so better to use then/callbacks
I thought that was the whole point of async, so the thread does not have to wait. It is like sintactic sugar for the other two, so we don't get the weirdly indented code like we used to.
@@msdhaliwal that’s wrong. Async/await doesn’t block the loop. It’s a pause for that current function, but it still lets other requests or callbacks on the stack to continue processing. Once the promise is fulfilled or rejected it returns the value or throws the error.
Now to respond to you. We heavily use async/await. In fact most do. There are instances where you can’t use directly such as you have an array or things that need to be processed by an async function like a database process. You could then use a function to map over the array and return an array of promises which can then be awaited fulfillment, either success or reject, using Promise.allSettled. developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/allSettled
@@msdhaliwal Yea thats not how that works. await doesn't actual wait, it actually returns the thread to the pool to process other work until the work within the await is complete. When the task being awaiting on is complete a new thread is actually dispatched to pick up where the await left off.
I find self documenting code with the occasional comment works very well. It's also nice to have a summary of what exactly a function is doing. Especially when there's a summary of input variables. I think a blended approach works best.
Using of forEach() instead of for() is much much slower. Even on V8 it is more than 20% slower, which could be an issue when processing big data. If you use nested forEach() inside another forEach() all this grows drastically. And using of lambdas eveywhere is also not a good idea from optimization perspective. All these "() =>" are creating extra scopes and closulers which could lead to memory consumption and leaks.
Vasily, What you tell about 'for/of' and 'for/in' loops? ...and methinks, for portfolio index page most people never notice the lag in 50ms-ish. For the huge projects, yes, I guess lambdas and forEach loops are the worst choice (this loop cannot be controlled with continues and breaks or reversed).
@@DenisTrebushnikov I had to optimize processing of quite big data in JS. Especially under IE (which becomes dead next month, yahhh!!!). And the difference in 20% is signnificant. And it was radically increased in case of two or three nested loops. In this case performance degradation could reach 50-60%. Just due to forEach()+scope generation. So, the straightforward for() is the best solution in this case. But of course if I know that my array has no more than dozens or hundreds items, I use forEach().
16:10, I agree that going out of your way to be backward compatible is too far but a graceful fallback to a simpler version is easy to do without tools, for example: html > body a:link { color: var(--our-dim-link ) } html > body a:hover { color: var(--our-lit-link ) } Would gracefully fallback to system colours for links on anything that doesn't support ">" and "var()"
I will say that one common place to still use `for` loops is in an async function that needs to await something in each iteration. You can't do that with an array method, because the await would apply inside the callback and not actually await in the parent function before moving to the next iteration, so you have to use a normal `for` loop in that case. Regarding self-documenting code: before I started at my current job 4 years ago, I commented *everything.* Part of the reason was I was used to writing tutorial code for others to learn from, including exhaustively commenting any library code I wrote so people could dig into it and learn from that as well. Then I started my job, and day one we were told, "no comments allowed; don't ever write a single comment here". So now I've lost that habit and the only time I use comments are for FIXME/TODO notes and commenting out code for debugging. Honestly, I can see both sides of the argument, and if it were up to me, I wouldn't enforce either comments or lack thereof, as long as the resulting code plus any comments is understandable. Talking about browser compatibility, does anyone else remember how much of a pain it used to be to make AJAX calls cross-browser compatible? Specifically for older IE versions. I remember having a huge chunk of nested try-catch blocks to detect specific ActiveX components to define XMLHttpRequest on IE, and even then, XHR required multiple event listeners to fully use. Now all of that is boiled down to a single `fetch` call in every modern browser. Kids these days have it so easy! 😂
@@christianseyda1463 Yeah, sure, and that's a common technique for sequencing promises. But when you're not starting with promises in the first place, wrapping everything in promises and chaining them in a reduce is a messy overkill just to avoid a "for" loop 😂
Personally I don't understand the criticism that the standard for loop gets. I don't think that the syntax is hard to understand at all since every programming language I have learned explained the for loop in the exact same way, so you automatically get used it. Furthermore, the standard for loop gives you all the functionality that those fancy array functions (reduce, forEach, filter, map, etc) give you with the ability to combine it all in a single loop. I doubt that anyone would ever do: array.filter().map().reduce() as I assume this would iterate 3 times, whereas you can write 1 for loop that does all this in a single loop. For arrow functions, even though it is possible to write them in a way that has implicit returns, I am almost certain that most senior developers would advice to use brackets as it will maintain the same style in all your code. It also doesn't hurt readability in any way. in fact I would say that a junior developer might not realize that there is an implicit return unless they knew about it beforehand.
@@andrew1007 I mean you can argue with me but an arrow auto binds the execution context with this. A traditional function allows you to select what this is referring to using bind, apply and call.
13:57 To refine your example, you can make use the null coalasing operator (written as ??) and do something like console.log(idToUserMap[1]?.firstName ?? "User does not exist")
Remember when all the rage was writing IF statements reversed (E.g.: if (constant == variable))? Because people were writing one equal sign instead of 2? Now we have double question marks to worry about.
@@redguard128 yoda conditions lol. I think those were pretty effective at reminding people to use double equal over single equals. If you can remember to use yoda conditions, then you pretty much never needed to use them. Null coalasing is purely syntactic, and not using them only makes you write longer code
Personally I still use regular functions over arrow functions cuz arrow functions don't get hoisted when the code executes, the only case where I use arrow functions is when it's an anonymous function.
I use arrow functions when lambda style functionality is appropriate but they don't call out program structure as clearly if you are using function-based (rather than class-based) design
I actually generally prefer to write classic functions instead of arrow functions if they are intended to stand on their own. For example I may have a file "utils.ts" with global functions like formatDate(). Those I prefer to write using the function keyword instead of arrow functions. I find them to be more explicit and clear in their meanings, and thus easier to read at a glance. Arrow functions can be easily confused by other functionality if you don't look at it close enough. Meanwhile I prefer using arrow functions inside other functions or for simple one liners or when passing them as arguments (I wouldn't do .forEach(function() {}) hehe). So to summarize, I like arrow functions by default, except when I want to explicitly declare that this is indeed a pure function you can call at your own will.
Ok, you beat me to it ;) As I like the idea of self documenting code, I've stopped writing "e" and make it more clear calling the variable "event". Same for try/catch and exceptions.
@@JamesQQuick In my opinion, it is totally okay to call exceptions and events to "e". It is obvious enough from the context. Function and variable naming conventions having much more impact to the readability.
1000% on the sunsetting of "this". I've written one-off frameworks (circa 2010-2012) that heavily used the keyword this, to the extent that it was encapsulated as much as possible behind wrappers that used "call" and "apply". Co-devs would still often get "this" wrong in those frameworks no matter how many guards I put up, because, and let's be honest: it's ambiguous. So glad to see it fading away!
One thing about for/foreach loops. If you are looking for performance, for loops are superior. It is rare in js to look that deep into performance but it is a good thing to know, for loops are faster.
coming from php, i like to use "for (value of value_list)" like i do "foreach($value_list as $item){}" also from what i;ve read, "for (value of value_list)" has it's advantages in speed and other things, but i believe it's more related to usecase rather then "trend"
when i have component level functions, i like to define it with function keyword - for readability. i only like arrow functions now when they are small little functions maybe used within an object or something
I would caution against just using lambda functions because you prefer the way it looks, they should only really be used within other functions, because they are anonymous, so if they throw an error it will be harder to trace where the error occurred just based on the callstack.
Hm, not a big fan of many of the features you described here. 1. forEach removes your ability to use a return statement inside a loop, because all it will return is the forEach callback itself (which does nothing) This will work: const users = ["Abby", "Jess", "Greg", "John"] function hasUserCalledGreg(users){ for (const user of users) { if (user === "Greg") return true } return false } This won't: function hasUserCalledGreg(users){ users.forEach(user => if(user === "Greg") return true) return false } 2. Not a big fan of arrow functions, because they force you to store your functions inside variables, and therefore you lose all hoisting capabilities
@@StuffyX974hoisting means (roughly speaking) that functions are accessible no matter where you write them. You can imagine that they get hoisted (==pulled to the top, like when you raise a flag) to the top of the file before your code runs. So, you can even call functions before defining them. But (in oversimplified terms) only functions are hoisted, not variables. So, this will work: sayHi() function sayHi() {return "hi" } But, this will not: sayHi() const sayHi = () => "hi" // sayHi is not initialized The first sayHi was a function, so it got hoisted. The second sayHi was not a function, it was a variable that contained an anonymous function. So, it didn't get hoisted and therefore couldn't be called before its definition.
forEach also doesn't have an equivalent to the for loop break statement, if I am not mistaken. That being said, I still use forEach unless I need to use return or break within a loop. Very often I do not.
I've never understood the argument that forEach is easier to read than a regular for loop. I really don't think for loops are hard to understand and write; maybe if you're brand new to programming I guess? Theres pros and cons of using for loops and using forEach & array methods like map, but saying they're tedious/hard to read & write isn't a real downside
Agree... In some cases I think it makes the code easier or cleaner, but sometimes if I have to do complex stuff, like combining elements and things like that, I like also the good old for loop... But maybe I'm too dumb to grasp the map / filter / reduce...
Watch out that const does only prevent you to change the reference of the variable but not the value. const foo = { a: 1 }; foo = { a: 2 }; // runtime error foo.a = 2; // works
Yep. When I need full constants, I combine const with Object.freeze. And then I take it one step farther to create enums by setting the const/frozen object's properties to Symbols to ensure uniqueness 😃
@@IceMetalPunk keep in mind taht Object.freeze() is a shallow freeze and not a deep freeze. If you have complex objects you'll need to recurse through to ensure full immutability.
I tend to prefer using for over foreach. I find the functional-style functions names super confusing and sometimes it's very hard to read what is actually happening every iteration. Also, I don't really like things to fail silently, so the ? Is more often than not kinda useless to me.
for your example of: - names.forEach(name => console.log(name)) you could also use: - names.forEach(console.log) This will call the given function with all paremeters, which in the case of a forEach is 3 parameters, element, index, and reference array. so with console.log it will more than you expected as output, but for other functions (one you write yourself for example), it will work as expected, and can be used to shorten your code even more ;)
This will not do the same thing because the callback of forEach is being passed (element, index, array), so on every iteration, you will be calling console.log(element, index, array), so it will print something like: "element1" 0 ["element1","element2"] "element2" 1 ["element1","element2"]
@@DemanaJaire You mean returning the previous Promise and chaining a .then with the next, right? I actually never thought of that. I think you're right.
I started using more for...of loops, which are as easy to write as forEach, but don't require a callback and indentation is more straightforward. I think it's more legible in cases where you need a block of code, rather than a simple one-liner
I use arrows for functions that return a value and regular functions for one's that don't. I like my code to read like a sentence. if it's a unique callback, yeah I'll definitely use an anonymous arrow. The only other time I'll use an anonymous arrow is for my package scripts.
For a senior developer the newer syntax may make life a bit easier and the code cleaner but it does come with a cost. If you have a large code base to maintain on a budget you can't simply hire a Jr developer since syntax like lamba expressions et. al. may not yet be part of their repertoire. It's good for them as a learning experience but bad for the guy paying the developer's salaries if he needs to hire more experienced and expensive developers. I don't have a great solution for this but one suggestion may be to have a coding standard that everyone must adhere to. Then at advantageous times you could have the Jr developers pour through the code and upgrade older syntax to newer syntax. This imparts knowledge and experience while not requiring Jr developers to jump into more advanced level code. If the code standard is well maintained and documented new hires can be trained on the more advanced techniques by reviewing the code standards. I do like the self documenting code style of variable naming but I also appreciate detailed and well written comments when it is appropriate! Believe me we all forget the details of the code we write after awhile and returning to it for upgrades months or years later is much easier if there are well written comments.
I like the points you listed. However, it would have been good if you also included the for/in for/of loops, especially as the array functions are NOT asynchronous safe. While you can use async/await with the array functions, you do need to take additional steps/care to ensure the code is actually doing what you think. Typically, these additional steps end up making the code so much harder to read, the benefit of the array function is lost You will get cleaner, easier to read code using for/of or for/in. With regards to var v let/const, I'm a little more conflicted. For me, the most important thing is that the definition expresses as clearly as possible the scope of the variable. Sometimes, var is a more accurate description than let. However, I also acknowledge many people are over simplifying things and now see var as a 'red flag'. Part of the problem stems from var being 'auto hoisted' i.e. doesn't matter where you define var in your function, it will look like it was defined at the top where let is only defined from the point in the code until its scope ends.
in Js there are many built-in functions, for and forEach now most of the time they make room for .map and .reduce. But one must always consider the case
While I've switched to const and let for 99% of variables. Var is still massively useful for some situations that just would be way more annoying and feature much more boilerplate any other way. I've watched people struggle to find some way around using it because they've heard it is universally bad. Reminds me a lot of the tables to divs transition. Once watched someone struggle for days to accomplish something with divs that was basic functionality in a table. (back when CSS still couldn't accomplish everything tables could, circa mid 2000's) And again, that reminded me of the birth of image maps before that. Anyone remember image maps? I feel like no one uses them anymore but they are still valid and solve problems that are a huge pain any other way. Image maps + canvas + animations can be used to do some straight up magical things.
I think it's worth noting that for the second example (for loops) you can remove the arrow function completely and just do `names.forEach(console.log)`. names.forEach expects a function that takes a string and returns void, and console.log accomplishes this - so there's no need to wrap it in an arrow func.
as a person new to Javascript, 1) i like knowing the emphasis on *this* being used and understood is less than what I was led to believe 2) arrow functions are good and understandable for very simple functions but i like being explicit in my code and comment my code 3) not using var is a becoming outdated and i see less of it 4) i like vanilla javascript, i don't know why i would change, see no reason to
Typescript helps out a lot, it’s like sass for css. It basically a code translation for JavaScript and can help out with production. You can implement and create interfaces with it and when using it can be like a pre check for errors. I need to understand JavaScript more though to understand and want to use typescript
@@AlThePal78 I just finished a project where I used SASS and started learning TS this week. I came to the same conclusion with the TS and SASS comparison... as TS is compiled down to JS, conceptually similar to the way SASS is compiled to CSS. I'm struggling a little with syntax when using types in Classes, but understand the rest of the TS basics.
4): Good type systems are the best way to avoid certain kinds of bugs. It can replace countless tests with just a few little extra annotations and catch problems you didn't even think of. The whole software industry is moving more towards this approach because it's just so valuable (and JS is a dumpster fire without it)
14:00, I would just use the OR operator: var objs = [] console.log( (objs[0] || {}).name || "no such user" ); **Edit:** btw the OR operator, for loops and functions work in older versions of javascript also, whereas all this new syntax just says you don't give a toss about user choice
6:59, you gave 2 DIFFERENT listeners there, functions have an implicit "this" argument, whereas "statements" do not so it is normal for a "statement" to reference something entirely different to what would be fed into the function's "this" argument since a statement can only receive an expression
I think when you were covering optional chaining you might have meant to cover nullish coalescence for that ?? 'fallback message' but it seems it was missing.
Some really good advances in ES6 as I'm discovering. I still use "var". I get that some may find their sensibilities offended by what might be called its _scoping sloppiness,_ because the var(s) defined in the loop continue to be in scope afterwards, but I don't really see the harm. Also there are times it can be quite useful. Like when you want to get the terminal value of an iterator or expression without using extra logic to retrieve it. Anyway, thank you for a very interesting video.
Yeah the var implications with scope are just not how I naturally think about scope. Just my opinion. Honestly, it just comes down to whatever works for you and your team. Thanks for the comment!
For your example of an iterator, you can do that with let by simply declaring it just outside the loop. So for instance, if the iterator of a loop is `i`, you can just do `let i; for(i = 0; i < 100; ++i) {}` for instance, and then you can access that value after the loop. It's technically more code, but it's not more logic, just a simple "move the word 'let' up one line".
Arrow functions (and function expressions for that matter) are NOT hoisted and as such cannot be called before they are defined. I tend to use full function declarations at the root level of a module so that the order of the functions in the module does not matter. Plus named const arrow functions are actually longer to type: const a = () => function b ()
With regards to your last two points, try css frameworks such as tailwind or windicss. For debugging, if you have containerized your application for ease of development, it may not be possible to debug code in vscode. Firefox has debugging capabilities built in. You can select the line of js code you want to debug by going the "Debugger" tab and choosing the line of code from the left submenu under "Sources". I'm sure chrome has something similar as well.
@@TheAliendreamerbg do you have a link for this? I tried, and nothing was happening. To be fair, I was trying to debug code running in a remote location, so I might have needed to add more configuration to launch.json to make it work
If you are using TS or you write a Project in Node. Arrow functions, const/let instead of var and optional chaining are good ideas. If not, all this things are No Go's. Please use for-of because it performs better. If you are using a linter it wont allow shadow variables. What I do not anymore today is, building classes in functions with the prototype keyword and i don't use Promise.then if i can use async/await (so in Node or TS)
Hey James can you please let me know that should i master javascript by making more n more projects in plain js or after learning about js i should continue with framework and make project in the frameworks..???
I am a self thought developer it's not really all about making projects it's about learning fundamental js programming concepts and making our ideas clear about how things really work . If you want to show off some projects for your portfolios and resumes then you can go for some framework ( example react ) else to make your fundamentals strong and make your logic development better you can practice coding questions with vanilla js
Nice video! Great to hear that I am doing things right in my front end developing. What comes to debugging, I am really used to do it in chrome developer tools instead of IDE. I almost never use console logs for debugging purposes :)
JS is weakly typed - "A weakly typed language has looser typing rules and may produce unpredictable or even erroneous results or may perform implicit type conversion at runtime"
Javascript is dynamically typed. The types exist and are inferred at runtime, but you can see numbers coerced to booleans, strings etc. depending on use which would not happen implicitly in a strongly typed language (compiler errors). what TS provides is notations where the types are ambiguous and hinting where the types are inferred (at author time) to assist developers in understanding what the code is (or is supposed to be) doing.
@@akillersquirrel5880 No, a weakly typed language is something that can start reading random bits of data and interpreting them as a function call and corrupt your entire system. Like assembler or C. JavaScript _always_ knows what type a particular value is, there is an operator for that. It might have silly rules for conversion, but those conversions are only possible _because_ JavaScript is _strongly_ typed. 1 == "1" in a weakly typed language would just compare the bits to each other; but JavaScript knows one is a string and can apply quite complex conversions to it and come up with the idea that those two values are "equal". A weakly typed language is more likely to say 70 == 'F' is true.
@@dtkedtyjrtyj If you only define "weakly typed" to mean that, then sure, I guess you're right. But by most understandings of the term "weakly typed", implicit type conversion is enough to make JS be considered weakly typed -- en.wikipedia.org/wiki/JavaScript#Weakly_typed en.wikipedia.org/wiki/Strong_and_weak_typing
@@akillersquirrel5880 I suppose it is a spectrum, but I don't see how a language that _always_ knows what type every value is and converts exactly according to a detailed spec can be called anything but strongly typed. I think a lot of people don't understand what the difference between dynamic and weak typing is, and the term has been watered down.
Thanks for teaching me about scoping with `const`--I never caught that until now. Regarding the getElementById() from the Document Object Model (DOM which applies more in the context of web pages in browsers than e.g., Node.js): the `id` attribute is supposed to uniquely identify an element in the page. It's invalid HTML to have more than one element with the same id. Therefore, getElementById() will only return a single element (if present it's present in the page). If you wanted an example of an array of elements from the DOM (without having to wrap a single element in a list literal), you could call getElementsByClassName(). The same class name can be assigned to multiple elements across the page so that function returns an array (which might still be empty or only have a single element if that's all that was defined on the page).
Please use at least coderunner in VSCode to show console output, that white rectangle from sour switches to browser is quite painful (not to mention interrupts explanation flow, if you write oneliner and show alternative syntax, no need to proof output.
#2, 3 and 4 are the three biggest critiques or things that I hate the most about JavaScript. A little part of me dies inside anytime I see someone using the foreach method. Call me old fashioned but I don't think it has any advantages and can easily be hard to understand. Arrow functions are the same... Just why? What's wrong with `function myFunction() {}`? Sure I suppose you could save a few key strikes but most of the time, my functions are... well, functions... why call it a variable? Sure technically you can reference it like a variable but I like to think of things from a conceptual perspective most of the time... it's a function... It takes arguments and returns a result... so in order to self document, call it such in your code. And as far as `this` goes... the fact that this is even a problem in the first place tells you all you need to know about the language. When you can't implement object oriented concepts for fear of referencing the wrong object, you've broken OOP. On that last point... I suppose JS doesn't really know if it wants to be OOP or FP but that's even another problem I have with it. I've seen developers moving more and more in a functional direction with JS (ex. React is huge with this in my experience). Yet literally everything in JS is an object... Heck there's an entire notation named after it to represent objects. It's like it's trying to be an object oriented language but everyone knows it sucks at that so they use it as a functional language. I didn't mean to rant on JS when I woke up this morning but apparently I needed to.
I Definitely use the higher order functions that are in javascript but I def still use for loops. Sometimes it's easier to work with, especially if I need the index or if I need to do something more complex.. There is work arounds to get the index etc but it's usually more complex than just writing for loops which In all honesty, takes like 10 seconds to write the syntax to get a loop started. .. you can also do it in reverse, even or odd, start at an index or just the first 10 items in the array etc..
Holy crap! I LOVE the examples of how to get away from "this". I definitely understand what it is and why it's used when it is. But, your explination and solutions to it seem much better! Love it thanks :)
For self documenting code there is also the decision (personal) about style. For example whether or not to say it's a "Map" or just use "usersById", the latter is my preference.
I liked forEach at first, but have stopped using it due to needing synchronous functions, which could go back to the old for loop or some of the newer ones. Optional Chaining I love the concept, but some legacy browsers do not like it still, and working in certain companies means you can not use it. Yes, there might be tools, but not allowed to use them sometimes. Have started loving console.time/table over log, only reason I use log is if I am just looking to see if it gets to the point. Debug I still do in the browser, just find it so much easier to mess with stuff there.
Was meaning asynchronous, due to you want might want it to wait before doing the next part of the code. You also might want it to be in an expected order.
I use a naming pattern of usersById for the map/dict and usersAllIds for the (sorted) array of UUIDs. Useful where you need an array of user objects, that you can always .map the allIds and lookup the byId
`forEach` will pass some parameters you're probably not expecting if you do that. I like a tacit style just as much as the next guy, but you have to make sure the target function isn't going to unintentionally use the additional parameters that `forEach` will provide.
this is all fairly subjective. i moved back to named functions as i find them easier to read. Others would have had the opposite experience. if you are a new developer do not take this video seriously. do what works for you - best practice is usually just personal preference.
yes, the choices are subjective so also the way of programming
Named functions can also be called before they are declared, which can be seen as a good or bad thing. I think it’s good because it allows developers to organize code more freely.
Don't do what works for you, follow the coding style guide for the project you are working on and be consistent with the existing code base. If you are the sole dev the do what floats your boat, it's your codebase.
Exactly, Im a much bigger fan of "good practices" or "common practices", "best practices" often warrant breaking
I typically use named functions for functions that I specify on the global scope and use arrow functions for anything that's inside a function or prototype and especially for anonymous functions.
You only talked about one use case of "this" in JavaScript. In this case we can sometimes get rid of it, but we need "this" a lot in object-oriented programming in JS. For example, when we have a "Circle" class and refer to a radius of a Circle instance inside of a class method, we write this.radius. This use case is also less confusing and will probably not go away any soon.
You're right however, JS is not an OOP lang by nature. Of course, it is a matter of preference, and if you go with the classes, then expect to use "this". In my experience, JS is absolutely turning into more like an FP style language (which I prefer too), just look at the functional pattern improvements in the last couple of years. I think classes are interchangeable with functions in all cases without exception. But again, it is a matter of preference. People coming from Java/.Net world, tend to use more classes. Interesting fact though, they tend to turn into FP shortly :) James' video highlights the issues of "this" in the context of functional style, which is quite real and been here in the last 25 years or so.
This video is about what people have stopped doing in 2022. We stopped doing OOP in JS is like the 1800s.
@@SkullTraill I am new to JS, can you please explain why? Thanks!
One of my favorite things about Javascript is the ability to add new methods to existing objects via _prototype_ functions.
Which often require use of "this".
@@the-suspect For one you don't really need OOP in JS and I find it much simpler to just avoid it. It'll most likely also lead to better code once you escaped the OOP mindset.
Nowadays it's all about clearly typed objects & functions in TS, I haven't met anyone who uses OOP JS outside of web development classes.
Re: “self-documenting code”, Code commenting is more valuable if it describes “why” rather than “what”. I don’t need a code comment to just translate into English what the code is doing, but explaining the _intention_ of the programmer serves to double-check that the code is doing that it’s _meant_ to do.
In that regard the comment is just as much for the original programmer as it is for the “reader”. If the programmer writes their intention, the code tends to be easier to write, with bugs and flaws becoming apparent. If you can’t describe both _what_ and _why_ you’re writing a line of code that way, it’s a red flag that you haven’t thought it through. Debugging both your own and others’ code is much easier with “why”-style comments.
Turns out, after decades of commenting this way, I’m now being rewarded by better results from GitHub CoPilot too :)
"Tell the nice AI why you want this function. It's okay, he'll be gentle."
I disagree somewhat in this case. You should explain 'why' something should or should not do something. In this case, though, it's a data structure (object literal). It doesn't do anything, it just 'is'.
Given that, i think it's good to just define exactly what it is.
I usually use 'By' as a convention, though. In this case, the example would be `usersById`.
EDITED: Sorry. I meant what was here as a top-level comment. Moving it...
Agreed that the example in the video isn't the best for this point.
Saying that, I do over-comment my code intentionally -- most statements get a comment; or at least, every _action_ gets a comment. The reason being that if I just commented sections I thought needed commenting, I'd miss out those that seem obvious to me, but might not be to others.
Admittedly it does feel a bit stupid writing those comments at times, but if everything else is diligently commented it looks weird. I usually just throw in a joke or some self-deprecation instead.
A colleague once summed it up as making comments "a good director's commentary track rather than an audio-description track."
“Why, not what” is my mantra for comments too.
When getting large data sets, the classic "for" loop will outperform forEach.. etc. So if performance is struggling, this is one of the first changes to make. Maybe this will change in JS over time, but forEach, etc. have lagged behind for years.
Not only that, but in place of using reduce (and forEach), a for loop is often more readable. Especially when using iterator (`x of y`). I prefer using for loops for readability in complex transformations, filtering and/or reduction.
I was about to write the same thing. Not using for...i AT ALL, is just plain wrong.
I don't think the difference is meaningful even in huge datasets. Benchmarks don't show that it sbetter.
But the benefit of forEach is that it's more clear what's happening and has less boilerplate.
@@thekwoka4707 but surely the forEach is just a wrapper that puts all the boiler plate under the hood?
Came here to say this, thank you! Also, defining a function inside another creates closure for ALL variables in outer function and that's (can be) very memory inefficient
For self-documenting dictionary/Map pairings of key => value, I usually use 'By' as a name convention. In this case, the example would be `usersById`.
Object literals in JS can go either way depending on how you're using them. If you're using them as a Map, with dynamic key values, then the convention above works. It's less applicable, though, when using the object like a class-instance or struct where you have hard-coded references to expected property names.
I name my maps the same way, except i use all lowercase.
@@Dziaji All lowercase? Gross.
@@vickmackey24 you like slowing yourself down with the shift key? canyoureadthis?
Re: For loops….You may want to note that array methods (map, forEach etc) dont work inside generator functions, you have to use for…of loops in generator Fns to iterate arrays ie. in a [Symbol.Iterator] method.
forEach is also a lot slower than map or a regular for loop
...and you also can't "await" in a forEach callback function, since it is a synchronous function. In this case a for..of or a for-loop is necessary
@@marksmod I usually do a map of the array so I can Promise.all it when it comes to asyncronous for each!
@@marksmod you can await in a reduce method, but I still don't recommend it. awaiting in a for of loop is much easier and intuitive.
For the commenting code one, I always and have always tried to be nice and specific with my naming. However coming from a data scientist/R background, I also still think commenting is important throughout the code. What's obvious to you from a name might not be obvious to the next person as knowledge bases can vary, so nothing wrong with a little 5 or 6 word descriptor for a section of code. Plus, in the RStudio IDE you can collapse code via comment headings and have markdown heading levels to give a full document outline to your code, so it's just a good habit I'm in to keep my code clean, organised and navigable, even in web-based coding.
Yeah I agree. I don’t think they go away completely. I do think we probably see less commenting than we would have five years ago for example.
@@JamesQQuick For me, the steps are three: a) make it as obvious as possible what your code is doing, b) don't comment what is obvious, c) comment on the not-so-obvious facts about your code. In my experience, there are a lot of those cases, where you need to explain the "why" but not the "what".
I generally avoid commenting "what" my code is doing. If I have to explain what it's doing, it's too complicated. Sometimes, however, I need to do things that are a bit weird, a bit off standard practice, a bit new, or I simply can't think of a way to write the code that isn't hard to understand. This is when I will at least start with a comment indicating "why" I wrote the code that way. This way the next dev who comes along (possibly me), will know the reason I had for writing this and that will give insight into how to fix it, if possible. If it's overly complex, then I will add a `TODO:` in the comment to indicate that this code needs some love when we figure out how to provide it.
I've found that code that is riddled with too many comments becomes very distracting and it actually becomes harder to read with all the commentary around it, so I avoid comments when possible.
Great list. My favorite trend is is getting away from function parameter lists, and just passing one object that can then be deconstructed. It's great because all parameters are named, making them "self documenting".
I make apps for engineering calculations and I do the same.When all input is complete I create an "item" object that I can feed to multiple calculation steps. Each step grabs
its own input and adds its output. The main challenge is finding meaningful and non-conflicting names for all properties.
5:16
Given your point about increased use of typescript, plain functions still play a major role when defining function overloads in typescript. Overloads do not work with arrow functions.
Interesting. I hadn't thought about overloaded functions. Thanks for clarifying!
Well yea. You don't overload functions you overload methods. You don't define a method using the traditional "function" syntax OR arrow function syntax in the first place.
@@peteredmonds1712 you are conflating overload and override.
Override is something you do to change the behaviour of a method, in a subclass I.e. you are overriding the default inherited behaviour. The parameters and return type stays the same.
Overload can only be done to functions. A function overload declares an alternate set of parameters and/or return type for that function. For example, a function that could either take a string or an array could have two overloads: one which has a parameter type of string and another which has a parameter type of array. The function implementation still stays the same, but the overloads serve as a hint to the user of how they can call the function.
A language like javascript will not be able to do overloads because it has no type system to disambiguate the overloads, however most typed languages have this feature, including typescript. Before typescript, it was up to the author of the function to include in their documentation that this function can take two types of parameters, but now with typescript and overloads, the code becomes self-documenting.
One can shorten the for loop example code even more like this
02:30 - For Loops
names.forEach(console.log)
This will pass in the item from the array into the function which is console.log
Useful for cases like,
listOfItems.filter(Boolean)
filters out falsy values
Of course, the problem here is that console.log takes variable arguments. And the callback for forEach is actually supplied 3 arguments. In other words, it will print the name, but it will also add the index and the initial array as well.
@@ChrisPikul510 Interesting insight. Nice one
2:36
There is also the for...of loops which can act as an alternative to foreach loops. I think typescript even converts forEach loops to use for...of when targeting es6 and above.
For of loops are particularly useful for working with generators.
Dont forget the for…in loop if you want a just a list of keys.
Regardless of of what features are outdated and not in common use, still, I think every developer, especially beginners, should learn, understand and familiarise themselves with these concepts (var, plain functions, for loops, this keyword etc.), before starting implementing the new alternatives.
Yeah I think that's a good point!
@Tim Davis I agree that this is not necessarily a best practices list. So much of it is opinion based which is fine as long as it works for your. BUT I would highly cautious taking it upon yourself to determine what/who "real" developers are.
I must admit I am old school and still do most of these things: I still write vanilla Js, I still use a lot of For loops, still write full Functions and only sparingly use arrows F, still comment code (Using JSDocs), I use minimal optional chaining as I still find a need to do something if a value does not exist, and I still heavily use console log to debug, although I am progressively leveraging Vs code built in tools. The only thing I have stopped doing 100% is the use of var.
Thanks for sharing!
I like forEach when I need all values in an array, however, good old fashioned for loops are useful when you need to break a loop
Using 'every()' instead of 'forEach()' - allows for 'breaking':
[ ].every((element, index, array) => {
//do your test here
if (breakLoopCondition){
//do something
return false; //break loop
} else {
//continue loop
return true;
}
});
I prefer using every() without side effects (as the name says - to check every element for something).. same principle as map() etc.
If I need to use break or would have side effect in function I actually prefer a for loop (usually for..of).
When I think about it, I dont even like to use forEach(). I use map() (even for working with object as a map using Object.entries and Object.fromEntries), then some(), every(), sometimes reduce() and for..of. It does all the work and looks the most readable for me.
@@LazyGod840 I'm curious why you prefer to not use side-effects. I get avoiding them when they might cause confusion, but imo breaking an .every() is easier to write and just as easy to read. No judgies, just wondering.
@@ontheruntonowhere That's interesting. I don't find it intuitive to use. Just the name "every" doesn't play well for that usage.
But to clarify I don't have any strong arguments against it and I think everyone should write code that way and compare it to something like for loop to really see if it makes sense or not. For me it just doesn't seem "right" in this case.
Also I would like to add one other thing I find even more important when working on a project and that is consistency. If I want to write some iteration with a break I would choose one way to do it and stick with it at least in that project. Still you want to use the most suitable way, but if it's just about picking one or another, pick the same one everytime. It helps both when writing and reading the code - one less thing to think about.
You can break & continue forEach loops as well, but it's very cryptic (one of them is `return true` and the other is `return false`, and I always confuse them and so will probably everyone reading the code)
5:11, again, no, just no, code should be CLEAR about what it does, that is anything BUT clear
I'm still pretty new at JS having just taken a freecodecamp course, but I found that with all the different looping methods they made me learn (recursion, forEach, for...of, .map) there were these particularities that made them useful, but for less situations than a general for loop. I found myself falling back on them when my attempts at an alternative failed. It became a sort of "if in doubt, for loop it" situation.
Just to add more options to the for loop. Hope that’s fun 🤩.
We might also use `list.forEach(console.log);`. In some cases, you can’t pass in a function like that but you can in this case (e.g. where `this` isn’t used internally).
We might also write ‘for (const item of list) console.log(item);’. I prefer this way as I could also use ‘await’ if the context is marked as ‘async’. And I don’t need the index value most of the time
I'm all about `for ... of` loops. They're criminally underrated.
EDIT ignore the rest of this comment. I stand corrected in the context of the JavaScript implementation of forEach (though it could be made to work with a custom implementation as it does in other languages). See the following comment or two from other writers.
Good call on the 'point free' version. `console.log` is already a function that can accept a single string argument-- there's no need to wrap in an arrow or anonymous function just to pass it to forEach().
My apology 🙏 The point-free one should work. BUT 😅 we will be logging whole lot more stuff because these are the signatures of the functions…. 🤪
console.log(obj1, /* ..., */ objN)
array.forEach((element, index, array) => { /* ... */ })
@@steamer2k319 for loops either introduce mutability or side effects. No one needs that.
@@DemanaJaire foreach doesn't protect against that either
which code theme u are using?
Shades of Purple
I would be interested in hearing what people think/ use regarding async/ await vs thenables and promises. I know the "community" seems to have a lot to say about it but are people really using sync/ await. and if so to what extent? in new code only, or going back and refactoring old code as well... or maybe not at all?
async/await and then both are used in different use cases. it is not recommended to use async await on server. it is not good to block thread on server so better to use then/callbacks
I thought that was the whole point of async, so the thread does not have to wait. It is like sintactic sugar for the other two, so we don't get the weirdly indented code like we used to.
@@msdhaliwal that’s wrong. Async/await doesn’t block the loop. It’s a pause for that current function, but it still lets other requests or callbacks on the stack to continue processing. Once the promise is fulfilled or rejected it returns the value or throws the error.
Now to respond to you. We heavily use async/await. In fact most do. There are instances where you can’t use directly such as you have an array or things that need to be processed by an async function like a database process. You could then use a function to map over the array and return an array of promises which can then be awaited fulfillment, either success or reject, using Promise.allSettled.
developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise/allSettled
@@msdhaliwal Yea thats not how that works. await doesn't actual wait, it actually returns the thread to the pool to process other work until the work within the await is complete. When the task being awaiting on is complete a new thread is actually dispatched to pick up where the await left off.
I find self documenting code with the occasional comment works very well.
It's also nice to have a summary of what exactly a function is doing. Especially when there's a summary of input variables.
I think a blended approach works best.
What vscode extension is that that shows you in red if you're missing a bracket etc?
Can you tell me what theme are you using, please ?
Could you please share the VS code extension on the 5:00 ?
Using of forEach() instead of for() is much much slower. Even on V8 it is more than 20% slower, which could be an issue when processing big data.
If you use nested forEach() inside another forEach() all this grows drastically.
And using of lambdas eveywhere is also not a good idea from optimization perspective. All these "() =>" are creating extra scopes and closulers which could lead to memory consumption and leaks.
Exactly. Same thing i observed too.
Vasily, What you tell about 'for/of' and 'for/in' loops? ...and methinks, for portfolio index page most people never notice the lag in 50ms-ish. For the huge projects, yes, I guess lambdas and forEach loops are the worst choice (this loop cannot be controlled with continues and breaks or reversed).
@@DenisTrebushnikov I had to optimize processing of quite big data in JS. Especially under IE (which becomes dead next month, yahhh!!!). And the difference in 20% is signnificant. And it was radically increased in case of two or three nested loops. In this case performance degradation could reach 50-60%. Just due to forEach()+scope generation.
So, the straightforward for() is the best solution in this case. But of course if I know that my array has no more than dozens or hundreds items, I use forEach().
@@VasilyPavlik so what for "for/of" & "for/in"? Are they similar to pythons one?
@@VasilyPavlik Its actually quite obvious that forEach is slow because of the required function call. Any experience developers can tell that easily.
16:10, I agree that going out of your way to be backward compatible is too far but a graceful fallback to a simpler version is easy to do without tools, for example:
html > body a:link { color: var(--our-dim-link ) }
html > body a:hover { color: var(--our-lit-link ) }
Would gracefully fallback to system colours for links on anything that doesn't support ">" and "var()"
I will say that one common place to still use `for` loops is in an async function that needs to await something in each iteration. You can't do that with an array method, because the await would apply inside the callback and not actually await in the parent function before moving to the next iteration, so you have to use a normal `for` loop in that case.
Regarding self-documenting code: before I started at my current job 4 years ago, I commented *everything.* Part of the reason was I was used to writing tutorial code for others to learn from, including exhaustively commenting any library code I wrote so people could dig into it and learn from that as well. Then I started my job, and day one we were told, "no comments allowed; don't ever write a single comment here". So now I've lost that habit and the only time I use comments are for FIXME/TODO notes and commenting out code for debugging. Honestly, I can see both sides of the argument, and if it were up to me, I wouldn't enforce either comments or lack thereof, as long as the resulting code plus any comments is understandable.
Talking about browser compatibility, does anyone else remember how much of a pain it used to be to make AJAX calls cross-browser compatible? Specifically for older IE versions. I remember having a huge chunk of nested try-catch blocks to detect specific ActiveX components to define XMLHttpRequest on IE, and even then, XHR required multiple event listeners to fully use. Now all of that is boiled down to a single `fetch` call in every modern browser. Kids these days have it so easy! 😂
now we have the handsome 'for of'
I use "for of" if I want to use async code
await Promise.all(arr.map(item => item.willReturnPromise()))
you can loop in a reduce, with a Promise as start value for mapping over array and awaiting each value before the next
@@christianseyda1463 Yeah, sure, and that's a common technique for sequencing promises. But when you're not starting with promises in the first place, wrapping everything in promises and chaining them in a reduce is a messy overkill just to avoid a "for" loop 😂
What is the extension that shows those inline errors/warnings?
Personally I don't understand the criticism that the standard for loop gets. I don't think that the syntax is hard to understand at all since every programming language I have learned explained the for loop in the exact same way, so you automatically get used it. Furthermore, the standard for loop gives you all the functionality that those fancy array functions (reduce, forEach, filter, map, etc) give you with the ability to combine it all in a single loop. I doubt that anyone would ever do: array.filter().map().reduce() as I assume this would iterate 3 times, whereas you can write 1 for loop that does all this in a single loop.
For arrow functions, even though it is possible to write them in a way that has implicit returns, I am almost certain that most senior developers would advice to use brackets as it will maintain the same style in all your code. It also doesn't hurt readability in any way. in fact I would say that a junior developer might not realize that there is an implicit return unless they knew about it beforehand.
I completely agree with this. I think the assumption that less code is better code is a massive oversimplification.
Hmm. I thought this way coming from C to JS, but I’ve completely flipped. To me, readability is inverse to the amount of code/symbols after the arrow.
whats up with the video compression? looks like its in 480p
What font are you using in VS? Looks nice, nice video
There are situations where you don’t want to use arrow functions. Auto binding this is not always preferred
esp if you are vue dev ;)
There's no such thing as autobinding. Arrow functions intrinsically have no context. Look it up on MDN
@@andrew1007 I mean you can argue with me but an arrow auto binds the execution context with this. A traditional function allows you to select what this is referring to using bind, apply and call.
@@andrew1007 actually I am showing my years of react using class properties with arrow. You are correct
Which theme are you using? Looks really nice :)
Shades of Purple
13:57
To refine your example, you can make use the null coalasing operator (written as ??) and do something like
console.log(idToUserMap[1]?.firstName ?? "User does not exist")
Be careful of using too many inline operators in JS I'd mention. They make code less maintainable.
Remember when all the rage was writing IF statements reversed (E.g.: if (constant == variable))? Because people were writing one equal sign instead of 2? Now we have double question marks to worry about.
@@redguard128 yoda conditions lol. I think those were pretty effective at reminding people to use double equal over single equals. If you can remember to use yoda conditions, then you pretty much never needed to use them.
Null coalasing is purely syntactic, and not using them only makes you write longer code
Hey Guys. In my job we are using flowTypes instead Ts. Are both similar? or Ts is much?
Personally I still use regular functions over arrow functions cuz arrow functions don't get hoisted when the code executes, the only case where I use arrow functions is when it's an anonymous function.
I use arrow functions when lambda style functionality is appropriate but they don't call out program structure as clearly if you are using function-based (rather than class-based) design
I actually generally prefer to write classic functions instead of arrow functions if they are intended to stand on their own.
For example I may have a file "utils.ts" with global functions like formatDate(). Those I prefer to write using the function keyword instead of arrow functions. I find them to be more explicit and clear in their meanings, and thus easier to read at a glance. Arrow functions can be easily confused by other functionality if you don't look at it close enough.
Meanwhile I prefer using arrow functions inside other functions or for simple one liners or when passing them as arguments (I wouldn't do .forEach(function() {}) hehe). So to summarize, I like arrow functions by default, except when I want to explicitly declare that this is indeed a pure function you can call at your own will.
For loops are FINE. Don’t mess with for loops
Ok, you beat me to it ;)
As I like the idea of self documenting code, I've stopped writing "e" and make it more clear calling the variable "event". Same for try/catch and exceptions.
Haha yeah I guess I botched the demo when I then used “e” lol great points!
@@JamesQQuick In my opinion, it is totally okay to call exceptions and events to "e". It is obvious enough from the context. Function and variable naming conventions having much more impact to the readability.
I think at this point e has just become shorthand for event for 99% of javascript developers. Its shorter to write, and everybody knows what it means
@@HorsiMusic True. It is just funny that I did that one after saying "Always spell out variable names" lol
1000% on the sunsetting of "this". I've written one-off frameworks (circa 2010-2012) that heavily used the keyword this, to the extent that it was encapsulated as much as possible behind wrappers that used "call" and "apply". Co-devs would still often get "this" wrong in those frameworks no matter how many guards I put up, because, and let's be honest: it's ambiguous. So glad to see it fading away!
What's your font extension name? Btw nice tuts!
One thing about for/foreach loops. If you are looking for performance, for loops are superior. It is rare in js to look that deep into performance but it is a good thing to know, for loops are faster.
Yeah. Also a FOR loop is hard to read?! What people are writing software nowadays?
coming from php, i like to use "for (value of value_list)" like i do "foreach($value_list as $item){}"
also from what i;ve read, "for (value of value_list)" has it's advantages in speed and other things, but i believe it's more related to usecase rather then "trend"
when i have component level functions, i like to define it with function keyword - for readability. i only like arrow functions now when they are small little functions maybe used within an object or something
I would caution against just using lambda functions because you prefer the way it looks, they should only really be used within other functions, because they are anonymous, so if they throw an error it will be harder to trace where the error occurred just based on the callstack.
I don't write javascript but
i kind of liked this "forEach" and so i added it to my custom dynamic array class in c++. :)
Hm, not a big fan of many of the features you described here.
1. forEach removes your ability to use a return statement inside a loop, because all it will return is the forEach callback itself (which does nothing)
This will work:
const users = ["Abby", "Jess", "Greg", "John"]
function hasUserCalledGreg(users){
for (const user of users) { if (user === "Greg") return true }
return false
}
This won't:
function hasUserCalledGreg(users){
users.forEach(user => if(user === "Greg") return true)
return false
}
2. Not a big fan of arrow functions, because they force you to store your functions inside variables, and therefore you lose all hoisting capabilities
That seems to be a good point. I still need to understand hoisting and its advantages.. could you give me an example please ? Thank you 🙂
@@StuffyX974hoisting means (roughly speaking) that functions are accessible no matter where you write them. You can imagine that they get hoisted (==pulled to the top, like when you raise a flag) to the top of the file before your code runs.
So, you can even call functions before defining them. But (in oversimplified terms) only functions are hoisted, not variables.
So, this will work:
sayHi()
function sayHi() {return "hi" }
But, this will not:
sayHi()
const sayHi = () => "hi"
// sayHi is not initialized
The first sayHi was a function, so it got hoisted. The second sayHi was not a function, it was a variable that contained an anonymous function. So, it didn't get hoisted and therefore couldn't be called before its definition.
forEach also doesn't have an equivalent to the for loop break statement, if I am not mistaken. That being said, I still use forEach unless I need to use return or break within a loop. Very often I do not.
@@yadusolparterre well explained bro. it's correct!
Thank you@@yadusolparterre it helped me, i'll dig deeper to get a good grasp
I've never understood the argument that forEach is easier to read than a regular for loop. I really don't think for loops are hard to understand and write; maybe if you're brand new to programming I guess? Theres pros and cons of using for loops and using forEach & array methods like map, but saying they're tedious/hard to read & write isn't a real downside
Agree... In some cases I think it makes the code easier or cleaner, but sometimes if I have to do complex stuff, like combining elements and things like that, I like also the good old for loop... But maybe I'm too dumb to grasp the map / filter / reduce...
great old FOR loop is not hard to read, moreover it gives more control but I guess forEach makes simple straightforward codes shorter.
Watch out that const does only prevent you to change the reference of the variable but not the value.
const foo = { a: 1 };
foo = { a: 2 }; // runtime error
foo.a = 2; // works
Yes, this is very true!
Yep. When I need full constants, I combine const with Object.freeze. And then I take it one step farther to create enums by setting the const/frozen object's properties to Symbols to ensure uniqueness 😃
@@IceMetalPunk keep in mind taht Object.freeze() is a shallow freeze and not a deep freeze. If you have complex objects you'll need to recurse through to ensure full immutability.
I tend to prefer using for over foreach. I find the functional-style functions names super confusing and sometimes it's very hard to read what is actually happening every iteration.
Also, I don't really like things to fail silently, so the ? Is more often than not kinda useless to me.
Also does't have the stack overhead of functions calls.
for your example of:
- names.forEach(name => console.log(name))
you could also use:
- names.forEach(console.log)
This will call the given function with all paremeters, which in the case of a forEach is 3 parameters, element, index, and reference array.
so with console.log it will more than you expected as output, but for other functions (one you write yourself for example), it will work as expected, and can be used to shorten your code even more ;)
This will not do the same thing because the callback of forEach is being passed (element, index, array), so on every iteration, you will be calling console.log(element, index, array), so it will print something like:
"element1" 0 ["element1","element2"]
"element2" 1 ["element1","element2"]
Thanks for another great video! If I may ask, what font do you use for VSC? It looks so Nice to my eyes!
there was a lot more to unpack in the regular function vs arrow function, in some cases they are not as interchangeable as one would think.
What vscode theme is that? :o
Shades of Purple
Hi! If use sveltekit and supabase for my big project, then it will be safe and fast? Do you think this stack is a good idea?
Documents.querySelector() not a thing yet?
For loops are really handy inside an async function, when you have to do some sequencial async stuff for each element inside an array.
You can use reduce for that.
@@DemanaJaire You mean returning the previous Promise and chaining a .then with the next, right?
I actually never thought of that. I think you're right.
@@juliohintze595 You can also use Array.prototype.map, and wrap it in Promise.all to wait them for all to finish in parallel
@@juliohintze595 yes, exactly that.
I started using more for...of loops, which are as easy to write as forEach, but don't require a callback and indentation is more straightforward. I think it's more legible in cases where you need a block of code, rather than a simple one-liner
I'm a fan of reversing names like idToUserMap since reading it in Clean Code. It makes uses of them more clear.
const user = usersById[id]
Same!
what about for (const item of array ) {} though
I use arrows for functions that return a value and regular functions for one's that don't. I like my code to read like a sentence. if it's a unique callback, yeah I'll definitely use an anonymous arrow. The only other time I'll use an anonymous arrow is for my package scripts.
What's your vscode theme?
Shades of Purple
For a senior developer the newer syntax may make life a bit easier and the code cleaner but it does come with a cost. If you have a large code base to maintain on a budget you can't simply hire a Jr developer since syntax like lamba expressions et. al. may not yet be part of their repertoire. It's good for them as a learning experience but bad for the guy paying the developer's salaries if he needs to hire more experienced and expensive developers. I don't have a great solution for this but one suggestion may be to have a coding standard that everyone must adhere to. Then at advantageous times you could have the Jr developers pour through the code and upgrade older syntax to newer syntax. This imparts knowledge and experience while not requiring Jr developers to jump into more advanced level code. If the code standard is well maintained and documented new hires can be trained on the more advanced techniques by reviewing the code standards.
I do like the self documenting code style of variable naming but I also appreciate detailed and well written comments when it is appropriate! Believe me we all forget the details of the code we write after awhile and returning to it for upgrades months or years later is much easier if there are well written comments.
Agreed !
Junior developers should be learning these features anyway.
Anyone know what that theme is?
Shades of Purple
I like the points you listed. However, it would have been good if you also included the for/in for/of loops, especially as the array functions are NOT asynchronous safe. While you can use async/await with the array functions, you do need to take additional steps/care to ensure the code is actually doing what you think. Typically, these additional steps end up making the code so much harder to read, the benefit of the array function is lost You will get cleaner, easier to read code using for/of or for/in. With regards to var v let/const, I'm a little more conflicted. For me, the most important thing is that the definition expresses as clearly as possible the scope of the variable. Sometimes, var is a more accurate description than let. However, I also acknowledge many people are over simplifying things and now see var as a 'red flag'. Part of the problem stems from var being 'auto hoisted' i.e. doesn't matter where you define var in your function, it will look like it was defined at the top where let is only defined from the point in the code until its scope ends.
There is nothing var does that you want, that let doesn’t do.
I agree...var has it's own uses in the "global" scope of a script. They should rename it to "global"
in Js there are many built-in functions, for and forEach now most of the time they make room for .map and .reduce. But one must always consider the case
10:36, I never noticed var didn't follow scope, guess I'll think of it as a a function global from now on
While I've switched to const and let for 99% of variables. Var is still massively useful for some situations that just would be way more annoying and feature much more boilerplate any other way. I've watched people struggle to find some way around using it because they've heard it is universally bad. Reminds me a lot of the tables to divs transition. Once watched someone struggle for days to accomplish something with divs that was basic functionality in a table. (back when CSS still couldn't accomplish everything tables could, circa mid 2000's) And again, that reminded me of the birth of image maps before that.
Anyone remember image maps? I feel like no one uses them anymore but they are still valid and solve problems that are a huge pain any other way. Image maps + canvas + animations can be used to do some straight up magical things.
Like...what though?
Anything that would use var can just use let higher up in the block stack
Regarding "optional chaining", any suggestion for if I need to perform somehting different like redirect() if (!idToUserMap) else render()?
I think it's worth noting that for the second example (for loops) you can remove the arrow function completely and just do `names.forEach(console.log)`. names.forEach expects a function that takes a string and returns void, and console.log accomplishes this - so there's no need to wrap it in an arrow func.
as a person new to Javascript,
1) i like knowing the emphasis on *this* being used and understood is less than what I was led to believe
2) arrow functions are good and understandable for very simple functions but i like being explicit in my code and comment my code
3) not using var is a becoming outdated and i see less of it
4) i like vanilla javascript, i don't know why i would change, see no reason to
Typescript helps out a lot, it’s like sass for css. It basically a code translation for JavaScript and can help out with production. You can implement and create interfaces with it and when using it can be like a pre check for errors. I need to understand JavaScript more though to understand and want to use typescript
@@AlThePal78 I just finished a project where I used SASS and started learning TS this week. I came to the same conclusion with the TS and SASS comparison... as TS is compiled down to JS, conceptually similar to the way SASS is compiled to CSS. I'm struggling a little with syntax when using types in Classes, but understand the rest of the TS basics.
Answer to that "why" in number 4:
Because the future is moving towards typescript and you're not powerful enough to stop it😁
4):
Good type systems are the best way to avoid certain kinds of bugs. It can replace countless tests with just a few little extra annotations and catch problems you didn't even think of. The whole software industry is moving more towards this approach because it's just so valuable (and JS is a dumpster fire without it)
@@smohammadhn lmao
I'm not particularly interested in JS, but I love that shirt!! Do you have a link for it?
14:00, I would just use the OR operator:
var objs = []
console.log( (objs[0] || {}).name || "no such user" );
**Edit:** btw the OR operator, for loops and functions work in older versions of javascript also, whereas all this new syntax just says you don't give a toss about user choice
6:59, you gave 2 DIFFERENT listeners there, functions have an implicit "this" argument, whereas "statements" do not so it is normal for a "statement" to reference something entirely different to what would be fed into the function's "this" argument since a statement can only receive an expression
I think when you were covering optional chaining you might have meant to cover nullish coalescence for that ?? 'fallback message' but it seems it was missing.
Some really good advances in ES6 as I'm discovering. I still use "var". I get that some may find their sensibilities offended by what might be called its _scoping sloppiness,_ because the var(s) defined in the loop continue to be in scope afterwards, but I don't really see the harm. Also there are times it can be quite useful. Like when you want to get the terminal value of an iterator or expression without using extra logic to retrieve it. Anyway, thank you for a very interesting video.
Yeah the var implications with scope are just not how I naturally think about scope. Just my opinion. Honestly, it just comes down to whatever works for you and your team. Thanks for the comment!
For your example of an iterator, you can do that with let by simply declaring it just outside the loop. So for instance, if the iterator of a loop is `i`, you can just do `let i; for(i = 0; i < 100; ++i) {}` for instance, and then you can access that value after the loop. It's technically more code, but it's not more logic, just a simple "move the word 'let' up one line".
One of your best videos so far! Opens a lot of constructive discussions.
Arrow functions (and function expressions for that matter) are NOT hoisted and as such cannot be called before they are defined. I tend to use full function declarations at the root level of a module so that the order of the functions in the module does not matter. Plus named const arrow functions are actually longer to type:
const a = () =>
function b ()
With regards to your last two points, try css frameworks such as tailwind or windicss.
For debugging, if you have containerized your application for ease of development, it may not be possible to debug code in vscode.
Firefox has debugging capabilities built in. You can select the line of js code you want to debug by going the "Debugger" tab and choosing the line of code from the left submenu under "Sources". I'm sure chrome has something similar as well.
it is possible, to debug container app, you just open a second port and allow the remote extensions of vs code to listen/hook and that is.
@@TheAliendreamerbg do you have a link for this? I tried, and nothing was happening. To be fair, I was trying to debug code running in a remote location, so I might have needed to add more configuration to launch.json to make it work
I haven't coded for a bit so im rusty, but something you can't do with foreach for example is using await inside, which for allows.
If you are using TS or you write a Project in Node. Arrow functions, const/let instead of var and optional chaining are good ideas. If not, all this things are No Go's. Please use for-of because it performs better. If you are using a linter it wont allow shadow variables.
What I do not anymore today is, building classes in functions with the prototype keyword and i don't use Promise.then if i can use async/await (so in Node or TS)
Thanks for explaining the 'optional chaining' part. I was completely unaware of that till now
Thing #11) Being gainfully employed. Lots of layoffs and hiring freezes in tech these days.
Hey James can you please let me know that should i master javascript by making more n more projects in plain js or after learning about js i should continue with framework and make project in the frameworks..???
I am a self thought developer it's not really all about making projects it's about learning fundamental js programming concepts and making our ideas clear about how things really work . If you want to show off some projects for your portfolios and resumes then you can go for some framework ( example react ) else to make your fundamentals strong and make your logic development better you can practice coding questions with vanilla js
@@aashrith9680thanks for the guidance
Nice video! Great to hear that I am doing things right in my front end developing. What comes to debugging, I am really used to do it in chrome developer tools instead of IDE. I almost never use console logs for debugging purposes :)
Hi im learning JavaScript. Have no exeperience with coding . Its hard to learn . Do you have tips for better learning skills.
Just a minor point: JavaScript _is_ strongly typed. What TypeScript add is static typing.
JS is weakly typed - "A weakly typed language has looser typing rules and may produce unpredictable or even erroneous results or may perform implicit type conversion at runtime"
Javascript is dynamically typed. The types exist and are inferred at runtime, but you can see numbers coerced to booleans, strings etc. depending on use which would not happen implicitly in a strongly typed language (compiler errors). what TS provides is notations where the types are ambiguous and hinting where the types are inferred (at author time) to assist developers in understanding what the code is (or is supposed to be) doing.
@@akillersquirrel5880 No, a weakly typed language is something that can start reading random bits of data and interpreting them as a function call and corrupt your entire system. Like assembler or C.
JavaScript _always_ knows what type a particular value is, there is an operator for that.
It might have silly rules for conversion, but those conversions are only possible _because_ JavaScript is _strongly_ typed.
1 == "1" in a weakly typed language would just compare the bits to each other; but JavaScript knows one is a string and can apply quite complex conversions to it and come up with the idea that those two values are "equal".
A weakly typed language is more likely to say 70 == 'F' is true.
@@dtkedtyjrtyj If you only define "weakly typed" to mean that, then sure, I guess you're right. But by most understandings of the term "weakly typed", implicit type conversion is enough to make JS be considered weakly typed -- en.wikipedia.org/wiki/JavaScript#Weakly_typed
en.wikipedia.org/wiki/Strong_and_weak_typing
@@akillersquirrel5880 I suppose it is a spectrum, but I don't see how a language that _always_ knows what type every value is and converts exactly according to a detailed spec can be called anything but strongly typed.
I think a lot of people don't understand what the difference between dynamic and weak typing is, and the term has been watered down.
Thanks for teaching me about scoping with `const`--I never caught that until now.
Regarding the getElementById() from the Document Object Model (DOM which applies more in the context of web pages in browsers than e.g., Node.js): the `id` attribute is supposed to uniquely identify an element in the page. It's invalid HTML to have more than one element with the same id. Therefore, getElementById() will only return a single element (if present it's present in the page). If you wanted an example of an array of elements from the DOM (without having to wrap a single element in a list literal), you could call getElementsByClassName(). The same class name can be assigned to multiple elements across the page so that function returns an array (which might still be empty or only have a single element if that's all that was defined on the page).
Please use at least coderunner in VSCode to show console output, that white rectangle from sour switches to browser is quite painful (not to mention interrupts explanation flow, if you write oneliner and show alternative syntax, no need to proof output.
Thanks for the video. Could you make font size of code bigger next time? For convenient watching on the phone...
#2, 3 and 4 are the three biggest critiques or things that I hate the most about JavaScript.
A little part of me dies inside anytime I see someone using the foreach method. Call me old fashioned but I don't think it has any advantages and can easily be hard to understand.
Arrow functions are the same... Just why? What's wrong with `function myFunction() {}`? Sure I suppose you could save a few key strikes but most of the time, my functions are... well, functions... why call it a variable? Sure technically you can reference it like a variable but I like to think of things from a conceptual perspective most of the time... it's a function... It takes arguments and returns a result... so in order to self document, call it such in your code.
And as far as `this` goes... the fact that this is even a problem in the first place tells you all you need to know about the language. When you can't implement object oriented concepts for fear of referencing the wrong object, you've broken OOP.
On that last point... I suppose JS doesn't really know if it wants to be OOP or FP but that's even another problem I have with it. I've seen developers moving more and more in a functional direction with JS (ex. React is huge with this in my experience). Yet literally everything in JS is an object... Heck there's an entire notation named after it to represent objects. It's like it's trying to be an object oriented language but everyone knows it sucks at that so they use it as a functional language.
I didn't mean to rant on JS when I woke up this morning but apparently I needed to.
Can anyone please tell me this Vscode theme name?
I Definitely use the higher order functions that are in javascript but I def still use for loops. Sometimes it's easier to work with, especially if I need the index or if I need to do something more complex.. There is work arounds to get the index etc but it's usually more complex than just writing for loops which In all honesty, takes like 10 seconds to write the syntax to get a loop started. .. you can also do it in reverse, even or odd, start at an index or just the first 10 items in the array etc..
Holy crap! I LOVE the examples of how to get away from "this". I definitely understand what it is and why it's used when it is. But, your explination and solutions to it seem much better! Love it thanks :)
For self documenting code there is also the decision (personal) about style. For example whether or not to say it's a "Map" or just use "usersById", the latter is my preference.
Yep, this is gold .. I'm now moving over to typescript, been migrating for the past month
I'm surprised guard clauses wete not mentioned as a substitute for nested code with if statements
I liked forEach at first, but have stopped using it due to needing synchronous functions, which could go back to the old for loop or some of the newer ones.
Optional Chaining I love the concept, but some legacy browsers do not like it still, and working in certain companies means you can not use it. Yes, there might be tools, but not allowed to use them sometimes.
Have started loving console.time/table over log, only reason I use log is if I am just looking to see if it gets to the point. Debug I still do in the browser, just find it so much easier to mess with stuff there.
also the good old for loop is more efficent preformance wise
forEach, as well as all the other array methods, are synchronous.
Was meaning asynchronous, due to you want might want it to wait before doing the next part of the code. You also might want it to be in an expected order.
I use a naming pattern of usersById for the map/dict and usersAllIds for the (sorted) array of UUIDs. Useful where you need an array of user objects, that you can always .map the allIds and lookup the byId
3:42
And even shorter:
names.forEach(console.log);
implicit parameters, not sure if it makes it better, but ok...
`forEach` will pass some parameters you're probably not expecting if you do that. I like a tacit style just as much as the next guy, but you have to make sure the target function isn't going to unintentionally use the additional parameters that `forEach` will provide.
@@recursiv ok, names.forEach(console.dir) it is.