I run incus os, which is an operating system that is made for spinning up containers and VMs. Whenever I have to work on a JS project I launch a new container for development and then ssh into it from my laptop. You can also run incus on your computer without installing it as an operating system.

Containers still have some risk since they share the host kernel, but they're a pretty good choice for protection against the types of attacks we see in the JS ecosystem. I'll switch to VM's when we start seeing container escape exploits being published as npm packages :)

When I first started doing development this way it felt like I was being a bit too paranoid, but honestly it's so fast and easy it's not at all noticeable. I often have to work on projects that use outdated package managers and have hundreds of top-level dependencies, so it's worth the setup in my opinion.

I'm waiting for container escapes too, its only a matter of time.

Haven't seen any in the wild, but i built a few poc's just to prove to myself that I wasn't being overly paranoid.

Amazing suggestion. So you're running it inside a Docker container or something? I'm going to try this out. I guess the alternative is a VPS if all else fails.

Incus uses LXC containers under the hood, which is better for development since the containers are made for running systems/os. Docker is best for running applications, but not that great for active development containers (imo).

With LXC any changes you make to the os/filesystem are persisted and there after the container boots up and shutsdown. So I don't have to worry about ephemeral storage or changes being lost. It feels more like a "computer" if that makes sense.

I do the same thing. Podman all the things.

Sorry to hear you got hacked.

I know we aren't supposed to rely on containers as a security boundary, but it sure is great hearing stories like this where the hack doesn't escape the container. The more obstacles the better I guess.

Hacks are humans. For like, ten more minutes anyway.

If the human involved can’t escalate, the hack can’t.

You can use pnpm, which forces you to approve the install scripts you want to run.

Do you approve on every update of the package? Do they offer a way to quickly review what’s going to run and what has changed since the last approval? Otherwise it’s just like another checkbox of “I confirm I read the terms and conditions”

Looks awesome. Gotta say, the built in testing, websockets, and file system router are exciting to see.

Is anyone using bun in production? Would love to hear your experience.

I’m using it for some internal business apps. I quite like it.

It’s early days, so I definitely miss some things— like a REPL.

I gotta say, though, it’s a good feeling when you deploy a zero-dependency TypeScript application complete with tests.

This sounds like a dream come true. Are you running into any issues with existing dependencies or this a new application?

I've been a long time Cypress user, but recently have been feeling those pain points you mentioned, the half-async-half-sync APIs are driving me mad :)

Im interested in Playwright, but wondering how you find the visual runner compared to Cypress? Are you able to run your tests in the browser and use a `debugger` or dev tools?

PW’s test inspector is pretty good. You can step through your test code and debug selectors. The inspector also runs in headed mode so you have the regular browser’s dev tools. The only thing left I want from PW is for PW to automatically rerun a test when it’s changed.

https://playwright.dev/docs/debug

This is so cool!

From the blog post it says read-only replicas are created close to users and kept up to date with the latest data.

- How should I think about this in terms of CAP? If there's a write and I query a replica what happens?

- How are writes handled? Do they go to a single location or are they handled by various locations?

I'm excited to try this. It's so cool to see databases being distributed "on CDNs" for lack of a better term.

I think they're replicated asynchronously, so reading directly from the replica may return old data. That's why they've added the ability to deploy special workers that "live" closer to the primary:

> Embedded compute

> But we're going further. With D1, it will be possible to define a chunk of your Worker code that runs directly next to the database, giving you total control and maximum performance — each request first hits your Worker near your users, but depending on the operation, can hand off to another Worker deployed alongside a replica or your primary D1 instance to complete its work.

Great article!

I will say I've found that using prettier makes nested ternaries much more readable.

I couldn't imagine using them without prettier, but since every app I work on these days uses prettier nested ternaries aren't so bad.

yes, next will prerender everything. you should give it a try.

I think for css classes like ".profile-card" this approach makes a lot of sense. Tailwind has @apply, which is a great way to turn these utility classes into named css classes.

However, after a while your app will end up with classes like .profile-card--inner, .profile-card__wrapper, and .profile-card__inner__wrapper--horizontal. When that happens it's usually easier to use those utility classes directly in the HTML template. You'll end up with something like:

    <div class="flex items-center mb-4">
    </div>

It's quick to write and requires no context switching!

There's a lot of problems that slackbots can solve, but asking people what type of slackbot they would pay $10 a month for is not probably not going to generate a lot of viable business ideas.

Find out problems folks are having and from there narrow that list down to those that are easily solvable by slackbots.