I'd add a small suggestion here that I don't see mentioned very often: always use const whenever possible It's such low hanging fruit and helps to avoid mutability or name shadowing bugs. If for some reason you can't use const then, and only then, should you use let

These are some great tips! Usually these JavaScript tips videos are not that practical but I use all of these every day.

Thanks man, really useful tips even for a beginner programmer like me. Love your videos, they are a big part of my learning process. Even if sometimes your content is a little advanced for me, trying to understand what you are on about always points me in the right direction and I come out more knowledgeable every time. Keep them coming and thanks for sharing :)

As for writing modules yourself instead of using old, unmaintained libraries: you can always clone them, pubvlish them under your own namespace and maintain them yourself. I do this a fair bit. If they are single-file modules, sometimes even just copy the code and paste it straight into my project.

Loved the video. I apply pretty much all of them at work. Thanks for sharing.

Glad to see you back making videos, man. Was wondering if something happened. Welcome back!

Absolutely amazing video for a beginner JS dev, gotta recommend it to anyone who's starting out with the language

Damn, that last one is something that hits me hard, but I definitely needed to hear. Always readability > condensation. (at the end of the day for the bundler in most cases it will be the same thing)

That's a great video in a really long time !

All of this is good advice for any JS programmer. I would say, though, that one should never mistake code constructs they are unfamiliar with to be "clever one-liners". There are definitely one-liners that are difficult to understand, but there are also ones that are idiomatic JS and quite easy to read if you familiarize yourself with the idiom. The example here of chaining ternary operators is for-sure not idiomatic. But usage of map over for loops, for example, can be beneficial so don't discount things right away.

Learn how to be a better JavaScript developer with this one small trick. *Learn and use typescript*

I didn't know about the difference between == and === in JS. Thank you so much.

Welcome back, engineer!

I look up to u, I hope to be as knowledgeable about programming as you are one day. Thanks for the tips.

I might be wrong here but: Isn't the one liner an If else statement while the 10 line is a switch case (which can be faster to run)?

Awesome! Mille thanks

Thanks for your great content but I miss you messing with scammers. 😆

Good video - some of these even apply to other langs. Thank you!

6:03 "block" might not be the correct word. Idk it can be confusing. It releases the thread of execution until the async task is complete.

I really your thumbnail design

use eslint my dudes. it really keeps your shit in check. also write tests, which you should be doing anyway XD. I believe you can use == in one case, if (x == null), it compares x to both null or undefined. Even eslint has a special rule for it. just try and write code that won't make u vomit a week from now.

Epic

Great

Ugh when I see a ternary inside a ternary my head explodes. It took me a while just to understand basic ternary statements.

Thanks for the video

The one-liner form appeared often in our production code at a previous job, because it measurably improved(!) overall code readability! Reason? It left room for more context to be on the screen. Once I got used to it, the concise form didn't slow me down anymore. Decades ago we learned that code was easier to understand if it fit on a single screen (which helped justify buying larger screens). A little scrolling is OK, but comprehension speed drops rapidly whenever you have to scroll around a lot to understand a given line of code. Don't take my word for it, try it out in your shop. How much longer does it take people to find an obvious bug in code that's dense but fits on one page vs equivalent code that's spread out to multiple files and lots of lines? You'll find what we found: it's possible to write "code-golf koans" that are a pain for others to grok, but the far more common problem is code that is hard to understand because it's effectively spread out over too many pages and files.

great, well done!

I'm working with code someone wrote and instead of writing well formatted queries they've removed all hard returns, I guess to save space. Some of these queries run out 3000 characters in one line. He did this with a lot of the php and javascript too, so it was pretty undecipherable. Then to make matters worse, he put a blank line after practically every line, so you can only see half the code that you could normally see and the lines of code that are there all ran for pages lengthwise. Just making it legible took weeks.

I am the best now because of you

Use Prettier and ESLint

9:48 but if I don’t play code golf with every line how will I prove that I’m so much smarter than everyone else? Also I do not brush my teeth or hair and this is normal to me.

Nested ternaries make my skin crawl. It’s ok if code spans a few lines.

Careful with the using strict comparison exclusively if you are working on someone else’s app that could possibly have been written to expect a number value to be compared to a string value number like 1 == ‘1’.

The last one is so important. Stupid future me won’t understand what smart present me is doing.

tips: - stay up-to-date on the latest version of node.js - make use of well supported npm modules (check number of downloads + last update time) - use a bundler for frontend things - use async/await, normal promises to defer - use strict equality === exclusively - don't block the event loop - avoid clever one-liners (give priority to code readability)

9:50 until JavaScript supports if/Else and Switch as Expressions, nested ternaries will be a necessary evil.

Damn

Hey bro, can you help me?

Learning how to pronounce "Babel" properly also helps :D

Please, stop, I don't want to be a JavaScript developer

Best way to do Javascript better is not use it.

Generally, good advice but he also gave some very poor advice on a few topics. (1) "I can't think of anytime you'd want to use loose equality...ALWAYS use strict". Okay, I can think of times you may want to use it. PREFER strict, but know when to take advantage of loose. (2) "clever one-liners" is a little misguided. Try to keep you code compact and minimal and, most importantly as he said, readable above all else. But for God sake, AVOID `switch` blocks. I can't believe he used that as the proper solution. Also, notice I said "avoid" not 'never'. First rule of thumb: prefer prefer, prefer avoid, avoid always, and avoid never. That is, don't be dogmatic. Anyway, having writ JavaScript for a decade and a half, I can tell this guy is still learning -- which is great. Just take what he said with a grain of salt and don't be afraid to use all the features of the language at the appropriate times.