Pizza Rolls and JavaScript memes

It’s officially beta week.

We’ve got a TypeScript beta, a Retool beta, and my proprietary cold exposure therapy beta. So I don’t care if all your friends say you have “sigma” energy — for today’s issue, we’re all beta buddies.

Welcome to #159.

---

TypeScript 5.0 Beta 🚀

In July 2020, we wrote about the TypeScript 4.0 beta in our third Bytes issue ever — back when we were surviving on Totino’s Pizza Rolls and making JavaScript memes for the love of the game.

Both TypeScript and Bytes have grown a lot in the last 30 months, so last week’s TS 5.0 beta release felt like a milestone for both of us in some ways. But in other ways, we really haven’t grown that much — I’m still making memes and burning taste buds with molten lava rolls, and TypeScript still refuses to follow SemVer.

That means that TS 5.0 isn’t technically a “major release”, although it does come with a few more breaking changes than usual and some cool new features that have type nerds foaming at the mouth extra excited.

Here are the highlights:

• Decorators — These are the things you learned in 2016 and then forgot about until now. They start with an @ symbol, and can be put in front of classes and class members (like methods, getters, and setters), allowing us customize them in a reusable way. This new TypeScript implementation is modeled after the Stage-3 ECMAScript proposal, and replaces the experimental decorators that TS used to have.

• Const annotations — You can now add a const modifier to type parameters, which can be really helpful when passing in things you want to narrow as their literals.

• Speed improvements — Most code bases should see speed improvements of 10-20%, thanks to TypeScript’s migration from namespaces to modules, which allow it to leverage modern build tooling with optimizations like scope hoisting.

Bottom Line: For most developers, decorators will be the headlining feature here. Some folks are even wondering if they could help make class-based programming popular again. Yes by “those folks” we mean the Java devs.

---

Another game-changing beta 👀

There’s only one thing on Earth I’d rather build less than a mobile app: an internal mobile app (*shudders*).

But these apps can make life a lot easier for your co-workers who don’t sit at a desk all day — folks like warehouse and logistics workers, field sales reps, site inspectors, and others.

That’s why Retool just released the brand new Retool Mobile — so now you can build powerful mobile apps in an afternoon.

How it works:

• Connect your company’s data source once, and use it across all your apps.

• Use Retool’s visual editor + custom code to build and test your app. It also gives you native components, like a barcode scanner, camera, signature pad, and more.

• Build it once, then deploy instantly to iOS, Android, and the web with enterprise-grade security.

It’s still currently in beta, but it’s already being used by teams at Amazon, DoorDash, Mercedes-Benz, and lots more.

Check it out.

---

Have a job you want to fill?

---

1. If you still can’t get enough TypeScript decorators, Dr. Axel Rauschmayer wrote this deeeep dive on Decorators that actually won the Pulitzer Prize for “Most intense breakdown of a Stage-3 ECMAScript proposal.”

2. The New Relic team wrote this great breakdown of How to monitor a Node.js application with some real-world examples to help you get your hands dirty. [sponsored]

3. Nate Moore wrote about Unlocking New Possibilities with Hybrid Rendering in Astro 2.0. Sounds cool, but I’ll only try it out if Nate comes to my house and lets me show him how to unlock all seven of his programming chakras through a mixture of cold plunge therapy and scalding hot Totino’s Pizza Rolls.

4. The Web Browser Interop Team just released their outline of 26 focus areas for 2023. Because if you’re not focusing on 26 things at once, are you even trying?

5. Artem Avetisyan wrote about how Node and SWC make a lightning fast TypeScript runtime. Just so we all agree: “Lightning” is faster than “super”, but slower than “blazing”, right?

6. Slashd Run is a tiny, experimental library that lets you run user-provided code in a Web Worker (which can’t access the DOM).

7. Alex Kladov wrote about Rust’s Ugly Syntax. Based on the title, I was expecting this to be the first negative Rust article ever published — but I think he was just clickbaiting us, the sneaky bastard.

8. Robert Pearce wrote a fun post about How To Lose Functional Programming At Work. He warns that you might not like it if “sarcasm and self-deprecation aren’t your thing.” Sounds like I’ll probably hate it then.

---

When writing software, the simpler solution is almost always the better one. If in order to use a feature I first have to memorize a list of rules, I try to avoid it. Not because that feature might not be valuable to know, but because I don’t trust myself to remember every nuanced rule. That logic is the primary decision to why I always use triple equals (===) over double equals (==). They both accomplish similar things, but the Pit of Success for triple equals is much larger, let’s see why.

Identity Operator (triple equals, ===)

When using triple equals ===, there are two rules you need to remember - strict equality (for when you’re comparing primitive values) and reference equality (for when you’re comparing reference values).

Strict Equality

Strict equality checks that both the type (number, string, boolean, etc) and the value are the same. If the type is the same but not the value, you’ll get false. If the value is the same but not the type, you’ll get false. If both the value and the type are the same, you’ll get true.

5 === 5 // true. Same type, same value.
5 === 4 // false. Same type, different values.
5 === "5" // false. Different type, same value.

true === true // true. Same type, same value.
true === false // false. Same type, different values.
true === 'true' // false. Different type, same value.

Seems simple enough, but as mentioned earlier this rule breaks down when we start to compare reference values (or values that aren’t primitives).

Reference Equality

As we saw in the previous example, primitives are compared by their value. However, if you use triple equals with reference values, it’s going to compare the references (or spots in memory).

{} === {} // false. Same type, similar value, different reference. ❌
[] === [] // false. Same type, similar value, different reference. ❌
{ name: 'Meg' } === { name: 'Meg' } // false. Same type, similar value, different reference. ❌

Even though each of the examples above has the same type and what appears to be the same value, because they’re reference values, JavaScript compares the references in memory, not the actual value. In each of the examples the references or locations in memory are different, which is why we always get false.

We can see this further by assigning two variable to the same reference in memory and then using the identity operator on them.

const user = {
  name: 'Tyler'
}

const person = user

person === user // true. Same type, same value, same reference.

In the example both person and user are referencing the same spot in memory, which is why we get true.

In summary, when using the Identity Operator (===), assuming you know about reference equality, everything just works as you’d expect. Here’s an equality table to prove it.

Equality Operator (double equals, ==)

Unlike the Identity Operator (===), unless you’re very familiar with it, odds are the Equality Operator (==) doesn’t behave as you’d expect. Here are just some examples,

"1" == 1 // true
null == undefined // true
0 == '' // true
'0' == false // true
[1] == true // true 🤷‍♂️

So what exactly is going on here? Notice that each comparison is being made between different types. As we saw earlier with the Identity Operator (===), all of these would return false since they’re all of different types. With the Equality Operator (==), it’s not that simple. Instead of returning false when the types don’t match, it’ll attempt to convert them into the same type.

So in the first example, "1" == 1 because the JavaScript engine will convert the String “1” to Number 1 which then evaluates to 1 == 1 which is true.

It’s that type coercion stage which makes the Equality Operator (==) so unpredictable. Here’s the same equality table we saw before except now in terms of ==.

If you and anyone who works on your codebase is confident in all of JavaScript’s type coercion rules, feel free to use whichever operator you’d like. However, if you’re like me and you’d rather use the tool that works how you’d expect, stick with the Identity Operator (===).