I apologize up front for 1. this being a long issue and 2. the terrible restaurant metaphor we use in the Snowpack story.
A different kind of “snow pack” for productivity
It’s been a busy January for Snowpack. It was named the “#1 Developer Productivity Booster” by the JavaScript Open Source Awards, celebrated the one-year anniversary of its v1.0, and just released v3.0 last week.
(Side note: we all know that caffeine + the TRON soundtrack are the real “#1 developer productivity boosters.” But we’re happy for Snowpack too.)
Quick review: Snowpack is a super-fast build tool for ES Modules that builds all of your dependencies once and ships them to the browser. After that, changes in your JavaScript code are instantly reflected in the browser without needing to re-bundle (unlike Webpack, which has to re-bundle after every change).
There are a lot more differences between Snowpack and Webpack that we don’t have time to cover here, so here’s a quick TL;DR
-
Snowpack is like Chipotle. It’s known for doing one thing really well and really fast (bundling ES Modules / bundling up huge burritos), and it does it in a straightforward way that makes sense. It’s pretty new and trendy, but it doesn’t offer a ton of options beyond its core functionality (bundling ESM / making burritos).
-
Webpack is like Cheesecake Factory: It’s a much slower experience, partially because it offers so many options (tons of Webpack use cases / over 250 menu items at CF). You’ll definitely feel overwhelmed during your first encounter with either of them, and you could reasonably describe both as a “post-modern design hellscape.” They’re a little older and clunkier, but they’ve still got a lot of power and versatility if you know how to use them.
Now that we’re all craving cheesecake burritos, here’s what’s new with Snowpack 3.0.
-
Streaming imports: This lets you skip the npm install step and just fetch the relevant, pre-built package code on-demand via ESM import. And since Snowpack caches everything for you automatically, you can work offline after the first package fetch.
-
New integration with esbuild: Now, you can plug in esbuild — the “I’m-100x-faster-than-everyone-and-not-obnoxious-about-it-at-all” bundler — to make Snowpack even faster.
-
New JavaScript API: This gives you more advanced control over Snowpack’s dev server and build pipeline, so you can create more powerful integrations on top of Snowpack. SvelteKit (Svelte’s new official web app framework) was built on top of this new API. And that’s a pretty big deal considering that Svelte was just crowned Lord of the Frameworks. (by the totally legit and definitely not biased State of JS survey)
The Bottom Line
We’ve got the perfect headline ready to go if Snowpack ever releases a paid, premium version: “Guac is Extra.”
One more glass of that vno vino
Vno is a compiler and bundler that pitches itself as “the first native build tool for compiling and bundling Vue single-file components in a Deno runtime.”
By now, you’ve undoubtedly heard the Deno hype. It’s the modern, secure runtime created by Ryan Dahl that many see as the heir apparent to Node.js. It was also the #1 most popular JavaScript project on GitHub last year.
But even though it feels like we’ve been hearing about Deno forever, v1.0 is still just 7 months old 👶. And until two weeks ago, there was no way to leverage Vue (the second-most popular JavaScript project in 2020) in a Deno runtime environment.
That’s where vno comes in.
It acts as an adapter that parses Vue component files and compiles + bundles them into a Javascript file that can be read by the browser. You can use the vno module to get the equivalent of a create-vue-app with a few CLI commands (complete with an example file structure). Or you can use it to optimize an existing Vue project.
The Bottom Line
Vno is the first tool to make it possible for developers to work with Vue in a Deno environment. That’s a cool concept on its own, but it also demonstrates the continued growth and emergence of Deno and Vue’s respective ecosystems.
2020 was obviously a huge year for both technologies, and it looks like 2021 isn’t showing any signs of slowing down. All aboard the hype train.
JS TS Tip: Why TypeScript?
Types are foundational to JavaScript; they influence everything about the way you write your programs. But JavaScript’s dynamic type system often makes it easy to introduce bugs by mistakenly referencing variables with the wrong type. How many of us have experienced the dreaded Undefined is not an object error?
TypeScript was invented to stop these problems from happening before you even run your code. It uses JavaScript as a base, adds some extra syntax to define types, and provides a tool to transform your code back into JavaScript. The result is a hybrid of a compiler and a linter. TypeScript checks your code as you write it to make sure the types are correct, and then compiles it to whatever version of JavaScript you need to support.
TypeScript is superset of JavaScript, meaning that any JavaScript program is also a valid TypeScript program. This allows TypeScript programs to import and use JavaScript code, meaning you don’t have to rewrite your entire app right away when you start using TypeScript. Other developer tools, like Babel or Webpack, can be configured to process TypeScript files, and new JavaScript runtimes like Deno support TypeScript natively.
There’s a reason TypeScript is so popular. Developers who use it love the type safety it provides while still giving them the flexibility of JavaScript. Here are some reasons why you might find TypeScript useful.
Type Validation
TypeScript is a static validation tool, like ESLint. The goal of any kind of validation tool is to increase your confidence that the program you are writing behaves the way it is supposed to and doesn’t have unexpected bugs. Since TypeScript understands the relationships between the types in your codebase, using it well can eliminate entire classes of errors and issues. As you write your code, TypeScript can give you hints to help you write your code correctly. TypeScript doesn’t replace ESLint or automated tests, but it can give you more confidence that your code is working correctly without having to run your code.
Compiler
TypeScript is also a compiler. Like Babel, it can transform TypeScript and JavaScript code to support different features for older JavaScript engines. If you need to support an older browser like IE11, TypeScript can transform your code so it will work correctly. If you only need to support newer engines, the compiler will strip out the type data and leave you with valid JavaScript.
It’s important to remember that TypeScript is not a runtime language - all of the types are removed at compile time. It’s purpose is to encourage you, the developer, to use the types to add checks to your program so you have fewer errors and bugs.
JavaScript Superset
TypeScript can be used as a progressive enhancement to JavaScript. It’s a superset of JavaScript, so any JavaScript program is valid TypeScript. This includes the massive amount of packages available on NPM. However, without proper type annotations, most JavaScript programs will have type errors. You can configure the compiler to ignore type errors on JavaScript programs as you transition your codebase from JavaScript to TypeScript.
Since TypeScript is a superset of JavaScript, many of the quirks of JavaScript are present in TypeScript programs. It might not always be possible to add the appropriate type annotations to something. TypeScript provides escape hatches, like the any type and // @ts-ignore which turn off the type checker for those parts of your code. This is just like writing regular JavaScript, so you can still enjoy the flexibility of dynamic types. However, it also means you can’t guarantee that your program will never have a type error. If you want a truly strongly typed language that compiles to JavaScript, you can use languages like ReScript or Elm.
Communication and Documentation
Coming into a brand new codebase can be daunting, especially if you don’t know how all the pieces connect together or how something is supposed to behave. Adding type annotations to your code removes a lot of the guess work in figuring out how a program works and serves as guide for anyone trying to work in your codebase.
TypeScript can also help with refactoring. Without TypeScript, you have no way of knowing all of the different places that need to be updated when you change something. TypeScript checks your change against any other files that might be affected and warns you if anything is broken. All that’s left is to follow each warning and make the appropriate change without needing to run your code.
The Bottom Line
In short, TypeScript will help you write code with less errors by checking your code before you run it. Adding the types might take a little bit of work, but it definitely pays off in the long run.
Cool Bits
-
Every White Male in Tech’s favorite JavaScript survey released their results last week.
-
CodeSwing is a cool VSCode extension that lets you create a personalized web playground right inside your editor. It’s even cooler if you use it while singing along to this iconic 2008 hit: “Now drop it loooow, and let me see your code SWING.”
-
The Vercel team published a great article and video on everything you need to know about React Server Components.
-
Mark wrote Why React Context is Not a “State Management” Tool (and Why It Doesn’t Replace Redux).
-
Stripe released some new VSCode extensions that let you build, test, and use Stripe inside your editor.
-
JQuery turned 15 years old last week!. It just got its first armpit hairs and is refusing to shower now. Teenagers.
-
Rob Palmer wrote and in-depth post about his 10 insights from adopting TypeScript at scale at Bloomberg.
-
You could go through Ania Kubow’s new 12-hour coding bootcamp on YouTube, or you could binge watch all of the extended versions on the Lord of the Rings trilogy. Doing either would probably make you a better person, but Ania’s bootcamp will probably make you better at your job.
