What hell is: people write multiple statements one after the other and put an await before a function call
- Causes performance issues - many times one statement doesn’t depend on the previous one

What if we don’t use the await keyword?
- We get an unresolved promise (which we can use later)
- The compiler won’t wait for the function to execute properly

What can we do?
- Get the promise and then wait for it in another line

Steps to get out of hell
1. Find statements which depend on the execution of other statements - make things as parallel as possible
2. Group-dependent statements in async functions
3. Execute these async functions concurrently - take advantage of the event loop to run these async non-blocking functions concurrently

Usually represent large integer ids/timestamps as string because the ints lead to lots of bugs - BigInt fixes this

Big Int could lead to BigDecimal!

js decimal problem (0.1+ 0.2 !== 0.3)

> 0.1+0.2
<- 0.30000000000000004

Previously had to use libraries to do big int calculations - can now use native BigInt which will reduce load time, parse time, and compile time + have run time performance. Still need to polyfill BigInt

BigInt:
- Can safely do things outside of the limit for Number
- To create a BigInt, add n to the end of any integer literal (eg. 123 -> 123n), can also use BigInt(123) === 123n
- Safe integer limits don’t apply to BigInt

eg:

BigInt(Number.MAX_SAFE_INTEGER) + 2n; //will be accurate

A New Primitive:

typeof 123n
// -> "bigint"

BigInt is never strictly equal to a number (42n !== 42) - to compare them, will need to convert (42n === BigInt(42))

When coerced to a boolean, BigInts follow the same logic as numbers (0n is falsey)

Operators:
- BigInts support most common operators, bitwise operations (|, &, <<, >>, and ^) perform bitwise arithmetic assuming a two’s complement representation for negative values (just like for numbers) - Two’s Complement
- Unary - works to make bigint a negative but, unary + is not supported because asm.js expects +x to always produce either a number o an exception
- Can’t mix operations between bigint and numbers (Bigint(2) + 2.5 -> ??? results in a TypeError)
- >>> (unsigned right shift does not work for BigInt because they are always signed

Why:
- Sometimes tech debt grows around dependencies that slowly loose value
- Some of the jQuery syntax doesn’t show intent properly - jQuery will select all of one type (did the author intend this?), and jQuery also silently skips expressions if they don’t match anything on the page
- jQuery is not compatible with Flow (or other static type checkers)
- Removing jQuery means you can rely on web standards more

Incremental Decoupling:
- Monitor number of jQuery calls
- Don’t allow importing jQuery into new code - use eslint to error
- Disable all subsequent eslint errors - shows devs its not up to coding standards
- People see the eslint disable in code reviews and prompts people to fix it
- Static type checking added confidence when refactoring code to vanilla js
- replace $.ajax with fetch()
- Incrementally remove jQuery modules that were no longer being used (creates a custom jQuery) - sped up JS
- Dropped old IE support and then didn’t have to worry about polyfills
- Only used JS as a progressive enhancement so that it would still work with JS disabled in the browser - then didn’t have to rewrite support in JS - could get rid of it altogether

Custom Elements:
- Component library native to the browser - nothing for the user to download, parse, compile
- Focussed on progressive enhancement when making elements

Polyfills:
- Use specific polyfills only when they are necessary for the user and not all the time (ie. to outdated browsers)