Bun?

[nelsonic]

https://bun.sh -> https://github.com/oven-sh/bun

Written in Zig ref: dwyl/learn-zig#1

Note: We haven't seen a performance bottleneck in our Node projects recently.
(mostly because we've not been using Node in a perf-critical project for a while ...)
But the Bun appears to be faster at everything than Node.
So I'm thinking of doing a SPIKE just to get it working on a basic project. 💭

I wonder if this is just just a case of "Faster Horses" ... Or if there is a benefit to this beyond speed?

[ndrean]

Check why Vite and Bun by Evan You (code splitting)

Bun features Apple's Javascript runtime https://developer.apple.com/documentation/javascriptcore instead of V8.

[nelsonic]

Yeah, we've never needed to use code splitting. 🐌
It's a sign that the app is way too bloated. 😬
Our biggest ever front-end app was 147kb ... which I felt was silly (slow on mobile with slow 3G ... ⏳)
But it's good to know that Bun is not targeting client-side apps. 👌

JavaScriptCore https://github.com/WebKit/WebKit/tree/main/Source/JavaScriptCore is written in C++.
So is V8: https://nodejs.org/en/learn/getting-started/the-v8-javascript-engine#the-quest-for-performance ...
There shouldn't be that much of a perf diff ... but all benchmarks say there is a huge diff between Node and Bun 🤷‍♂️
https://www.builder.io/blog/bun-vs-node-js

Again, not using this yet. Just opening the issue to capture thoughts. 💭

[ndrean]

A disgression, but for example, LiveView ships a lot (!) of (meaningful) Javascript. I believe the code should be split and stripped out from the unused JS. Vite or Rollup (or the new Rust RollDown should be used. But this is the work of the team, not ours. Take a look at Livebook, JS heavy. Plenty of React is injected. I don't understand why they didn't go the SolidJS for example, almost 10 times lighter and not virtual DOM. Probably read-to-use libraries, I didn't go into the details.

[nelsonic]

Yeah, Livebook is suuuuper JS-heavy; but it's unlikely to be used on a slow internet connection. 💭
Even the biggest JS Apps are smaller than the average <img> ...
Not saying there's an excuse for bloated JS but there are apps that are complex and need a lot of code.
Agree that some splitting could help lighten Livebook ... 💭
bun might not be the tool for that. 👍

[ndrean]

But... they did something amazing with Kino.JS.Live. I am not doing any kind of self promotion but take a closer look at the Livebooks I did (any correction/issue is welcome!):

• WebRTC-SFU-demo. It showcases the power of message passing, the usage of the underlying WebSocket connection, and the ease to inject a third party JS library, Google's mediaPipe library. The result is impressive in this tiny Livebook.

• Another example is with the Livebook HLS-demo. Again, the power of message passing, the usage of a raw WebSocket connection to easily pass binary data, and again the integration of third party JS library.

I just though 👏👏

[ndrean]

bun setup with Liveview.

YT link below

[nelsonic]

Very good overview from Andrew. 👌
Not clear to me why we would need to go through the effort though ... 🤷‍♂️ 💭

[ndrean]

If you are not adding anything, indeed. Otherwise, you can start and stop bloating the JS, do dynamic imports, in other words, cutting your JS into pieces (all your hooks, web workers code etc), and thus potentially shipping less useless JS. 100k of JS, its not nothing

[nelsonic]

definitely not nothing. but feels like a niche problem in a LiveView App. 💭
Still, good to know it's possible and quite straightforward. 👌