I've used this for many projects that are still working to this day.
That said, i'm not impressed. A web-based solution is usually better performing, despite all the bloatware necessary. This says a lot about the state of software development unfortunately.
I'm curious as to how you came to that conclusion. Did you run any tests, or is it just a general observation? What's your computer hardware like? This isn't an accusation of anything, I promise I'm genuinely curious.
I've not done proper scientific comparisons, but had to reimplement some games as websites to make them reliably perform on Raspberry Pi's we used embedded.
This is a bit of an apples to oranges scenario, because the algorithm and architecture is not exactly the same, despite the game functioning identical.
The main weak points of LÖVE that we hit were mainly around embedded video playback though, which is probably very well optimized in chromium.
I dunno if this is what you were seeing, but LuaJIT has some serious performance issues on ARM.
https://love2d.org/forums/viewtopic.php?t=94760
It's unfortunate as Love2D is generally VERY snappy on x86. I used it on a 300MHz laptop back in the day.
I don’t usually push LÖVE to its limits because I tend to make simple games as a hobby but I do keep an eye on its framerate and often it‘s in the 100s of frames per second. So it may not be impressive (in sense of winning benchmarks) but it’s rarely perceivably slow.
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.
Optimized abstraction layer is still an abstraction layer. The web is like two or three of those.
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.
Explain this to electron haters.
step 1 htop
there isnt step 2, explain is over
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.
Nobody ever said in the thread that web is the most efficient platform, stop with your “designed for documents” trauma already.
Meanwhile that same computer could probably run Counter Strike at 400 FPS.
[dead]