> Prometheus stole fire from the gods and gave it to man. For this he was chained to a rock and tortured for eternity.
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?
import isOdd from "https://unpkg.com/is-odd";What if it makes me recoil in horror? screams into the void
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.
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.
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
>looks inside
>node modules
Hilarious
Pretty neat, though.