From e8a2c794f94b10dc5ad549ecbc300b446ca532ae Mon Sep 17 00:00:00 2001 From: Bradlee Speice Date: Fri, 21 Aug 2020 14:28:15 -0400 Subject: [PATCH] Further updates --- _posts/2020-07-24-isomorphic-apps copy.md | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/_posts/2020-07-24-isomorphic-apps copy.md b/_posts/2020-07-24-isomorphic-apps copy.md index 682fdf4..5216c6f 100644 --- a/_posts/2020-07-24-isomorphic-apps copy.md +++ b/_posts/2020-07-24-isomorphic-apps copy.md @@ -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?