glen/dyna3
1
0
Fork 0
Code Issues 14 Pull Requests 1 Actions Projects Releases 2 Wiki Activity

List reactive web frameworks for Scala

Vectornaut 2024-08-07 21:30:06 +00:00
parent 2e6af44de3
commit d9cf029e6e
1 changed files with 4 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
Coding-environment.md

@ -70,6 +70,10 @@ The gist of the most significant argument for the upper version is that one read
- Actually, there is Scala.js that compiles to JavaScript, that seems quite mature. There does not currently seem to be a way to compile to WASM, but it appears to be pretty close as an optional backend in Scala.js (see https://github.com/scala-js/scala-js/issues/4928). One can use existing JavaScript frameworks via Scala.js -> JavaScript; there also exist Scala frameworks/servers like [Xitrum](https://xitrum-framework.github.io/) but not sure what that does as far as client-side computation. So it seems as though trying to go with Scala would at least at first mean sticking within JavaScript per se, so there is a potential trap if in fact WASM ends up being needed for performance reasons (assuming that a language well-compiled to WASM will be faster than basically equivalent JavaScript). On the other hand, the ongoing work for the [WASM backend](https://dev.virtuslab.com/p/scala-to-webassembly-how-and-why) could provide a way out of that trap, although some commenters online say that the WASM backend will not likely be any faster than the pure-JavaScript backend because it will not be able to get close enough to the underlying WASM architecture to take advantage of its possible speedups. So there is some risk here; not sure how to evaluate whether it's worth looking deeper? - Actually, there is Scala.js that compiles to JavaScript, that seems quite mature. There does not currently seem to be a way to compile to WASM, but it appears to be pretty close as an optional backend in Scala.js (see https://github.com/scala-js/scala-js/issues/4928). One can use existing JavaScript frameworks via Scala.js -> JavaScript; there also exist Scala frameworks/servers like [Xitrum](https://xitrum-framework.github.io/) but not sure what that does as far as client-side computation. So it seems as though trying to go with Scala would at least at first mean sticking within JavaScript per se, so there is a potential trap if in fact WASM ends up being needed for performance reasons (assuming that a language well-compiled to WASM will be faster than basically equivalent JavaScript). On the other hand, the ongoing work for the [WASM backend](https://dev.virtuslab.com/p/scala-to-webassembly-how-and-why) could provide a way out of that trap, although some commenters online say that the WASM backend will not likely be any faster than the pure-JavaScript backend because it will not be able to get close enough to the underlying WASM architecture to take advantage of its possible speedups. So there is some risk here; not sure how to evaluate whether it's worth looking deeper?
- Nevertheless, being the statically-typed significant-indentation language with the highest SO score is suggestive that we should put a bit of effort into seeing what using it would be like. - Nevertheless, being the statically-typed significant-indentation language with the highest SO score is suggestive that we should put a bit of effort into seeing what using it would be like.
- Scala and Java have [a bunch](https://statr.me/2015/09/an-overview-of-linear-algebra-libraries-in-scala-java/) of numerical linear algebra packages. Some of them have been [benchmarked](http://lessthanoptimal.github.io/Java-Matrix-Benchmark/runtime/2013_10_Corei7v2600/) against each other. The [EJML](http://ejml.org/wiki/index.php) seems to dominate the benchmarks for matrices smaller than 100×100. The benchmarks don't include [Breeze](https://github.com/scalanlp/breeze) or [Slash](https://github.com/dragonfly-ai/slash), though. So far, Slash has been the easiest to get up and running. - Scala and Java have [a bunch](https://statr.me/2015/09/an-overview-of-linear-algebra-libraries-in-scala-java/) of numerical linear algebra packages. Some of them have been [benchmarked](http://lessthanoptimal.github.io/Java-Matrix-Benchmark/runtime/2013_10_Corei7v2600/) against each other. The [EJML](http://ejml.org/wiki/index.php) seems to dominate the benchmarks for matrices smaller than 100×100. The benchmarks don't include [Breeze](https://github.com/scalanlp/breeze) or [Slash](https://github.com/dragonfly-ai/slash), though. So far, Slash has been the easiest to get up and running.
- Reactive web frameworks include:
- [Laminar](https://laminar.dev/). Confusing variety of similar-looking ways to do things. Documentation very difficult to use.
- [Outwatch](https://outwatch.github.io/). Documentation looks detailed and well-written. Build environment seems complicated, but maybe it's not all necessary?
- [REScala](https://www.rescala-lang.com/). Actively developed. Nice documentation of reactive data structures, but little explanation of how to use these in a web app. The [to-do list example](https://github.com/rescala-lang/todolist-standalone-example) and [other examples](https://github.com/guidosalva/REScala-examples) are valuable.
- I think the musings/reservations I discuss above really just come down to the question of whether adopting a language originally tied to the JVM, and for the moment for our purposes tied to the JavaScript engines in browsers, will ultimately hobble the **performance** of Dyna3, which will surely have compute-intensive aspects. One way we could get at this is do the hello, world app in Scala (which should be trivial via Scala.js, as it will end up 100% JavaScript when compiled), and then do the same "Linear algebra hello world" in Scala as in other systems under consideration in which the linear algebra will be compiled to WASM, and make sure the linear algebra task being performed is a noticeable compute-time consumer, and then just benchmark the identical task in Scala and the other candidates. - I think the musings/reservations I discuss above really just come down to the question of whether adopting a language originally tied to the JVM, and for the moment for our purposes tied to the JavaScript engines in browsers, will ultimately hobble the **performance** of Dyna3, which will surely have compute-intensive aspects. One way we could get at this is do the hello, world app in Scala (which should be trivial via Scala.js, as it will end up 100% JavaScript when compiled), and then do the same "Linear algebra hello world" in Scala as in other systems under consideration in which the linear algebra will be compiled to WASM, and make sure the linear algebra task being performed is a noticeable compute-time consumer, and then just benchmark the identical task in Scala and the other candidates.
### C++ with our own civet-like syntax unmangler (SO 18.3/53.1) ### C++ with our own civet-like syntax unmangler (SO 18.3/53.1)