The wasm ABI allows for a bit more flexibility than the C one.
I’m not sure how much impact it has on practice (probably very little, otherwise somebody would have fixed it), but in native code there’s a lot of potential for mismatching behaviors from the two different runtimes.
You can even compile Fortran code to wasm and run it on a web browser. Who need Javascript’s puny 64bit floating point precision when you can have Fortran’s superior 128bit floating point precision?
No, but GUI frameworks can generate it for you. Same goes for DOM access, for which there’s normally only a JavaScript API.
So, you’ll likely want to read JS, when researching what events or properties you can read/write for certain HTML nodes in the DOM, but with a mature GUI framework, you should not need to write any JS.
I’m choosing the third side: WebAssembly
Blazingly fast 🦀🦀🦀
Incredibly powerful type system λλλ
And the best part, those two interop better than in native code.
Really? Why is that?
The wasm ABI allows for a bit more flexibility than the C one.
I’m not sure how much impact it has on practice (probably very little, otherwise somebody would have fixed it), but in native code there’s a lot of potential for mismatching behaviors from the two different runtimes.
Oh I had no idea, thanks for explaining!
You can even compile Fortran code to wasm and run it on a web browser. Who need Javascript’s puny 64bit floating point precision when you can have Fortran’s superior 128bit floating point precision?
Have they finally dumped the required js stub loader?
No, but GUI frameworks can generate it for you. Same goes for DOM access, for which there’s normally only a JavaScript API.
So, you’ll likely want to read JS, when researching what events or properties you can read/write for certain HTML nodes in the DOM, but with a mature GUI framework, you should not need to write any JS.