Post

the latest version of Porffor features ESM support! it not only removes needing a bundler beforehand but also makes compilation much faster as we can split C across modules

😅 what I meant is, these are all frontend libraries, which require a frontend your compiler doesn't have any way to actually render a DOM, does it?

Have a look at this thread, which you might find interesting: bsky.app/profile/joe....

Joe Pea@joe.trusktr.io

A browser built with HTML elements for its Ui, how it should have always been! But! Funny enough these days we can also compile DOM code (including Custom Elements written in TypeScript) to native code statically linked to DOM without JavaScript. So browser UIs can go back to native technically. 🙃

0 reposts2 likes

well, interesting, although... I'm not sure we need more excuses for every little app to ship a 250 MB bundled browser? 😅 also I'd expect the difference between native and JS to be very marginal for most apps - the DOM is already the bottleneck, JS is doing very little actual work in most apps 😊

I'm not making any claims wrt to that thread other than it is interesting. But I think the idea is that if you are going to ship something Electron-like, yon could compile your JS and therefore *not* include V8, and also *not* include Node, which results in a smaller package.

We can also instrument the code, run app tests, and prune all unused code paths from the output. The tests would need to be good, f.e. with 100% coverage. Easy for AI to maximize coverage with arbitrary code even if the tests aren't great, just for trimming the output.

Games do this. If I install multiple games on my device, it's unlikely that they all use a dynamically shared/linked runtime (unless it's only iOS games using strictly iOS APIs for example). Another issue is someone might not want to download a specific browser they don't use just for an app.