Wasm for the rest of us

In today’s issue we’ve got the brightest JavaScript star in the sky, crippling trust issues, and a Lightning McQueen joke that I’m 90% sure we’ve already made before (but I don’t care).

Welcome to #151.

---

Wasm for the rest of us

Have you ever wondered, “How come everyone is suddenly talking about WebAssembly so much?” or… “What is WebAssembly?”

Well, you’re in luck — because after I ingested a particularly potent dose of P5P to lower my prolactin levels, I was visited by the Ghosts of Wasm’s Past, Present, and Future (yes, even though it’s January). And now that my fine motor skills are back to normal, I’ll give you the Spark Notes version of what they told me.

The Past: Historically, JavaScript was the only programming language capable of running in the browser — until WebAssembly was released in 2017 as a “portable compilation target for various programming languages.” This made it possible for those aggressively passionate “JavaScript isn’t a real language” devs to use faster, lower-level languages like C++ and Rust to build web applications with near-native performance.

Wasm became an official WC3 Standard in 2019, marking a major breakthrough for the web and giving it the potential to become a “universal operating system” capable of running any type of program. And yet, most of us still haven’t used Wasm. So what’s it been up to lately?

The Present: Like Socker Boppers in the 90s, Wasm is just starting to go more mainstream. The most notable example is Figma, which uses Wasm and C++ to power its $20 billion collaborative design tool. More recently, we’ve seen other companies use Wasm to run Postgres, Photoshop, and even Wordpress in the browser.

In many ways, Wasm is following the same adoption curve as technologies like real-time video or multiplayer text editing. Today, only companies with a genuine business need and the ability to invest serious resources will be able to leverage the technology. But over time, this complex infrastructure should be abstracted behind simple APIs, making it accessible to the masses. Which brings us to our next ghost…

The Future: If you squint, you can already start to see what the next few years look like for Wasm. StackBlitz is already working hard on Web Containers as a sort of “Docker containers for Wasm” while other projects are also working to smooth out some of the rough edges and fully unlock the browser’s potential as an operating system.

As these foundations are built out, we might start moving into a “framework era.” Eventually, something like a “Next.js for Wasm” will let normie developers harness all the power of Wasm, without needing to become an expert in low-level systems.

Bottom Line: God bless us, everyone.

---

Permit: Never build permissions again

Building a permission layer for your app is like playing drunk Jenga — it seems simple at first, but as things scale and grow more complex, it’s just a matter of time before it all comes crashing down.

That’s where Permit comes in - they created a plug-and-play, low-code way to build Role Based Access Controls (RBAC) – so you could easily add functionality to your app like “only allow kronk@ui.dev to make purchases over $500 without approval.”

Plus, they also just launched Low-code Attribution Based Access Controls (ABAC). So you can add more granular/powerful permissions to your app, without building all the complex logic yourself.

Just select that you want to “allow USA-based users who are in the engineering department of ui.dev to make purchases over $500 without approval” – and it’ll auto-generate the code for you, which you can manage directly from your Git repo.

Permit is already used by small startups and huge enterprises (like Tesla, Cisco, and Palo Alto Networks) who all say the same thing: “Permit has easily saved us 3+ months of work.”

Check it out to see it in action.

---

---

How can this code be improved?

fetch("/user")
  .then((res) => res.json())
  .then((user) => {

  })

---

1. If today’s Wasm story filled you with an unquenchable thirst for lower level programming, then you should check out this practical comparison of build and test speeds between C++ and Rust. Then maybe try drinking a Sprite.

2. Take the Developer Nation Survey and you’ll be entered to win over 250 prizes — including a ThinkPad L15 Gen 3, an Intel NUC 10 Performance Mini PC, IoT kits, an iPad Air, gift cards, and more. And the survey questions themselves are *actually* interesting and pretty insightful. [sponsored]

3. The 2022 JavaScript Rising Stars report just dropped. I know what you’re thinking, is this necessary? Well is it necessary for me to drink my own urine? No, but I do it anyway cause it’s sterile and I like the taste.

4. Lightning CSS just launched a new visitor API that lets you you build custom CSS transform plugins in JavaScript. Lightning McQueen CSS is this awesome new Cars-themed template that I keep trying to convince Adam Wathan to add to Tailwind UI. But some people don’t appreciate modern art.

5. GitHub Copilot Labs now comes with a new test generator that creates and refines tests for you. Who knows maybe literally not needing to write tests will be the thing that convinces me to actually test my apps.

6. Jan Plhak wrote about How ChiselStrike generates its TypeScript client API. ChiselStrike also sounds like the name of a weird anime that I’d watch on Toonami at 1:30 am when I was 12 years old.

7. Spall is an auto-tracing code profiler for exploring your code and finding perf issues. It runs in your browser and is (of course) powered by Wasm. Consider your Wasm third eye opened 👁️.

8. Have you ever wondered what a Furby’s source code looked like? Oh, well here it is anyway. I’ll admit I’m a little disappointed they didn’t use Remix.

---

Thanks to Steve for this one. Here’s his fantastic breakdown.

fetch("/user")
  .then((res) => res.json())
  .then((user) => {

  })

As is, if our server responds with anything other than the user (like a 400, 404, 500, etc.), we don’t handle those scenarios. You might think we can just add on a catch.

fetch("/user")
  .then((res) => res.json())
  .then((user) => {

  })
  .catch((err) => {

  })

Not quite. The problem is catch isn’t triggered for any of those status codes. And worse, even if you wanted to check for the status of the request, you already ignored it when you converted the response to JSON in the first .then.

The better approach is something like this, where you check the status before converting to JSON.

fetch("/user")
  .then((res) => {
    if (!res.ok) {
      // Check the status
      // to decide what you do
    }

    return res.json()
  })
  .then((user) => {

  })
  .catch((err) => {

  })

Check out Steve’s video where he takes it even one step further.