I’m a:

• Gamer
• Full stack web dev
• Android/iOS/MacOS/Windows Dev

So I have a lot of machines

Machine 1

• Purpose: MacOS/iOS app builder/publisher
• Usage: 100% work
• Location: Work
• OS: Modified MacOS Sequoia
  • Sequoia to avoid the glass interface disaster that Apple released
  • Uses custom window manager built in hammerspoon because fuck macos’s window management
  • Modified firmware so Caps + IJKJ = Arrows
• Shell: ZSH
• IDE: VSCode

Machine 2

• Purpose: Personal computer
• Usage: 90% games / 10% work
• Location: Home
• OS: Modified Windows 11
  • All the ads and AI bloat is removed but it requires increasing maintenance to maintain
• Shell: ZSH through WSL Ubuntu
• IDE: VSCode

Machine 3:

• Purpose: do everything on the go
• Usage: 50% games / 50% work
• Location: Wherever
• OS: Modified Windows 11
  • All the ads and AI bloat is removed but it requires increasing maintenance to maintain
• Shell: ZSH through WSL Ubuntu
• IDE: VSCode

Machine 4:

• Purpose: Disposable environments to test new things
• Usage: 100% work
• Location: Work
• OS: Kubuntu 25.10 (Current plasma version is great so far)
• Shell: ZSH
• IDE: VSCode

Also:

• Android Tablets
• Android Phones
• iPads
• iPhones

Future:

• Helix
  • I want to learn Helix’s keyboard workflow
  • Helix’s lack of extensions has held me back.
    • Helix has been working on extensions for a while though and I’ll re-evaluate it once it does and the community builds the needed extensions
  • Zed has some helix commands, so I may switch to that from vscode to get helix commands + extensions.
• OSs
  • I want to reduce my windows 11 maintenance
  • Held back by anti-cheat games (PUBG, then Helldivers 2, and will try Arc Raiders these holidays, potentially Marathon next year)
  • I’ll experiment with KDE / Cosmic / Niri in 2026.
  • If no anti-cheat games have captured my attention in 2027, I’ll switch another one of my personal machines to Linux

I’m literally slower with AI, because I have to waste my time review slop generated code that looks convincing rather than actually works.

If they tried at least to write the code themselves they would get better over time

Pretty sure Deno had that first though.

Deno launched with an all-tools-in-one approach and then you could use deno bundle to compile everything into a single binary that you could run on another machine.

Then they briefly broke deno bundle in their 2.0 release when they added node/npm compatibility then brought it back in 2.4.

Serious question for anyone who actually uses Bun:

Why are you using Bun instead of Deno or Node?

If you would have asked me 10 years ago, what were the biggest problems with JS as a whole, I would have stated:

1. Poor type safety

2. No standard library which leads people into dependency hell

3. Poor security (installing a project should not even allow the possibility of key stealing or ransomware)

4. No runtime ergonomic immutable data structures with fast equality checks (looked like it was going to be resolved with the Records and Tuples proposal, but it was withdrawn and discussions are continuing in the composites proposal)

Today I consider point 1 mostly resolved and point 4 a problem for TC39 and engine implementers, and not resolvable by runtimes themselves.

That leaves us with problems 2 and 3.

I see Node having poor solutions for 2 and 3.

I see Bun having poor solutions for 2 and 3.

I see Deno having great solutions for 2 and 3.

As far as I can tell, people have chosen Bun for either hype or speed reasons.

Hype doesn’t seem like an important reason to choose Bun since it’s always fleeting and there’s enough investment in the industry to keep each runtime going for a long time.

I do see speed being a moderate issue with JS, but that’s mainly due to:

• dependency install times which should be a one time cost, and which can be reduced anyway by using a standard library

• slow framework slop, which isn’t really a runtime issue.

So I’m not sure speed fits as a reason for choosing Bun.

I’m not sure what the other reasons are, but I’m genuinely curious.

If you’re using Bun in projects today, why have you chosen bun?

Bruh, deno’s great!

Why would you need to go to a store to download apps?

I’ll repost my comment yesterday about this very thing (link: https://news.ycombinator.com/item?id=45279384#45283636)

It’s also too early to worry about DOM apis over wasm instead of js.

The whole problem with the DOM is that it has too many methods which can’t be phased out without losing backwards compatibility.

A new DOM wasm api would be better off starting with a reduced API of only the good data and operations.

The problem is that the DOM is still improving (even today), it’s not stabilized so we don’t have that reduced set to draw from, and if you were to mark a line in the sand and say this is our reduced set, it would already not be what developers want within a year or two.

New DOM stuff is coming out all the time, even right now we two features coming out that can completely change the way that developers could want to build applications:

• being able to move dom nodes without having to destroy and recreate them. This makes it possible so you can keep the state inside that dom node unaffected, such as a video playing without having to unload and reload a video. Now imagine if that state can be kept over the threshold of a multi-page view transition.

• the improved attr() api which can move a lot of an app’s complexity from the imperative side to the declarative side. Imagine a single css file that allows html content creators to dictate their own grid layouts, without needing to calculate every possible grid layout at build time.

And just in the near future things are moving to allow html modules which could be used with new web component apis to prevent the need for frameworks in large applications.

Also language features can inform API design. Promises were added to JS after a bunch of DOM APIs were already written, and now promises can be abortable. Wouldn’t we want the new reduced API set to also be built upon abortable promises? Yes we would. But if we wait a bit longer, we could also take advantage of newer language features being worked on in JS like structs and deeply immutable data structures.

TL;DR: It’s still too early to work on a DOM api for wasm. It’s better to wait for the DOM to stabalize first.