Pauan

> if you do that then there's no easy way to write code that doesn't care whether it's in the browser or on node. ```rust #[cfg(all(target_arch = "wasm32", any(target_os =...

> That's not what I mean: there's no reason you should have to rebuild your rust code to run it in the browser compared to in node - you should...

> that's just not possible - when you deploy your package, you'll be deploying compiled webassembly - you can't have two different targets and have the same package work for...

> Without a generic "javascript" target rust *can't* do that. Why can't it? If you have some code which works on `wasm32-node-unknown` and `wasm32-web-unknown` (e.g. because it's generic JavaScript code,...

I thought about this some more, and I think these should be the new targets: ``` wasm32-unknown-javascript-web wasm32-unknown-javascript-node ``` This leaves open the possibility of later adding in a `wasm32-unknown-javascript`...

I was originally in favor of adding more targets, but now I think we should just have `wasm32-unknown-unknown` and use @aturon 's portability lint. The reason is because the situation...

I added in [Futures 0.2 support](https://github.com/koute/stdweb/pull/206) to stdweb. For quite a while now it has been possible to easily use Rust Futures and JavaScript Promises (including a mixture of both)...

@allsey87 Not much has happened in the past few meetings, so we stopped having them. The best way to stay informed about any changes is to watch the [wasm-bindgen](https://github.com/rustwasm/wasm-bindgen), [wasm-pack](https://github.com/rustwasm/wasm-pack),...

In addition to the usual vdom libraries (of which there are already many), I think we should also have support for a very different sort of DOM library, based on...

> What are the downsides to that style vs VDOM? The primary downside is needing to learn how to use Signals. Signals are really great, but they do have a...