gr4vityWall

Thanks for the link. Seems like it isn't ready for general usage yet.

Wasn't familiar with it, looks interesting.

Some animations are painfully slow, though. After opening a menu[0], it takes a long time to close once you click outside.

How well does it work without JS? I assume that's how the ripple effect is implemented.

[0] - https://www.beercss.com/#:~:text=Menus,-code

Edit: they have documented what works and what doesn't with JS disabled here : https://github.com/beercss/beercss/blob/main/docs/JAVASCRIPT...

That file hasn't been updated in a while. Not sure if nothing has changed since then, or if it's outdated.

It seems similar in concept to Haxe, but focused on writing libraries which are then called from the target language, rather than building your whole application in Fusion. Is that correct?

How are exceptions translated to languages which don't have exceptions, like C?

The amount of targets seems impressive, but I don't see anything resembling a standard library. Usually, it's in the standard library where diverging behavior between targets shows up. Haxe's documentation tends to cover those issues, and lets you know when a behavior is target-dependent, or unspecified. They do try to be consistent between targets whenever possible in a performant way.

Loreline[0] is a recent project which leverages Haxe to build a cross-platform library. Is there a similar project showcasing how Fusion can be used for that?

[0] - https://loreline.app/en/docs/

There's QuickJS, LLRT, Rhino, and GameMaker is about to get TS/JS support.

I remember reading that article some years ago.

Boy, wasn't I surprised when I ran into this PR. I'm excited.

Is it possible to merge it, but keep it disabled by default? This could allow users to play with it on Bun while maintaining the expected behavior of JSC.

Maybe a separate build could work too.

> This isn't true, but I understand why you feel that way.

By all means, I'd be happy to be proven wrong. Last effort I saw on this direction was node-gui + React. I believe that project isn't being maintained. Being able to use something like Vite to build desktop programs would be a blessing.

QML doesn't have a way to define interfaces with JSX and doesn't integrate with the wider JS tooling. From my very limited experience, it still feels too close to the C++ world.

I think Qt is only missing well-written, feature-complete bindings for a major JS runtime, including support for hot reload.

Developing UIs without hot reloading is too painful.

From what I can tell, they do full page reloads when visiting a different page, and use Preact for building UIs using components. Those components and pages then get rendered on the server as typical template engines.

OpenFL should cover your needs pretty well. https://openfl.org

I have a 120GB SSD from 2013 that saw typical gaming/workstation usage since it was bought, and it still works fine.

I think repairability is important, but I don't think it will stop those laptops from being popular.

Great work. I believe used M1/M2 machines will be favored by young developers as their personal fun laptop in a few years, like the Thinkpad T420 used to be. For different reasons, of course.

Do the M4 and M5 GPUs also change a lot from the M3? I hope it's not too much work to get those going once M3 is usable.

> There's an underlying assumption that server-side code is inherently good, performant, and well crafted.

I didn't read it that way. I believe the underlying assumption is that the server-side code won't run in a power-constrained computer, thus having more performance headroom.

I'm not a LLM, but you're absolutely right. That conclusion is sound.

Haxe has a really elegant solution to this in the form of Abstracts[0][1]. I wonder why this particular feature never became popular in other languages, at least to my knowledge.

0 - https://code.haxe.org/category/abstract-types/color.html

1 - https://haxe.org/manual/types-abstract.html

They seem to have a schema solution from their docs: https://docs.modelence.com/stores

How does your framework compares to Meteor.js? I see similarities in the problems being solved, and the tech stack being used. Do you have examples of the idiomatic way of client/server communication in Modelence?

I think the line between the framework and the AI code generation tool is blurry.

In principle I agree with you. But people seem to like using a game-specific launcher for games like Steam, GOG, Heroic Launcher, Hydra Launcher, etc.

Alternatively, work on developing protocols for game launchers instead. Get the Heroic Launcher devs and devs from other launchers to work on a common interface.

I appreciate that attitude. Keep it up.

Their Github repos seem fairly active, from a quick look: https://github.com/TritonDataCenter

Their website is indeed out of date. Reminds me of Haxe in that aspect. The language itself is receiving significant development, but the website looks abandoned, and no new blog posts have been posted in a while.

These days, you're indeed better off using Illumos/SmartOS to run GNU/Linux zones/VMs, rather than native applications, from what I hear.

I know someone who runs SmartOS for their home server. They only had good things to say about it. It's been working well for a few years now.

Running the benchmark from the article on my laptop (M4 Macbook Air) had a few interesting results:

* when running the script with Node.js, the results are inline with the article (SoA is the fastest)

* Bun is slower than Node.js with both SoA and AoS.

* Bun has similar performance between SoA and AoS.

* in Bun, Interleaved is the fastest one by a significant margin. This is consistent through runs.

% bun bench.js

AoS: 924.54ms

SoA: 1148.57ms

Interleaved: 759.01ms

Bun's performance profile seems very different from Firefox and V8-based runtimes there. I wonder how QuickJS would fare. The article didn't mention the CPU used either, the performance difference may be dependent on the architecture as well.

You give up on hot reloading when using dear imgui and C++, though. There's nothing comparable to Vite in most ecosystems for building desktop programs, as far as I'm aware.

Tooling is the problem, I've used imgui and it's pretty good. But not nearly as practical for prototyping UI.

I hope they upstream their implementation of Web Extensions to WebKit.

I'm not interested in using a proprietary browser, and hope for a release under a free license at some point. But a free WebKit-based browser with Web Extensions could have interesting properties regarding battery life on mobile GNU workstations.

> Would it be more correct to say it doesn’t necessarily mean free as in beer

Yes, I believe so.

I see it as English-centric, rather than US-centric. That differentiation isn't necessary in most (all?) languages.

Adopting the word "gratis" when the speaker means "at no monetary cost" also helps clarify things.

After reading the, I don't feel convinced abtout the runtime performance advantages of WASM over asm.js. he CPU features mentioned could be added to JS runtimes. Toolchain improvements could go both ways, and I expect asm.js would benefit from JIT improvements over the years.

I agree 100% with the startup time arguments made by the article, though. No way around it if you're going through the typical JS pipeline in the browser.

The argument for better load/store addressing on WASM is solid, and I expect this to have higher impact today than in 2017, due to the huge caches modern CPUs have. But it's hard to know without measuring it, and I don't know how hard it would be to isolate that in a benchmark.

Thank you for linking it. It was a fun read. I hope my post didn't sound adversarial to any arguments you made. I wonder what asm.js could have been if it was formally specified, extended and optimized for, rather than abandoned in favor of WASM.