Open storopoli opened 8 months ago
I'm working on this. Dropping emscripten would be great because then we could move frontend.js
into the back end 🥳 via web-sys
. The problem currently is that web-sys
doesn't support emscripten.
Dropping emscripten would be great because then we could move
frontend.js
into the back end 🥳 viaweb-sys
Does this means that we can strongly type the API inputs and outputs and get rid of parse_[i|f]64
?
Does this means that we can strongly type the API inputs and outputs and get rid of
parse_[i|f]64
?
No, what would change is that instead of interacting with the DOM using Javascript (for example, via getElementById(id)
), we could interact directly with the DOM from within Rust. This would mean that we could drop the JSON communication between back end and front end because the back end can directly modify the DOM elements.
Ok so we have 's/JavaScript/Rust'
in all frontend?
But if we drop the JSON communication aren't we also dropping the parsing floats and ints into straight getting Rust's floats and ints?
Ok so we have
's/JavaScript/Rust'
in all frontend? But if we drop the JSON communication aren't we also dropping the parsing floats and ints into straight getting Rust's floats and ints?
Could be. I don't know whether HTML number elements are automatically interpreted as number types by web-sys
.
If we implement the (non-central) distributions in Rust, we can drop the
nmath
C library andemscripten
as dependencies.What we need:
cdf
(and hence thepdf
is included) andquantile
functions:Alternatives:
Make a PR toit is dead.statsrs
lib
sub-crate.Distributions.jl