Been working with JavaScript on and off since 1998, and I still find tons of values in your videos. Kudos, Kyle, on these excellent tutorials-you’re a real community asset
So in case anyone wondered how decimal numbers can be represented in memory. If we push a 1 to the left, we double its value. If we push it to the right, it's going to be halved. So let's do it, starting with 1: decimal -> binary 1 -> 1 .1 -> 0.5 .01 -> 0.25 .001 -> 0.125 Need 0.75 in decimal? That's 0.5 + 0.25 so it would be .11. Now let's look at the famous 0.1 + 0.2 = 0.30000004. 0.1 (dec) is smaller than 0.125 (1/8) so we need the next 2^-x power, 1/16, that's 0.0625 (.0001 binary). We're left with 0.0375, which is a bit larger than 1/32 (0.03125 dec, .00001 binary). 1/16 + 1/32 is therefore 0.09375 in decimal (.00011 binary). We would need 0.00625 more to 0.1, we're getting closer to 0.1, but in this case, since 0.1 can't be a sum of 2^-x powers, you will reach the maximum number of bits threshold so your value gets truncated. Imagine if he had only 4 bits, the best binary representation for 0.1 would have been 0.0001, which is only 0.0625! 0.2 (dec) is larget than 0.125, so we have .001 for starters, we need 0.075 more, which is between 1/16 and 1/8, so we have 1/8 + 1/16 so far (0.125 + 0.0625 = 0.1875, .0011 in decimal). We would need 0.0125 next, which, again, is not a sum for 2^-x powers and 0.2 representation is again truncated. You get close, but never 0.2 exactly. This is why you're not getting 0.3 for adding 0.1 and 0.2, which also doesn't have an exact binary representation. 0.1 + 0.2 in binary is like adding 2 truncated numbers, the way you would do 975 + 210 in decimal, about 1000 + about 200, that should be about 1200.
I'm amazed that after so long of working in JS that I can still learn something new. This time around, the console Timer and debugger option :) Thanks for sharing!
I mean, for the "Binary Math" solution I would highly recommend using Math.round and just round the comparing values to 2 decimals or so. Or directly round the values after each math-operation to x decimals so you can then later compare them to 0.35 directly.
I would actually suggest using a library specifically made for dealing with decimals(like decimaljs or bigjs) - especially true if you're working with some financial data and rounding it would be rather risky.
@@huge_letters As always it "depends on the usecase". For financial data that could be worth a shot, but then again you are depending your financial data on some "dude" who has issues open since 2018 which haven't been closed. If you are too lazy to repeat "Math.round()" in your code, you should consider writing util functions yourself, so you drastically reduce the likelyhood of bugs. For example write a "sum([decimalsArray])" function that returns with a precision of 2 by default and can be adjusted by parameters. I also read somewhere that a new datatype is coming that will fix this, but i can't find any info on that so maybe I have faulty memory here...
I mean... labels are essentially GOTO statements. Sure, there are times when you want to use them, but they are usually a bad thing because it makes code less readable in more complex examples. For this first example, you can just use a "break" statement to break out of that inner loop.
@@TheGreatMcN GOTO statements are icky. I mean... it's what the compiler is ACTUALLY doing really low level... but yeah, I'd consider rearchitecting the code before using labelled gotos. Like, consider using functions and return statements.
Tip for those trying to compare equality on decimal arithmetic: Use subtraction and an epsilon. IE: let epsilon = 0.00001 (or whatever precision you like) and re-write your equality to if Math.abs(x-Comparison_Value) < epsilon { }. In your example it would be if (Math.abs(x-0.35) < epsilon) { // do stuff }
@@adtc Flooring will truncate the decimal part completely. So if you were to compare 0.9 with 0.3 with a floor it'd be equal. Unless I'm not understanding where you are using the floor function. Math.floor(0.9-0.2) === 0 -> true. But I think most would want that to be falsey
@@arjix8738 Int math is prefered, but not always an option, it will depend on the size of the numbers you are using. If you want precision to 6 decimal places, you'll have to multiply by a million and then divide at the end, which may or may not be ok. But in general, I do agree that if you know that your numbers are safely not going to overflow, that converting to int and back is the best. For money transactions, I leave everything in pennies (or cents or whatever) and then convert on the presentation layer.
On Binary Math. I would advise multiplying, rounding and diving to significant decimals to ensure that the input condition is treated to match our condition. e.g. Math.round(num * 100) / 100 for 2 decimal. Same with strings : Always do a if( {input}.toLowerCase().trim() == {condition}.toLowerCase().trim() ) {} I would say these 2 methods are life savers when you want String and Number comparison.
Here is a generic rounding function. This example is a static function in my class MathLib. Sorry about the formatting... static round(number, precision) { const power = 10 ** precision; let result = Math.round((number * power).toPrecision(15)) / power; return result; }
That's a really bad idea as you can't assert that Number.EPSILON has a good enough tolerance. Example: Math.abs((0.1 + 0.2) - 0.3) < Number.EPSILON is true. Math.abs((1000000.1 + 0.2) - 1000000.3) < Number.EPSILON is false. Clearly the difference should be the same, yet the tolerance is insufficient. Your best bet when working with things like these would be to use a custom tolerance. The approach is sound, but relying on Number.EPSILON is not. It would also be possible to use Math.abs, multiply by 10^n and then Math.round to get an integer value, after which you can make an assertion. I haven't tested it extensively though, so I can't guarantee it works in all cases, but it's a possibility for some cases I can think of.
Worth noting for the sake of other readers that code smell *does not* mean bad code. It's just a potential red flag, something to watch out for and be wary that it might be bad code. Labels are extremely useful when you need them, but overuse is definitely something to be careful of.
@@foxoninetails_ Actually is a smell of bad code. If you have to watch out for that chunk, it is bad, indeed, so you are obligated to put more effort into it in order to maintain the code base. Btw, the nested loop example is easy solved by function extraction (and you are allowed to *return* whenever you want to continue to the next iteration)
@@KeenkiDash The term "code smell" does not and has never referred to bad code, except when used by people who have no idea what they're talking about. It was coined specifically to refer to code that is often, but not necessarily, indicative of bad design. Labels, like any other code smell, are not inherently bad, but rather should be used sparingly and thoughtfully. They are a valuable tool, but not one which should be used without good reason. And no, "the nested loop example" (which one? I'll assume the most common, breaking out of multiple loops) can't be trivially solved by function extraction. Labels allow you to break or continue from specific levels of a nested loop at any point inside them; to do so via function extraction, in more extreme cases, requires the inner functions to return some form of signal value which tells the previous function that it should also do the same, which becomes an unbelievable mess to manage.
Note: You need unique ids when using console.time. Generate a random suffix for the name when using it in async functions that are called multiple times.
9:58 No, it's not hard at all. You can use Object.keys, Object.values and Object.entries to effortlessly loop through anything you want. Being able to use an object as a key is super cool though! Would be even cooler if object comparison wasn't such a pain in JS 😅
Objects should be used for storing data where your keys are pretty much static and known and well-structured - like you have a person entity which has a name, age, location etc. Map was made specifically for situations where you want a relationship between arbitrary number of keys and values. It's optimized such cases too. Object.keys, values, entries create a new object in memory on top of the one you already have.
I often make a helper function to create "enums" in JS (obvs. not real enums, but close enough for most uses). It just takes a list of strings, and then returns a *frozen* object that maps the strings to Symbols of the string, thereby ensuring that (a) they can't be changed, and (b) they are all unique values. Which is like 2/3 of the use of enums. So for instance, I could do: const Directions = make_enum('UP', 'DOWN', 'LEFT', 'RIGHT'); And the resulting frozen object would have unique symbols referenced as Directions.UP, Directions.DOWN, Directions.LEFT, and Directions.RIGHT.
The For labels seem like a great way of documenting what each of your loops is doing without having to use comments. Even if you don't use them in the execution itself. Just like good variable names avoid unnecessary comments.
For the loop variables: Is it not just easier and clearer to put the standard continue for i === 1 directly after the first for loop? This would directly increment the i counter.
The point of this was to show the feature, not to show a practical example. This is a feature with a pretty rare use case. It's difficult to come up with a good example until you actually have a use for it
@@purduetom90 I would make the case that break and continue are goto statements. But personally, I try not to use any for loops at all and use map filter and reduce instead
I love your videos, Ive been developing sites and software just as a hobby for over 25 years and been stuck in the old ways of doing things. I'm in the process of teaching myself angular and node and your videos are very helpful and easy to follow.
It's always a bad idea to assert equally with floating point values. They're mostly useful in games, math, geo spacial and other applications where accuracy to 1/10000ths are not important. Always use whole integers when dealing with money values where 1 is the smallest unit of a given currency, and use number formatting when displaying to a UI.
@@benscherer7256 you are correct but I'm pretty sure you don't have to worry about that if your values are integers - you won't get any weird rounding errors.
One of my favourite things in plain JavaScript is taking TypeScript features like an enum, an convert them to basic JavaScript. In that case, you can create an enum with const enumTest = Object.freeze({ test: "Hallo ich bin ein deutscher Text" )} export enumTest; you can now easily use this enum within your JavaScript files (you may wanna minify this code with babel and parcel, to also support older browsers like Internet Explorer); That's just one of the things I kinda like to do with JavaScript.
it's crazy how you apparently always shows some feature I'VE NEVER SEEN BEFORE! which is almost unbelievable to me since I've been around JS for a while lol!
I have a video idea for you: do all the different Object methods such as Object.freeze Object.assign etc etc. I feel like I keep seeing new ones out in the wild
well I definitely didn't know loop labels, so I guess this video actually wasn't clickbait, like all the other ones I've seen with a similar title :) good job!
Great video! For me personally, the Set was the big win. I didn't realize that it was in ES6, but it makes creating a unique array muuuch easier without the need for an external library. Simply `[...new Set(array)]` or `Array.from(new Set(array))`. Of course this is only for primitives where value comparison is trivial! Thanks for the help 🙂
Exactly what @prometheas said below, I still reference your videos after all these years over any other video. You get to the point and you get to the point fast! A+ my man!
A lot of this stuff is great with the exception of labels. Most likely you need to refactor some code to use a reducer if you are running nested loops.
Thanks as always, can think of a couple of situations where loop labels could've helped me a lot. Somehow feels like a bad practice thing that should be used rarely though
my opinion: in general avoid even recommending labeled lines of code to jump to. 'go to' is very easy to lead to spaghetti code and should not be recommended for novices. if you really need to use it first try to simplify your loop or even extract them or their contents into functions. i've seen plenty of times nested loops and conditions spiraling into a big mess even the original author couldn't understand what and why they did what they did a couple days later
Adding extra functions does nothing for nested loops and nested loops are a requirement for some algorithms. They are unavoidable. Labels have value and you should know about them.
This is what I’ve heard when I learned about goto in C++... but contrary to what everyone says, it can be used in ways that don’t spaghettify code. I know cuz I used it in a very unique and honestly rather efficient way back when I developed my CSGO hack. You can easily loop back to a certain part of an infinite loop when there’s complications with variables.
I never use gotos at all. In languages like C, I typically need to manage dynamic objects anyway, to make sure they are properly disposed. This requires structured programming techniques, and the avoidance of gotos. I give some detailed examples here github.com/ldo/a_structured_discipline_of_programming .
@@lawrencedoliveiro9104 im not arguing that generally speaking you should avoid gotos im saying that they have their place even in well structured programs. the real use for them just isn't very common and generally a different structure would be preferred. my csgo hack's variables were dynamic and that's actually why i needed the goto over a traditional while/for loop or whatever. it was for the main fn.
the problem with 0.1+0.2 is not only a computer problem. It's also a programmer problem. They forget to round to the same precision of the source numbers. If you have 1 digit on source, you must round to 1 digit on the result (for a addition), so you HAVE to round 0.3000000000004 to 0.3 to stay in the same précision level.
The problem with 0.1+0.2 not equals 0.3 has been very very simplified in this video. Of course you can store 0.3 in binary. One not very effective but obviously possible solution would be as string. And some libraries that enables you to compute arbitrary big numbers (like BigDecimal in Java) do this. But since normally you want some nice compromise between precision, calculation speed and memory size, the primitive data types for floating point numbers are optimized for the most common use cases. They can store either pretty (but not alway perfect) accurate numbers or very big/very small numbers. But not both at the same time. So the real reason why most programming languages get 0.1+0.2 wrong is not, that if can't be represented in binary but that the representation used in most programming languages can't do it. Most programming languages (including JavaScript) use the IEEE 745 specification for storing floating point numbers. You can read all about it in the official specification (web.archive.org/web/20160806053349/www.csee.umbc.edu/~tsimo1/CMSC455/IEEE-754-2008.pdf ) or look on UA-cam for some videos that explain in in a more digestible form since the specification is 70 pages long. Storing floating point numbers efficiently really isn't easy ;)
The labeling loops was very cool. TIL. With that said thou, isn't there something about messing up control flow? Otherwise we could just be using goto instead of increasingly fancy breaks and continues, or even mid-loop returns.
So for binary calculations I always use function fix2(x) { return Number.parseFloat(x).toFixed(2); } This way I always have 2 (or as many as I specify) number of decimals.
Very interesting stuff. I knew about some of these, but don't use it often. You explain it well and give good examples which makes it easy to understand, I will try to find use cases for these in my projects :)
clickbait, damn arrogant millenials have NO CLUE what some of us know. Imagine them walking into a library to learn... lost like little puppies in the woods. Thanks youtube, for "dont show videos from this dick". 👍👍👍
@@ChrisLocke1969 what the fuck dude, this guy just tries to help people out. Plus it's true, the majority of web devs don't know these tricks. If you're a power user good for you but please don't spit on someone helping 90% of developpers out there
Hey Kyle, is there any option to purchase just the advanced portion of the course? I already have a job as a full stack JS developer but I'd like to sharpen my skills with advanced knowledge
Another way to check number equality is to use Number.EPSILON. So if you want to see if 0.1 + 0.2 equals 0.3, just do: (0.1 + 0.2) - 0.3 < Number.EPSILON // true
9:58 It's not difficult at all to loop through keys and values of Objects. `Object.keys(yourObject)` will give an array of enumerable keys. `Object.values()` gives you an array of values. `Object.entries` gives you an array of key, value tuples. You can use for-of loops like: for (const [key, value] of Object.entries(yourObj) { ... } One downside compared to Maps is that ordering of pairs isn't straightforward and wasn't even standardized until ES2015.
If you're making heavy use of Object.freeze for functional-style programming, I'd also recommend an immutable data structure library like immer, which does a bunch of stuff behind the scenes to make things easier and faster
At 16:30, that example is still a bad example. To check floating point numbers, you have to check for the detla difference. Something like : if (Math.abs(x - 0.35) < delta) where the delta is any precision of tolerence. For example, let's say the tolerence is 0.001, then : if (Math.abs(x - 0.35) < 0.001) will be true if x is between 0.3499 and 0.3501
Ah nest loops with labels. Sooo good. This is useful for looping through tv shows and their episodes. About the only time I would ever use a recursive nested loop. 😉
Been working with JavaScript on and off since 1998, and I still find tons of values in your videos. Kudos, Kyle, on these excellent tutorials-you’re a real community asset
I feel like the ECMA spec has evolved so much since the initial releases that we should be calling it JS++
lol
So in case anyone wondered how decimal numbers can be represented in memory. If we push a 1 to the left, we double its value. If we push it to the right, it's going to be halved. So let's do it, starting with 1:
decimal -> binary
1 -> 1
.1 -> 0.5
.01 -> 0.25
.001 -> 0.125
Need 0.75 in decimal? That's 0.5 + 0.25 so it would be .11. Now let's look at the famous 0.1 + 0.2 = 0.30000004.
0.1 (dec) is smaller than 0.125 (1/8) so we need the next 2^-x power, 1/16, that's 0.0625 (.0001 binary). We're left with 0.0375, which is a bit larger than 1/32 (0.03125 dec, .00001 binary). 1/16 + 1/32 is therefore 0.09375 in decimal (.00011 binary). We would need 0.00625 more to 0.1, we're getting closer to 0.1, but in this case, since 0.1 can't be a sum of 2^-x powers, you will reach the maximum number of bits threshold so your value gets truncated. Imagine if he had only 4 bits, the best binary representation for 0.1 would have been 0.0001, which is only 0.0625!
0.2 (dec) is larget than 0.125, so we have .001 for starters, we need 0.075 more, which is between 1/16 and 1/8, so we have 1/8 + 1/16 so far (0.125 + 0.0625 = 0.1875, .0011 in decimal). We would need 0.0125 next, which, again, is not a sum for 2^-x powers and 0.2 representation is again truncated. You get close, but never 0.2 exactly.
This is why you're not getting 0.3 for adding 0.1 and 0.2, which also doesn't have an exact binary representation. 0.1 + 0.2 in binary is like adding 2 truncated numbers, the way you would do 975 + 210 in decimal, about 1000 + about 200, that should be about 1200.
I'm amazed that after so long of working in JS that I can still learn something new. This time around, the console Timer and debugger option :) Thanks for sharing!
I mean, for the "Binary Math" solution I would highly recommend using Math.round and just round the comparing values to 2 decimals or so. Or directly round the values after each math-operation to x decimals so you can then later compare them to 0.35 directly.
I would actually suggest using a library specifically made for dealing with decimals(like decimaljs or bigjs) - especially true if you're working with some financial data and rounding it would be rather risky.
@@huge_letters As always it "depends on the usecase". For financial data that could be worth a shot, but then again you are depending your financial data on some "dude" who has issues open since 2018 which haven't been closed. If you are too lazy to repeat "Math.round()" in your code, you should consider writing util functions yourself, so you drastically reduce the likelyhood of bugs. For example write a "sum([decimalsArray])" function that returns with a precision of 2 by default and can be adjusted by parameters. I also read somewhere that a new datatype is coming that will fix this, but i can't find any info on that so maybe I have faulty memory here...
I mean... labels are essentially GOTO statements. Sure, there are times when you want to use them, but they are usually a bad thing because it makes code less readable in more complex examples. For this first example, you can just use a "break" statement to break out of that inner loop.
Or just check the condition in the outer loop
True, we need a concise example of when to use the labels I think
If a labeled break is like a goto, then how is unlabeled break not like a goto?
@@TheGreatMcN GOTO statements are icky. I mean... it's what the compiler is ACTUALLY doing really low level... but yeah, I'd consider rearchitecting the code before using labelled gotos. Like, consider using functions and return statements.
@@TheNewGreenIsBlue Sure, I agree with that. That doesn't answer my question though.
Tip for those trying to compare equality on decimal arithmetic: Use subtraction and an epsilon. IE: let epsilon = 0.00001 (or whatever precision you like) and re-write your equality to if Math.abs(x-Comparison_Value) < epsilon { }. In your example it would be if (Math.abs(x-0.35) < epsilon) { // do stuff }
Couldn't you just floor it and check for zero? Just curious...
@@adtc Flooring will truncate the decimal part completely. So if you were to compare 0.9 with 0.3 with a floor it'd be equal. Unless I'm not understanding where you are using the floor function. Math.floor(0.9-0.2) === 0 -> true. But I think most would want that to be falsey
@@KurtSchwind oh right, I don't know what I was thinking 🤪 thanks
or just calculate using whole numbers (integers) and then convert them to decimals
eg divide it by 10 => 3/10 == 0.3
@@arjix8738 Int math is prefered, but not always an option, it will depend on the size of the numbers you are using. If you want precision to 6 decimal places, you'll have to multiply by a million and then divide at the end, which may or may not be ok. But in general, I do agree that if you know that your numbers are safely not going to overflow, that converting to int and back is the best. For money transactions, I leave everything in pennies (or cents or whatever) and then convert on the presentation layer.
On Binary Math. I would advise multiplying, rounding and diving to significant decimals to ensure that the input condition is treated to match our condition.
e.g. Math.round(num * 100) / 100 for 2 decimal.
Same with strings :
Always do a if( {input}.toLowerCase().trim() == {condition}.toLowerCase().trim() ) {}
I would say these 2 methods are life savers when you want String and Number comparison.
Here is a generic rounding function. This example is a static function in my class MathLib. Sorry about the formatting...
static round(number, precision) {
const power = 10 ** precision;
let result = Math.round((number * power).toPrecision(15)) / power;
return result;
}
This video is like window shopping, you find things you never thought you needed!
17:12 you can use Number.EPSILON in combination with Math.abs() to include these tolerances. Eg.: Math.abs(x - 0.35)
That's a really bad idea as you can't assert that Number.EPSILON has a good enough tolerance.
Example:
Math.abs((0.1 + 0.2) - 0.3) < Number.EPSILON is true.
Math.abs((1000000.1 + 0.2) - 1000000.3) < Number.EPSILON is false.
Clearly the difference should be the same, yet the tolerance is insufficient. Your best bet when working with things like these would be to use a custom tolerance. The approach is sound, but relying on Number.EPSILON is not.
It would also be possible to use Math.abs, multiply by 10^n and then Math.round to get an integer value, after which you can make an assertion. I haven't tested it extensively though, so I can't guarantee it works in all cases, but it's a possibility for some cases I can think of.
IMO if you need labels, that is a code-smell
it's like goto.. it's EviL!!
Worth noting for the sake of other readers that code smell *does not* mean bad code. It's just a potential red flag, something to watch out for and be wary that it might be bad code. Labels are extremely useful when you need them, but overuse is definitely something to be careful of.
@@foxoninetails_ Actually is a smell of bad code. If you have to watch out for that chunk, it is bad, indeed, so you are obligated to put more effort into it in order to maintain the code base.
Btw, the nested loop example is easy solved by function extraction (and you are allowed to *return* whenever you want to continue to the next iteration)
@@KeenkiDash The term "code smell" does not and has never referred to bad code, except when used by people who have no idea what they're talking about. It was coined specifically to refer to code that is often, but not necessarily, indicative of bad design. Labels, like any other code smell, are not inherently bad, but rather should be used sparingly and thoughtfully. They are a valuable tool, but not one which should be used without good reason.
And no, "the nested loop example" (which one? I'll assume the most common, breaking out of multiple loops) can't be trivially solved by function extraction. Labels allow you to break or continue from specific levels of a nested loop at any point inside them; to do so via function extraction, in more extreme cases, requires the inner functions to return some form of signal value which tells the previous function that it should also do the same, which becomes an unbelievable mess to manage.
yeah i can already see someone senior to me being cool with 3, 4, 5 levels of for loop nesting ;)
Note: You need unique ids when using console.time. Generate a random suffix for the name when using it in async functions that are called multiple times.
This is really well done! I like the way you structure your video. The code, output, and video layout makes it easy to follow. Keep it up!
9:58 No, it's not hard at all. You can use Object.keys, Object.values and Object.entries to effortlessly loop through anything you want. Being able to use an object as a key is super cool though! Would be even cooler if object comparison wasn't such a pain in JS 😅
Objects should be used for storing data where your keys are pretty much static and known and well-structured - like you have a person entity which has a name, age, location etc.
Map was made specifically for situations where you want a relationship between arbitrary number of keys and values. It's optimized such cases too.
Object.keys, values, entries create a new object in memory on top of the one you already have.
I often make a helper function to create "enums" in JS (obvs. not real enums, but close enough for most uses). It just takes a list of strings, and then returns a *frozen* object that maps the strings to Symbols of the string, thereby ensuring that (a) they can't be changed, and (b) they are all unique values. Which is like 2/3 of the use of enums.
So for instance, I could do:
const Directions = make_enum('UP', 'DOWN', 'LEFT', 'RIGHT');
And the resulting frozen object would have unique symbols referenced as Directions.UP, Directions.DOWN, Directions.LEFT, and Directions.RIGHT.
Kyle, amazing video, bro!!! Map & Set just changed my perception of how should I start working with objects and arrays :O
new sub here, i absolutely LOVE your vids about 5 must know js features, and the other js video. GREAT CONTENT man! Thank you SO MUCH!
The For labels seem like a great way of documenting what each of your loops is doing without having to use comments. Even if you don't use them in the execution itself. Just like good variable names avoid unnecessary comments.
Never thought of it that way but it sure makes sense. Thanks for sharing :-)
these console methods are pretty neat, they sure'll make debugging a little less of a pain
For the loop variables: Is it not just easier and clearer to put the standard continue for i === 1 directly after the first for loop? This would directly increment the i counter.
I thought the same thing, but he probably just needed something easy to show of this example of this functionality.
yeah you dont need labels for this at all, labels arent really ever necessary but they can be good to know i guess
The point of this was to show the feature, not to show a practical example. This is a feature with a pretty rare use case. It's difficult to come up with a good example until you actually have a use for it
These are glorified goto statements…
@@purduetom90 I would make the case that break and continue are goto statements. But personally, I try not to use any for loops at all and use map filter and reduce instead
I can't like this enough! I work in typescript every day and I have found so many incredible things from you.
Holy crap you're a boss!
Another cool but rare piece of JS goodness: JS Proxy API.
I read somewhere that basic state management is possible using Proxy.
Vue reactivity system is based on Proxies, if I am not mistaken. It's where I learnt first to use them :). They are really cool tho.
@@microhoffman1248 Yup they are
@@Jens-OS nah fuck off
Yaah😃
Man! this should be sold on some learning platform for top dollars. So much valuable information here!! Thank you Kyle!
I love your videos, Ive been developing sites and software just as a hobby for over 25 years and been stuck in the old ways of doing things. I'm in the process of teaching myself angular and node and your videos are very helpful and easy to follow.
When I work with large decimals I use .toFixed() with a + before to round and convert back to a number. Like this: `+num.toFixed(12)`
@@Jens-OS reported for spam
It's always a bad idea to assert equally with floating point values. They're mostly useful in games, math, geo spacial and other applications where accuracy to 1/10000ths are not important. Always use whole integers when dealing with money values where 1 is the smallest unit of a given currency, and use number formatting when displaying to a UI.
though in js there is no integer type so you always need to be careful when working with primitive number types because it is a float.
@@benscherer7256 you are correct but I'm pretty sure you don't have to worry about that if your values are integers - you won't get any weird rounding errors.
One of my favourite things in plain JavaScript is taking TypeScript features like an enum, an convert them to basic JavaScript. In that case, you can create an enum with
const enumTest = Object.freeze({ test: "Hallo ich bin ein deutscher Text" )}
export enumTest;
you can now easily use this enum within your JavaScript files (you may wanna minify this code with babel and parcel, to also support older browsers like Internet Explorer);
That's just one of the things I kinda like to do with JavaScript.
Thanks for all the great info! I hope your new courses make you enough money to finally afford furniture
@@Jens-OS challenge? You son of a bitch, i’m in
Great video as usual but the main question is, do you have a video or channel playing your Jackson?
it's crazy how you apparently always shows some feature I'VE NEVER SEEN BEFORE! which is almost unbelievable to me since I've been around JS for a while lol!
@@Jens-OS no
believe me, all the features he is showing are handy, but not any better than what you already knew (in terms of difficulty)
@marlon that indicates these features are useless
@@mohamedbasry9588 I've found many of theses features to be usefull actually! Of course, not all of them, but a lot!
Man! Feature-packed video! Thanks so much!
To properly deal with floating point precision errors caused by IEEE 754, you should write "Math.abs(a - b)
The console and debugging stuff was fantastic, thanks for making my job easier!
I have a video idea for you: do all the different Object methods such as Object.freeze Object.assign etc etc. I feel like I keep seeing new ones out in the wild
@@Jens-OS How about instead of commenting trying to appeal to people's kindness, you just make some good content?
Thanks a ton for these videos man! Lots of awesome stuff in here.
Most JS I learned in such small amount of time, You are amazing teacher !!!!
Thanks for the loop label, console.assert, and console.table tips!
I've NEVER seen this label thing for loops that's crazy! Thank you
well I definitely didn't know loop labels, so I guess this video actually wasn't clickbait, like all the other ones I've seen with a similar title :) good job!
Great video! For me personally, the Set was the big win. I didn't realize that it was in ES6, but it makes creating a unique array muuuch easier without the need for an external library. Simply `[...new Set(array)]` or `Array.from(new Set(array))`. Of course this is only for primitives where value comparison is trivial! Thanks for the help 🙂
Exactly what @prometheas said below, I still reference your videos after all these years over any other video. You get to the point and you get to the point fast! A+ my man!
A lot of this stuff is great with the exception of labels. Most likely you need to refactor some code to use a reducer if you are running nested loops.
Thanks as always, can think of a couple of situations where loop labels could've helped me a lot. Somehow feels like a bad practice thing that should be used rarely though
if you find yourself in need of loop labels I can almost guarantee you have code that needs to be restructured anyway
@@ng429 I agree. loop labels are unnecessary if you know how to properly nest your loops (if nesting if necessary at all)
my opinion: in general avoid even recommending labeled lines of code to jump to. 'go to' is very easy to lead to spaghetti code and should not be recommended for novices.
if you really need to use it first try to simplify your loop or even extract them or their contents into functions. i've seen plenty of times nested loops and conditions spiraling into a big mess even the original author couldn't understand what and why they did what they did a couple days later
Indeed! The problem was famously pointed out back in 1968 by Edsger W. Dijkstra in an article titled "Go To Statement Considered Harmful".
Adding extra functions does nothing for nested loops and nested loops are a requirement for some algorithms. They are unavoidable. Labels have value and you should know about them.
This is what I’ve heard when I learned about goto in C++... but contrary to what everyone says, it can be used in ways that don’t spaghettify code. I know cuz I used it in a very unique and honestly rather efficient way back when I developed my CSGO hack. You can easily loop back to a certain part of an infinite loop when there’s complications with variables.
I never use gotos at all. In languages like C, I typically need to manage dynamic objects anyway, to make sure they are properly disposed. This requires structured programming techniques, and the avoidance of gotos.
I give some detailed examples here github.com/ldo/a_structured_discipline_of_programming .
@@lawrencedoliveiro9104 im not arguing that generally speaking you should avoid gotos im saying that they have their place even in well structured programs. the real use for them just isn't very common and generally a different structure would be preferred. my csgo hack's variables were dynamic and that's actually why i needed the goto over a traditional while/for loop or whatever. it was for the main fn.
Great video! I think I’m now officially a JavaScript Nerd, since I already knew all these features 😁
I love all your videos. I am just studying javascript, because I love this language 'console' languages. Thanks
You debugged my entire life with that "debugger" keyword. Kyle, I luv ya so much.
Thank you for this video! I definitely feel like I learned something new.
the problem with 0.1+0.2 is not only a computer problem. It's also a programmer problem. They forget to round to the same precision of the source numbers. If you have 1 digit on source, you must round to 1 digit on the result (for a addition), so you HAVE to round 0.3000000000004 to 0.3 to stay in the same précision level.
Excellent tutorial! Thanks for the help.
Thanks Kyle! Downloaded this to watch later. Keep up the good work.
Constantine
0:15 *then start using typescript*
12:18 “for (k in «obj»)” loops over the keys in the object table. And you can have non-string keys in those, too.
The problem with 0.1+0.2 not equals 0.3 has been very very simplified in this video. Of course you can store 0.3 in binary. One not very effective but obviously possible solution would be as string. And some libraries that enables you to compute arbitrary big numbers (like BigDecimal in Java) do this. But since normally you want some nice compromise between precision, calculation speed and memory size, the primitive data types for floating point numbers are optimized for the most common use cases. They can store either pretty (but not alway perfect) accurate numbers or very big/very small numbers. But not both at the same time. So the real reason why most programming languages get 0.1+0.2 wrong is not, that if can't be represented in binary but that the representation used in most programming languages can't do it. Most programming languages (including JavaScript) use the IEEE 745 specification for storing floating point numbers. You can read all about it in the official specification (web.archive.org/web/20160806053349/www.csee.umbc.edu/~tsimo1/CMSC455/IEEE-754-2008.pdf ) or look on UA-cam for some videos that explain in in a more digestible form since the specification is 70 pages long. Storing floating point numbers efficiently really isn't easy ;)
The labeling loops was very cool. TIL.
With that said thou, isn't there something about messing up control flow? Otherwise we could just be using goto instead of increasingly fancy breaks and continues, or even mid-loop returns.
yes, NEVER USE goto...label.
I believe the classic way to work around floating point issues is
if(Math.abs(a-b) < Number.EPSILON)
Wow. cool tips! I didn't realize that Javascript has all those features. Can you unfreeze an object later after you froze it?
No, but you can simply clone it and reassign the variable. like `obj = JSON.parse(JSON.stringify(obj));`
Amazing job, buddy! Amazing!
Excellent video. Is it best to no longer use semi-colons?
Those debugger tips are gonna be super useful! Thanks!
Man, this is simply amazing! Great content!
wow, this is packed with stuff I did know existed! thank you for this!
When I started coding, I started with VBA, and people used to say that the loop1 thing was really bad. Never really knew why.
That last debugging part was insane, didn't know you could do so much with console.
So for binary calculations I always use
function fix2(x) {
return Number.parseFloat(x).toFixed(2);
}
This way I always have 2 (or as many as I specify) number of decimals.
Very interesting stuff. I knew about some of these, but don't use it often. You explain it well and give good examples which makes it easy to understand, I will try to find use cases for these in my projects :)
In the first example, you could simply put your "if (i == 1)" statement within the first for loop. Problem solved.
☺️
Yeah I noticed this too. He was probably giving an example if you want to continue a loop within an another loop.
I think "break" is also a good choice
And way more readable
generally in every possible situation there are much better solutions than using loop labels
"Almost Nobody Knows" is a huge overstatement ;)
clickbait, damn arrogant millenials have NO CLUE what some of us know. Imagine them walking into a library to learn... lost like little puppies in the woods. Thanks youtube, for "dont show videos from this dick". 👍👍👍
@@ChrisLocke1969 what the fuck dude, this guy just tries to help people out. Plus it's true, the majority of web devs don't know these tricks. If you're a power user good for you but please don't spit on someone helping 90% of developpers out there
This video is very informative I did not know the power of javascript
GREAT
Awesome video as usual. I can't wait until you embrace TypeScript; I learn so much from your videos! :)
I really want to dive back into Typescript this year.
I love your vids!! High value
Hey Kyle, is there any option to purchase just the advanced portion of the course? I already have a job as a full stack JS developer but I'd like to sharpen my skills with advanced knowledge
Unfortunately that is not possible. It is only sold as a bundle.
Nice tips. Want to see your chrome dev tools tutorial...
I always learn most from this kind of general-code videos.
Does the complete package contain the six bonus projects? Very interested in this course!
Thanks!
It does not. Only the premium package contains the bonus projects.
I learn so much from your videos. Thank you for the effort you put into your work.
IMHO using break instead of labels from first example is easier and more readable :)
The labels work like in assembly that’s nice
that's because that's where it comes from, labels are a relic of the old way of programming
Quality information, thanks
Great video, thanks Kyle ✌️
@16:54 Why not instead cast to an integer?
if (int(x * 100) == 35) {}
The arbitrary range check feels wrong because it’s indeterministic.
To compare floating points is better to use a function like
var areEqual = (a,b)=>Math.abs(a-b)
Great tips. Thanks, Kyle!
Amazing features, didn't know some of them. Subscribed
debugger looks very usefull
i think it worth a whole ep on debugger usage
I think I should I checkout your js course👍 great bro
Thanks! I learned some good stuff.
Another way to check number equality is to use Number.EPSILON. So if you want to see if 0.1 + 0.2 equals 0.3, just do:
(0.1 + 0.2) - 0.3 < Number.EPSILON // true
9:58 It's not difficult at all to loop through keys and values of Objects. `Object.keys(yourObject)` will give an array of enumerable keys. `Object.values()` gives you an array of values. `Object.entries` gives you an array of key, value tuples.
You can use for-of loops like:
for (const [key, value] of Object.entries(yourObj) { ... }
One downside compared to Maps is that ordering of pairs isn't straightforward and wasn't even standardized until ES2015.
Highly appreciated, REALLY!
really really cool! instead of putting 10000000 you can do 10**7
10e7 is even easier for this particular case, but it's cool to know the exponentiation operator works in JavaScript too!
@@tatianabasileus didn't know 10e7 works too , cool!
console.table was a killer !! thanks a lot Kyle !!
GREAT video!
If you're making heavy use of Object.freeze for functional-style programming, I'd also recommend an immutable data structure library like immer, which does a bunch of stuff behind the scenes to make things easier and faster
I don’t think immer does anything faster
At 16:30, that example is still a bad example. To check floating point numbers, you have to check for the detla difference. Something like : if (Math.abs(x - 0.35) < delta) where the delta is any precision of tolerence. For example, let's say the tolerence is 0.001, then : if (Math.abs(x - 0.35) < 0.001) will be true if x is between 0.3499 and 0.3501
On checking numbers with decimals: how about instead of
if (i === .35)
you're doing:
if (i*100 === 35)?
That doesn't solve the issue
Wow. Very utile video. 👍
Pure gold. Thank you
Will "break" stop some Functions like interval or timeout? Or we can only use clearthem() to make them stop?
Ah nest loops with labels. Sooo good. This is useful for looping through tv shows and their episodes. About the only time I would ever use a recursive nested loop. 😉
exciting !!! Thanks very much !