10 Things JavaScript Developers Have STOPPED Doing - Are you doing them?

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 bro very nice!!

I've dealt with self documenting legacy code bases before, and it's never a good experience. I think it's because there are too many downsides to the practice:

Devs are never good at naming things, so often the names are misleading, and you don't have the luxury of restating what you mean as you would a comment.

Comments can explain why a thing exists, when you would want to use a thing, where it should be called from. Names only tell you what it is.

Often you get the type in the name ( you've got 'Map' in your example ) which can become wrong if you refactor or expand the scope.

Names become too long and make the code harder to read, Java gets really bad for this with it's 60 character method names. Bringing in camelcase also doesn't help.

Var names start to look like function names. Used to be more of a problem before colour syntax hilighting.

Devs get too proud of their self documenting code, and don't comment where it is needed.

Can anyone please tell me this Vscode theme name?

For loops are hard to read. your 'i' index for example on your names array could be namesIndex. not hard at all

Arrow functions, new syntax,
es2015… new 😂😂😂

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.

for...of > forEach

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..

I hate frameworks. More specifically, I hate how most people use libraries that have hundreds, if not thousands, of dependencies.

I thank you so much for pointing out the `this` thing. That's been one of my pet peeves for a long time. For those who talk about "Well, what about OOP", I can say that other than the OOP I have to deal with in libraries that use it, I avoid (JS pseudo) OOP in JS as much as possible. Besides the fact that "this" becomes important when you are doing things that way. I've found that using closures and composition is way easier and more intuitive once you understand it than what JS pretends is OOP, and then you get to ditch "this" forever. I've been writing JS since '96 (yes the year it came out), I ditched JS's version of classes long ago because, in the end, they're not really classes and trying to make them behave like they are is way more painful that just ditching them altogether. A lot of black box (black magic) behavior disappears when you ditch so-called JS classes.

Var has been let go!

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.

this video is clear a lot of concepts about javaScript

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

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.

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 ()

For loop i match faster then array methond on large arrays.. bc the call stack... arrow functions without return can make confuse biginners..

Honestly "this" shouldn't be used in event handlers function/arrow/whatever. I did that like 20 years ago when I was still learning JS, and consider it foolhardy today. You care about what element the event fired on, that's Event.currentTarget's job, as been pretty much since we kicked supporting IE8/earlier to the curb.

The current object should be event, that it isn't either way and we have to access it via the passed parameter is actually pretty dumbass.

If you're working with real objects without events, "this" is pretty damned essential in your methods. If it isn't, you don't know how to use objects properly. Sadly, "not using objects properly" seems to be why we have so many people railing against their use. Kind of like the pedantic "if/else is evil" whackjobs who will use 30 lines of code to replace 5 because it's "easier". Of course writing six times the code is easier and simpler to follow. Tell me another one Josephine. Of course that those usually railing against if/else usually have in their "bad" examples "else after return" tells you exactly how much those nutters actually know about programming. Which is to say, not a damned thing!

Array.foreach is utter shite, always has been. Introducing the overhead of a callback function should be creating a major perormance hit, and that instead it just creates memory thrashing hell indicates the browser makers spent way too much time optimzing the wrong thing.

It sure as shine-ola doesn't promote code clarity when you're either making functions to be called halfway across the code, or further pissing on performance with anonymous functions. That's why the proper answer in most cases is not the moldy Array.foreach, but instead for...of. Even if it doesn't perform as well even though it SHOULD be faster, the code is way cleaner. And you mix a little Object.entries with destructuring, and it's almost as powerful as foreach in PHP.

ALMOST

VAR is still useful if you're result needs to be accessed after a loop or some other operation. People are treating let/const as replacements, and not as supplements... but then it took me a long time to even see the point of let/const since IMHO you need more than function level scoping, your code is shite. Even more crippled with objects not being frozen when declared as const. Wasn't until I realized we could replace IIFE with just {} and let/const that I saw a use that did anything meaningful.

You got interesting points here but navigating the video was confusing because you mixed things people stopped doing with things people started doing.

The old style for loops are still faster, and you have more control over their behavior. So when you said the new methods are "better", that's only in how much faster they are to write.

I rly don't like replacing `function` with arrow functions, it just looks confusing for no reason, how does
const foo = (a, b, c) => { ... }
look cleaner than
function foo(a, b, c) { ... }
is kinda beyond me, lambdas are cool when u create them in place when passing a function as parameter but using them everywhere is just way excessive for me, but maybe i just don't code enough in JS/TS

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.

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

Typescript is way better than js. It can get annoying to convert and there are some times when I get confused by it

Can you tell me what theme are you using, please ?

One of your best videos so far! Opens a lot of constructive discussions.

"first point, we dont use js anymore.
next point, lemme use js to explain" 😊

"this" is actually very powerful when you understand it's context

That time when you see you can use optional chaining like this : someArray?.[mayBeUndefined]

one liners turn my software to hardware

There are a lot of reasons to still use FOR loops, and with autocompletion, I just do for+tab, or forof+tab, or forin+tab. There is no way I'm writing the for definition lmao

But again, for a lot of specific use cases a for feels cleaner than an Array.map() with a 10-line long function inside

what about for (const item of array ) {} though

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.

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.

Modern powerful IDE with great IntelliSense is what makes long self-documented names possible.

I don't use let or classes. I use currying and partial application. I write copious helpers and libraries. I don't rely on hoisting. I dont write css or sass directly (use typestyle). I don't use raw dom. I rarely debug anything but styles

I like optional chaining but sometime if it's like a req field or something people will cover up the issue by doing this

you can make it even shorter: names.forEach(console.log)

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.

Hello, about the comments I think they should be used to explain why you are doing something, so they are important but just to clarify that in my opinion, and the names should explain what the code is doing.

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++. :)

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 :)

I usually tell people to stop using forEach(). Certainly forEach() is a step up from the c-style for loop you showed, but even better is the newer for-of loop (which came after forEach()) - the for-of loop is better in every way - there's nothing for-of can do that forEach can not, and it supports all iterables, await, yield, etc.

hopefully picking up typescript soon for new projects, but I wish #1 was 'stopped using semicolons'

how can semicolons even exist in 2022 CE. literally boggles my mind.

hmm, maybe I should look at kotlin JS

Not even [].forEach(console.log) - wtf?

Glad this video is available. Now I just need to focus on doing the opposite of these so that I become valuable and lower in the firing totem pole. Unless the bosses prefer everyone doing the same kind of coding style. I guess that might be one mindset to go by.

Hi im learning JavaScript. Have no exeperience with coding . Its hard to learn . Do you have tips for better learning skills.

I think most 'change" is just for the code look fancier and hard to read so your boss won't replace you that easy.