It isn't web based? It's a set of Lua scripts that run locally

They are saying web based solutions often out perform LÖVE, even though you would expect the opposite because LÖVE doesn't have the bloat of a browser engine.

Browser engines are probably some of the most optimized pieces of software in existence, so it doesn't surprise me at all.

Love2D uses Luajit and directly calls established game libraries. The CPU usage should be far better for 2D games, luajit is faster than a browser's javascript jit. You can also create single exe games that are a few megabytes and not a few hundred megabytes.

Optimized abstraction layer is still an abstraction layer. The web is like two or three of those.

Explain this to electron haters.

Browser engines are optimized for displaying web pages, not for applications.

60MB+ for a calculator is not optimal.

explain that to my webgl TypeScript browser game running at 180+ FPS while rendering a large RPG tiled world with infinite procedurally JIT generated biomes, with heavy processing delegated to webworkers.

As you aren't posting code or stats I can't say much, but I'd bet a native app would still be smaller and more efficient, since you have to wrap what you're doing in an entire Chromium instance and deal with a web stack designed for documents, which is definitionally less efficient than a native alternative. Tiles aren't exactly cutting edge technology.

"Heavy processing delegated to webworkers?" That just sounds like threads but worse.

yep, native is faster for sure.

but webgl + web workers is good enough these days.

I can't share code sorry, the project got big and I have commercial plans.

But you can tell Gemini 3.1, Opus 4.6 or GPT 5.4 High to generate a demo and they do a decent job most of the times.

that's how I got started, seeing how it was possible to have good game performance with multi threaded workloads on a browser.

The first post in this subthread was literally a statement that "A web-based solution is usually better performing, despite all the bloatware necessary." And you literally joined in to support that assertion against "the Electron haters."

And it isn't trauma, it's literal fact. Electron isn't used because it's technically superior to native applications, it's used because web devs are a dime a dozen. It's popular for business reasons, not technical reasons. It works "well enough," but only because computers are really fast but there's only so much slack an OS can take up when even parts of it are Electron apps, and probably vibe-coded to boot.

Meanwhile that same computer could probably run Counter Strike at 400 FPS.

step 1 htop

there isnt step 2, explain is over

1Password has really been bugging me recently, all the emails they send have giant link buttons they want you to click without verifying where you're actually going

Our organic artisanal code is written by free-range developers

"free-range" means fully remote, right?

> So the stable state here is all humans eventually being locked out?

Yep. The most easy to implement stable state for any system where you're aiming to prevent misuse is to just prevent use

IIRC Thunderbird is a fork of Firefox, so it can do all of the web things your heart desires

My local build of helix is 20MB, did you use the suggested flags on the install guide page?

> Is there some established AI-agnostic protocol/interface?

AFAIK no

ACP?

https://agentcommunicationprotocol.dev/introduction/welcome

I desperately wish Helix would support virtual text (code folder, markdown links just showing the text when not selected), but the default keybinds and the way that selecting and editing text work just works too well in my brain to go anywhere else

I know it's not a proper fix, but helix does have `:reload` and `:reload-all` commands

I have reload-all bound to Ctrl-r

Same!

Nano not powerful, but it is friendly, it shows you its keybinds.

Vim is very powerful, but also very unfriendly.

The difference in effort required to pick up Nano vs Vim is HUGE