UEFI Bindings for JavaScript

Oh hey, we've reached the "Metal" stage! https://www.destroyallsoftware.com/talks/the-birth-and-death...

Love this. An example of complete and total dominion over the machine. Great quote here too lol

> Prometheus stole fire from the gods and gave it to man. For this he was chained to a rock and tortured for eternity.

Can someone break this down for me? Looks like it's using... C? to load a js interpreter which bootstraps an API around all UEFI features? Do I have that right?

And, if so, does that mean that once the API has been bootstrapped, one could actually write an OS in js? Or are there other abstractions that would need to be migrated first?

I presume you'll add the network stack next, so that I can use my favourite, most useful packages?

  import isOdd from "https://unpkg.com/is-odd";

The choice of Duktape here is smart — it's one of the few JS engines that can actually run freestanding with minimal libc stubs, since it was designed for embedding in constrained environments. V8 or SpiderMonkey would be a nightmare to get running pre-boot.

What I find most interesting is the UEFI services binding approach. Rather than trying to abstract away the hardware, it exposes the raw EFI protocols (GraphicsOutput, SimpleFileSystem, etc.) directly to JS. That's a much more pragmatic design than trying to build a full HAL — you get to prototype UEFI applications rapidly while keeping the escape hatch to C for anything performance-critical.

Would love to see if anyone tries hooking this into UEFI's built-in network stack for PXE boot scripting. That could actually be useful beyond the novelty factor.

> If this makes you grin, you are probably holding the torch.

What if it makes me recoil in horror? screams into the void

This project will go places. Like every silly project not intended for production. :)

next step is to create a UEFI TUI using react (please don't)

I think there are two philosophies here:

1) JavaScript must stay in the box (aka in the browser).

2) JavaScript as a general purpose programming language.

While I can absolutely understand 1), I have had wanted to access the filesystem via JavaScript, just as I do via ruby or python, for local use only. After I googled for a while, they would say that this is not possible unless one uses npm/node. I think this shows that there are use cases here and the "default" JavaScript, aka 1), does not cover these. I do not like JavaScript, but based on my own use cases, I actually favour 2) far more than 1). So from that point of view, being able to access UEFI can also be useful. So why not.

Wow, this is cursed.

This is hilarious lol, it’ll be any day now before we get a full JS kernel. Garbage collection could be an obstacle, but I know there have been some kernels written in Go/Java before

Does it manage to support floats? I am not sure if those can be safely used in the UEFI environment. (I recall GRUB’s build of Lua being integer-only, and Linux avoiding the use of floating-point arithmetic in kernel mode, but I don’t remember the reason.)

"The Birth and Death of JavaScript" is coming true after all.

This is both so impressive and cursed that I'm not sure how to feel.

Turning in the widening gyre, the falcon cannot hear the falconer. The center cannot hold.. The old prophecy is coming true.

Could this be used as a learning tool? Rebooting the computer takes so much more time compared to reloading the browser tab. And you probably can't brick your computer.

I’m always amazed and slightly envious of what programming languages with large developer bases can do. I mean if a language is Turing complete it can do anything, but JavaScript takes this to the extreme.

Mind you I never said anything about quality or performance, obviously doing everything in JavaScript comes with it’s own issues but if you were to say that someone got JavaScript running in the Linux kernel as a POC I wouldn’t even be surprised

Awesome! Everything will be rewritten in JS

Can't wait for browser support for this... ;-)

Yeah, but your [developers] were so preoccupied with whether or not they could, they didn't stop to think if they should.

This is incredible.

> If this makes you grin you are probably holding a torch

Hilarious

Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should!

"Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should."

Pretty neat, though.

It begins!

Finally!

I love it.

But why?

Cursed