• 11 Posts
  • 135 Comments
Joined 3 years ago
cake
Cake day: June 19th, 2023

help-circle



  • Bro, how are generators going to be faster?

    This is an AI article.


    My results:

    Firefox:

    Loop: 44ms - timer ended

    Generator: 4580ms - timer ended

    Node (uses same engine as deno, chrome, edge):

    Loop: 30.577ms

    Generator: 1.533s

    Safari (uses same engine as bun):

    Loop: 605.222ms

    Generator: 2804.669ms

    Bun (same engine as Safari but without needing to apologise for Safari):

    [17.52ms] Loop

    [297.17ms] Generator


    Generators are going to be slow because:

    • they’re going to be stack switching so much in JS runtimes which adds a lot of overhead
    • JS doesn’t have the other language features (yet) that you want to use with generators, which makes less folks want to use generators, which makes implementers not want to spend time optimising them. (Why bother trying to inline generator state when it’s probably going to change once the adjacent features come in?)

    Until generators don’t rely on stack switching, they’re always going to be super slow.






    • Bootstrap 2-5 sucked, but it was great for throwaway internal tools that will never become public.
    • Foundation died to bootstrap.
    • Pure was made by yahoo and went unmaintained so some other people wanted something like pure but they wanted to monetize it, then Pure got remaintained by it’s community
    • Tailwind isn’t great, it sold devs on a lie by limiting choices to limit mistakes, but limiting choices also restricted the features that devs needed to do their projects properly. They tried to figure out a way to add those features but suffered from gradual scope creep while trying to maintain it’s original lie and has ended up more complicated than it needed to be while being less featureful than what devs needed. What they should have done instead of making everything a utility class, was keep the build system (lightning css), add a token system (e.g. open props, or their own version of it), allow people to add their own css instead of trying to shoehorn it into a class, then went out of their way to teach people how to make things as classless as possible.


  • Yeah, I’m the lead on a bunch of websites that all have to be localised.

    There’s a lot of weird footguns to watch out for, and a lot of retraining devs when they’re used to only working on a single language/locale.

    Two biggest head scratchers I’ve had to deal with are computers treating “fr-FR” different from “fr-fr” (due to file system case-sensitivity differences between developers), and having to undo the coded assumption that languages and locales follow an [a-z]{2}-[a-z]{2} pattern (e.g. “en-gb”) once we stumbled upon Latino Americano: “es-419”.


    EDIT: My left ear really loves the Erlang talk.

    This fixes it:

    const audioContext = new AudioContext();
    const audioElement = audioContext.createMediaElementSource(document.querySelector("video"));
    audioContext.destination.channelCount = 1;
    audioElement.connect(audioContext.destination);
    



  • 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



  • 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?