I was lucky to attend the talk by Mr Crockford at Codemotion Amsterdam 2019, where he presented his new book to the web community. The talk was in a format I’ve never seen before: the speaker was literally reading his book to the audience. He prepared a few interesting slides and the talk mostly consisted of two chapters of the book, mixed with Q&A sessions.
The fun fact is that the book’s chapters and pages start with the number zero and it took some effort to manage this with a publishing company. As the author says: “The book is written by a programmer for programmers”. You can clearly see the chapters list is formatted in our lovely JSON:
When web developers start talking about numbers and caveats around them, there is one example which normally pops up in their minds:
According to the table, the significand part is limited by 52 bits and, in case it exceeds this number, the rest simply get cut off. Here is the root cause of the problem with floating numbers.
It’s just one thing among all possible issues when you work with numbers. Chapter 2 of the book should help us understand better potential problems and find solutions to solve them.
When Mr Crockford finished answering all the questions related to the third chapter, he switched to chapter 24 (twenty-four) and read some excerpts from it. In this chapter, he shows some good practices of writing a “fast” code and shares some bad examples of code we should avoid.
When we start optimising our code or application, the first thing we have to do is to find the root cause of our problem. Or, in case we want to increase the speed, we need to determine a bottleneck – the place which slows down the application and can be improved. Once we know what exactly we want to optimise, it’s much easier to find the right solution.
Another very important thing here is measurement. How do we know if our next update/release/hotfix will improve the current implementation? We need to measure the performance correctly and do it before and after our changes. The measurement here is a key! Only if we compare measurement results of before and after state we can be sure that we’re really optimising our application and not making it worse.