The best hair in OSS

Issue #19.October 26, 2020.2 Minute read.
Bytes

Last week, Billy McFarland (aka The Fyre Festival fraudster) was put in solitary confinement for launching a podcast from prison. Please don’t tell me how they smuggled the mics in.

We hope this gives you the courage to pick up that side project you’ve been putting off (unless it’s illegal).

Node.js 15 is Released

Node.js 15

Featuring all your favorite artists! (Except Ryan Dahl 🦕)

The OG JavaScript runtime blessed us with a major release last week, which means that Node.js 15 is now the “current” release line that gets all the fun new features. It also means that if you’re still using Node 14 you’re either a total n00b or you’re someone with a balanced, fulfilling life outside of JavaScript-land (gross).

Either way, Node.js 14 is getting moved to long-term support (LTS) later this week, so here’s what’s new with Node 15:

  • No more warnings for unhandled rejections. In Node 15, if an unhandledRejection hook isn’t set, it’ll be raised as an uncaught exception and terminate the application (instead of warning you with UnhandledPromiseRejectionWarning like it has since the Node v6 days). Node made this change based on a “user insights survey”, so enjoy the one thing this time of year where your voice is actually heard…

  • Upgraded V8 (the engine, not the juice - we make this joke whenever we mention V8 (the engine, not the juice) and we’re never going to stop). Node 15 upgraded to V8 8.6, which brings improved performance and a few new(ish) JavaScript features like logical assignment operators, Promise.any(), and String.prototype.replaceAll().

  • Experimental support for AbortController — a new, easier way to facilitate native promise cancellation.

  • npm 7 comes included in Node 15, which we wrote about last week. Tl;dr - npm has workspaces and supports yarn.lock files now, because good package managers copy, but great package managers steal.

The Bottom Line

It seems like the trendiest thing in OSS is to build a new runtime from scratch that’s got cool buzzwords like “modern” and “fast” and “TypeScript.” But until Deno (or someone else) grabs the crown, Node.js is still the runtime king.

TWIH: AngularJS Hits a Decade

AngularJS

AngularJS devs with that 10-year anniversary strength

10 years ago last week, AngularJS was publicly released to the world. It was created at Google by Misko Hevery as a tool to allow web designers to interact with both the frontend and backend. Misko originally named it GetAngular because of HTML’s angular brackets (<>).

But in late 2009, GetAngular seemed destined to remain a small side project forever. Until Misko made a bet with his boss that changed the course of web history.

At the time, Misko was working on the small Google Feedback team, who had grinded out 17,000+ lines of code over 6 months. As the app’s codebase grew, Misko and his teammates were getting frustrated with how hard it was to test and modify the code. So Misko did what any developer would do: he bet his manager that he could rewrite the entire app from scratch in 2 weeks using his side project JavaScript framework (GetAngular).

Misko lost the bet because it technically took him a whole 3 weeks to rewrite the app. Along the way, he managed to reduce the codebase from 17,000 lines to 1,500. Not bad.

At that point, the manager realized that our boy Misko might be onto something with this whole “JavaScript framework” thing, and decided to invest some Google-bucks into building it out. We’re not totally sure when the name officially changed to Angular, but it worked out for everyone except for this guy who could have sold that handle for quite a bit… After a few months of work, AngularJS had its initial public release on October 20, 2010.

So what’s the lesson here? If you’re stuck working on a large, unruly codebase, just stop what you’re doing and invent your own JavaScript framework real quick. It’ll be much easier that way.

Cool Bits

  1. Tyler wrote about Protected routes and authentication with React Router v5 and it’s #1 in cool bits because we’re shameless.

  2. Create React App 4.0 was released last week with Fast Refresh and support for React 17, TypesScript 4, and ESLint 7. Now it’s easier than ever to skip learning the fundamentals of React. Hooray!

  3. Rich Harris made a 20-minute video for Svelte Summit 2020 to discuss the future of Svelte and the web-dev landscape. (Spoiler: bye, Sapper.) He also continued to make his case for “best hair in OSS.”

  4. Harry Wolff wrote about what Vue.js does better than React. TIL Youtube let’s you upload videos that are 0 seconds long. Get it? Cause React is… ok never mind.

  5. The Cookie Store API is a new browser API built to expose cookies to service workers as an asynchronous alternative to document.cookie. Definitely should’ve named it the Cookie Monster API, wtf.

  6. Oceanwind is a new library that compiles Tailwind shorthand syntax into CSS at runtime. After releasing the library, the Oceanwind team started working on their line of scented candles at Bath & Body Works. 🌊

  7. The MDN team wrote about the future editorial strategy of the MDN Web Docs now that Mozilla has laid off the whole team “restructured the organization.”

  8. On a lighter note, Daniel made Dogbot - a Twitter bot that surfaces adoption listings for doggos. Thankfully, it’s not another one of those toy robot dogs from the ’90s with the terrifying commercials.

One Question Interview

What does building for the web look like 5 years from now?

Ben Hong

“Five years from now, I hope to see a world where our tools have taken further leaps and bound forward to empowering developers to build and scale applications at an even faster rate than today with things like improved debugging tools and better cross-platform support. Most importantly though, I hope to see that the web community continues to hold true to its core values of sharing knowledge and creating a warm community that people can join regardless of their background.”

Ben will be giving a ui.dev Event titled “Introduction to Vue 3” this Thursday.

JS Tip: == vs ===

We’re experimenting this week. LMK if you prefer these long form breakdowns or if you’d rather have the simple “Spot the Bug” type posts.

When writing software, the simpler solution is almost always the better one. If in order to use a feature I first have to learn and remember a list of rules pertaining to it, I try my best 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.

Triple equals equality table

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 ==.

Double equals equality table

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 (===).