HN user

gr4vityWall

930 karma
Posts8
Comments275
View on HN

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/

Deno Desktop 1 month ago

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

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.

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.

SmartOS 6 months ago

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.

SmartOS 6 months ago

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

SmartOS 6 months ago

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.

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.