3 ms·

What would be more interesting than running Swift in the browser is running Wasm on Android and iOS. That would bring some true code sharing between the browser

What would be more interesting than running Swift in the browser is running Wasm on Android and iOS. That would bring some true code sharing between the browser, mobile and backend! And also easily allow constructing apps using pieces written in any of the languages that nicely compile to Wasm.

gok 7y ago
Why not just compile the Swift to native Android and iOS code?
- GreaterFool 7y ago
  Because Wasm could be used mobile as a native first class citizen, not limited to running within a browser or some browser view. And then Wasm code can be shared between multiple environments including mobile, browser, edge (CloudFlare workers), backend (multiple Wasm runtimes are emerging right now and some of then are very performant). And then one would not be limited to Swift but could use any language that compiles to Wasm. So code reuse would effectively skyrocket. Wasm can be used in every corner of computing spectrum. It doesn't mean it's some perfect tool to solve all problems but it can lead to interesting places and those are worth exploring.
  - millstone 7y ago
    Honestly this reads like a solution in search of a problem. Native code will be faster in every way. Wasm's strengths are in running untrusted code - its sandbox is quite strict. So the use case for wasm on mobile is downloading code dynamically. Wasm's competition in this space is JS, not native code.
    - jamil7 7y ago
      > Native code will be faster in every way. Sure, but I believe a lot of people will be willing to make a performance tradeoff for that convinience.
- jamil7 7y ago
  Not sure about the OP but personally I use WKWebView in a few places to render some HTML from a server for parts of my app that a user can then interact which needs to run some JS. For me it could mean being able to keep more of my app in a single language and port peices of it to other platforms.
nickmain 7y ago
Unfortunately WASM on iOS could only be interpreted, not JITed, due to protected memory. Also WASM works in Mobile Safari and SFSafariViewController, but not in WKWebView - which limits its interaction with an app.
- GreaterFool 7y ago
  Wasm is great for sandboxing so iOS could make Wasm first-class native citizen. Then Wasm module could have access to anything and everything iOS and one could write "native" iOS applications using any language that compiles to Wasm.
  - manwe150 7y ago
    Is it though (a good sandbox, I mean)? A modern OS already tries very hard to be a sandbox that can run anything. What does Wasm bring to the table for iOS? I also feel like this is just a weird year for software, because we've got Wasm making huge strides ("let's make it easy to sandbox everything like javascript"), discovered Spectre ("oops, our assumptions about javascript being a good sandbox were maybe wrong, we apparently need to use hardware-enforced process separation"), but also many other permutations of these things in other spaces (such as the WSL2 announcement of a new integrated Windows-Linux environment, vs. containers vs. VMs vs. WSL1 vs. Wine vs. micro-services).

gok 7y ago

Why not just compile the Swift to native Android and iOS code?

GreaterFool 7y ago
Because Wasm could be used mobile as a native first class citizen, not limited to running within a browser or some browser view. And then Wasm code can be shared between multiple environments including mobile, browser, edge (CloudFlare workers), backend (multiple Wasm runtimes are emerging right now and some of then are very performant). And then one would not be limited to Swift but could use any language that compiles to Wasm. So code reuse would effectively skyrocket. Wasm can be used in every corner of computing spectrum. It doesn't mean it's some perfect tool to solve all problems but it can lead to interesting places and those are worth exploring.
- millstone 7y ago
  Honestly this reads like a solution in search of a problem. Native code will be faster in every way. Wasm's strengths are in running untrusted code - its sandbox is quite strict. So the use case for wasm on mobile is downloading code dynamically. Wasm's competition in this space is JS, not native code.
  - jamil7 7y ago
    > Native code will be faster in every way. Sure, but I believe a lot of people will be willing to make a performance tradeoff for that convinience.
jamil7 7y ago
Not sure about the OP but personally I use WKWebView in a few places to render some HTML from a server for parts of my app that a user can then interact which needs to run some JS. For me it could mean being able to keep more of my app in a single language and port peices of it to other platforms.

nickmain 7y ago

Unfortunately WASM on iOS could only be interpreted, not JITed, due to protected memory. Also WASM works in Mobile Safari and SFSafariViewController, but not in WKWebView - which limits its interaction with an app.

GreaterFool 7y ago
Wasm is great for sandboxing so iOS could make Wasm first-class native citizen. Then Wasm module could have access to anything and everything iOS and one could write "native" iOS applications using any language that compiles to Wasm.
- manwe150 7y ago
  Is it though (a good sandbox, I mean)? A modern OS already tries very hard to be a sandbox that can run anything. What does Wasm bring to the table for iOS? I also feel like this is just a weird year for software, because we've got Wasm making huge strides ("let's make it easy to sandbox everything like javascript"), discovered Spectre ("oops, our assumptions about javascript being a good sandbox were maybe wrong, we apparently need to use hardware-enforced process separation"), but also many other permutations of these things in other spaces (such as the WSL2 announcement of a new integrated Windows-Linux environment, vs. containers vs. VMs vs. WSL1 vs. Wine vs. micro-services).