mirror-github-bspeice/speice.io
1
0
Fork 0
mirror of https://github.com/bspeice/speice.io synced 2024-11-14 14:08:09 -05:00
Code Issues Releases Wiki Activity

Further updates

Browse Source
This commit is contained in:
Bradlee Speice 2020-08-21 14:28:15 -04:00
parent fc502e10bc
commit e8a2c794f9
1 changed files with 8 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
_posts/2020-07-24-isomorphic-apps copy.md
View File

@ -75,6 +75,9 @@ it's now _feasible_.
Looking forward, the things I think could be beneficial to address are:
Put another way, these are the things that would be necessary for me to consider moving away from
Typescript:
- Template/starter project examples
- Being able to `yarn create` a project and have it already set up with two-way JS to Rust
bindings would go a long way towards reducing the currently painful setup using either
@ -89,4 +92,8 @@ Looking forward, the things I think could be beneficial to address are:
that run natively and are "glued" to Electron via Javascript. Further investigation to clarify
the pros/cons of each approach would be helpful; are there situations in which WASM offers
benefits over Neon? Vice-versa? Both WASM and Neon already require more complex setups than
typical JS/TS setups.
typical JS/TS setups. Using Rust stdlib instead of Node API's for system access is nice, being
forced into loose coupling is nice, but maybe the penalty associated with
bundling/distribution/etc. only makes sense for projects as large as Rust-analyzer, etc.
- Automatically generate bindings from TS definition files. Alternately, something like the JS
"@types" as a group to supervise maintenance of TS to Rust bindings?