10 ms·

SwiftWasm: Run Swift in Browsers

187 points by gyre007 7y ago

mlevental 7y ago
i really really really like swift. it's by far the best language i've ever used but i wish it weren't so "monoculture" (ios dev). i guess this is good for that but i really wish the open source port of foundation were the focus of the community.
- NobodyNada 7y ago
  I feel like the open source port of Foundation is in pretty good shape (especially compared to a few years ago). The really important classes are mostly complete ([0]); all that's left is primarily some of the advanced networking features (but many real-world networking applications use swift-nio instead anyway). I think what's most important is 1) language refinements via swift-evolution, and 2) projects which bring Swift to more domains, such as this for the client-side and Vapor for the server-side. [0]: https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/Status.md https://github.com/apple/swift-corelibs-foundation/blob/mast...
  - ken 7y ago
    The number of Linux issues on bugs.swift.org is still significant. Even when code compiles on Linux, it often doesn't work without crashing, or has different behavior. As someone who has tried to port (non-GUI) Swift code from Mac to Linux, I'd say there's still a ways to go.
    - NobodyNada 7y ago
      It's not always perfect, but it's certainly much more stable than it was a few years ago, and it continues to improve with each release. A few years ago I had to spend weeks with each new Swift release debugging segfaults and working around Foundation bugs and missing features, but lately my Mac-tested code usually works just fine on Linux (except for the occasional problem with C library dependencies or platform-specific APIs).
- deleted 7y ago
  [deleted]
- terhechte 7y ago
  I completely agree. I currently use Rust for all my cross platform use-cases. I'd love to have the same kind of library ecosystem ("crates") with Swift that I get with Rust. I hope we will get there slowly, with this and now that Windows almost works.
  - mlevental 7y ago
    i use rust too and some of the quality of life features from swift would make rust as good as swift, if not better. ?? rather than unwrap_or, as? and try?, if let, guard let. maybe there are reasons rust didn't incorporate this sugar having to do with the borrow checker i don't know but jeez i feel so burdened with boiler plate when i deal with optionals in rust.
    - sanxiyn 7y ago
      Rust has if let. It can't chain them yet, but the proposal to fix it (RFC 2497) was accepted and implementation is in progress.
      - terhechte 7y ago
        But Rust lacks `guard let x = a else { return }` which is one of the nicest additions of Swift. I know there were attempts to add it to Rust, but somehow the community really doesn't like it because a `let x = match a { Some(a) => a, None => return; }` is too similar. However I feel that guard also expresses the intent.
        gamegoblin 7y ago
        I frequently define a `guard!` macro in Rust that does exactly that. Seems clean enough to solve at the macro level -- doesn't necessarily need to be built into the language itself.
        newacctjhro 7y ago
        This kind of stuff should be on the stdlib if it's meant to be idiomatic.
- novok 7y ago
  Compile times and binary sizes are still issues although. There is a lot more optimization work left to do. It's a C++ v2 for a lot of the decisions they have made. And it doesn't scale that well when you have large code bases compared to other languages. Something like a javascript / flutter style hot reload really accelerates your dev cycle and I wish Swift had it too.
  - kitsunesoba 7y ago
    I maintain a non-trivial Swift app and while compile times are indeed longer than those of Objective-C, it’s nothing insurmountable and has improved a lot on the past couple of years. To me it’s more than worth the trade with all I gain with Swift compared to Obj-C. Hot reload is nice but to me is far from a dealbreaker, especially after your app is past the phase where you’re writing a bunch of new UI.
_bxg1 7y ago
This could be really cool given that Swift is already very JavaScript-like (Edit: TypeScript, really). A JavaScript-like that you can run on the web and is just faster out of the box is appealing. Now if only Apple would put more effort into cross-platform support for Swift...
- robbyking 7y ago
  How is Swift JavaScript-like?
  - _bxg1 7y ago
    Syntactically it's like someone took TypeScript and said, "what are a couple of tweaks we can perform to make it slightly more ergonomic, and also how do we get rid of the garbage collector".
    - jdmoreira 7y ago
      No. They are both typed languages but the feature set is not even comparable. Swift is a huge language
      - _bxg1 7y ago
        I'm not saying they're equivalent, I'm saying if you're used to reading TypeScript then Swift will be very familiar, syntactically. That matters if you're thinking about splitting your codebase across two languages.
- jjtheblunt 7y ago
  Swift is not at all Javascript-like, I think. Interesting.
- boringuser1 7y ago
  >Now if only Apple would put more effort into cross-platform support for Swift... You made the mistake of thinking Swift is a programming language and not just the Apple API.
GreaterFool 7y ago
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.
  - 7y ago
bouh 7y ago
Seems that swift is gaining a lot of traction. It has also have drawn interest in the Machine learning community
yingw787 7y ago
I love the talk on "The Birth and Death of JavaScript" by Gary Bernhardt: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... Highly encourage everybody to watch it and how people may interact with JavaScript more and more through things like WASM. Very funny talk too :)
- adamnemecek 7y ago
  There's little relationship between wasm and js.
  - diegoperini 7y ago
    The talk predicts that Js will be dead (for user space) the moment it conquers the OS. Dead in this context means it will be invisible to the app developer just like C.
  - _bxg1 7y ago
    The talk is more about the web as an application platform, and its values, coming down to OS userland. Whether that means JS or Wasm or both doesn't really matter.
  - bobajeff 7y ago
    At the time, asm.js looked like it was going to possibly be the universal bytecode that runs everything. WebAssembly hadn't gone public at that time.
- mythz 7y ago
  The age is nigh, its already become the easiest way to run and install Safari's JavaScriptCore on every platform: $ wapm install -g jsc Can then use `jsc` to execute .js, as a REPL or inline expressions: $ jsc -e "console.log([1,2,3].map(x => x*2).reduce((x,acc)=>acc+x))"
  - syspec 7y ago
    You can also symlink the JavaScript core framework which contains the executable there without installing anything as an alternative
pumanoir 7y ago
There is also https://www.elementscompiler.com/elements/default.aspx https://www.elementscompiler.com/elements/default.aspx which is a pretty good compiler and webassembly is one of the compile targets.
robertAngst 7y ago
>programming language developed by Apple Inc I would be too worried about Apple going full Apple and screwing devs to ever learn Swift. I think this is a permanent disadvantage for anything B2B.
- Razengan 7y ago
  C#/.Net has done fine despite its birth in a company with a far worse reputation for abandonment. Same for Go.
  - simonh 7y ago
    Java ending up with Oracle was a bit of a worst case scenario as well, yet people still write Java. Exclude languages originating with a big corporate sponsor or owner, and that's half the development ecosystem gone.
    - Razengan 7y ago
      Yes, I mean look what just popped up today: "Microsoft Throws in the Towel on UWP, Elevates Win32" https://news.ycombinator.com/item?id=19883351 https://news.ycombinator.com/item?id=19883351 Before I jumped ship to the Apple ecosystem around 10 years ago, I was even then already sick of Microsoft abandoning or being indecisive about their platforms.
mastrsushi 7y ago
Can someone explain to me what makes Wasm any better and/or different than Javascript bytecode.
- sanxiyn 7y ago
  WebAssembly has 64-bit integers and 32-bit floating points, which is difficult to do fast in JavaScript because everything is 64-bit floating points there. (32-bit integers are exact in 64-bit floating points, so that works.) This is the main advantage. WebAssembly is also easier and faster to parse for now, but won't be for long, because JavaScript binary AST work is in progress: https://github.com/binast https://github.com/binast JavaScript has better access to DOM and is superior otherwise.
  - mastrsushi 7y ago
    Wouldn't fixed 64-bit integers be more of a memory usage issue than performance? I'd argue that having to decide between 32 and 64 would unavoidably add some slow down.
    - sanxiyn 7y ago
      WebAssembly 64-bit integer arithmetics compile to machine instructions on 64-bit architectures. To do that in JavaScript, you need to pattern match on long multiplication emulated with 32-bit integers.
  - MiroF 7y ago
    And wasm is a compilation target for languages that aren’t JS, a pretty big advantage in my book
    - sanxiyn 7y ago
      JS also is a compilation target for languages that aren't JS, so that is no advantage. What advantage there is boils down to 64-bit integers and 32-bit floating points.

187 points by gyre007 7y ago

i really really really like swift. it's by far the best language i've ever used but i wish it weren't so "monoculture" (ios dev). i guess this is good for that but i really wish the open source port of foundation were the focus of the community.

NobodyNada 7y ago
I feel like the open source port of Foundation is in pretty good shape (especially compared to a few years ago). The really important classes are mostly complete ([0]); all that's left is primarily some of the advanced networking features (but many real-world networking applications use swift-nio instead anyway). I think what's most important is 1) language refinements via swift-evolution, and 2) projects which bring Swift to more domains, such as this for the client-side and Vapor for the server-side. [0]: https://github.com/apple/swift-corelibs-foundation/blob/master/Docs/Status.md https://github.com/apple/swift-corelibs-foundation/blob/mast...
- ken 7y ago
  The number of Linux issues on bugs.swift.org is still significant. Even when code compiles on Linux, it often doesn't work without crashing, or has different behavior. As someone who has tried to port (non-GUI) Swift code from Mac to Linux, I'd say there's still a ways to go.
  - NobodyNada 7y ago
    It's not always perfect, but it's certainly much more stable than it was a few years ago, and it continues to improve with each release. A few years ago I had to spend weeks with each new Swift release debugging segfaults and working around Foundation bugs and missing features, but lately my Mac-tested code usually works just fine on Linux (except for the occasional problem with C library dependencies or platform-specific APIs).
deleted 7y ago
[deleted]
terhechte 7y ago
I completely agree. I currently use Rust for all my cross platform use-cases. I'd love to have the same kind of library ecosystem ("crates") with Swift that I get with Rust. I hope we will get there slowly, with this and now that Windows almost works.
- mlevental 7y ago
  i use rust too and some of the quality of life features from swift would make rust as good as swift, if not better. ?? rather than unwrap_or, as? and try?, if let, guard let. maybe there are reasons rust didn't incorporate this sugar having to do with the borrow checker i don't know but jeez i feel so burdened with boiler plate when i deal with optionals in rust.
  - sanxiyn 7y ago
    Rust has if let. It can't chain them yet, but the proposal to fix it (RFC 2497) was accepted and implementation is in progress.
    - terhechte 7y ago
      But Rust lacks `guard let x = a else { return }` which is one of the nicest additions of Swift. I know there were attempts to add it to Rust, but somehow the community really doesn't like it because a `let x = match a { Some(a) => a, None => return; }` is too similar. However I feel that guard also expresses the intent.
      - gamegoblin 7y ago
        I frequently define a `guard!` macro in Rust that does exactly that. Seems clean enough to solve at the macro level -- doesn't necessarily need to be built into the language itself.
        newacctjhro 7y ago
        This kind of stuff should be on the stdlib if it's meant to be idiomatic.
novok 7y ago
Compile times and binary sizes are still issues although. There is a lot more optimization work left to do. It's a C++ v2 for a lot of the decisions they have made. And it doesn't scale that well when you have large code bases compared to other languages. Something like a javascript / flutter style hot reload really accelerates your dev cycle and I wish Swift had it too.
- kitsunesoba 7y ago
  I maintain a non-trivial Swift app and while compile times are indeed longer than those of Objective-C, it’s nothing insurmountable and has improved a lot on the past couple of years. To me it’s more than worth the trade with all I gain with Swift compared to Obj-C. Hot reload is nice but to me is far from a dealbreaker, especially after your app is past the phase where you’re writing a bunch of new UI.

_bxg1 7y ago

This could be really cool given that Swift is already very JavaScript-like (Edit: TypeScript, really). A JavaScript-like that you can run on the web and is just faster out of the box is appealing. Now if only Apple would put more effort into cross-platform support for Swift...

robbyking 7y ago
How is Swift JavaScript-like?
- _bxg1 7y ago
  Syntactically it's like someone took TypeScript and said, "what are a couple of tweaks we can perform to make it slightly more ergonomic, and also how do we get rid of the garbage collector".
  - jdmoreira 7y ago
    No. They are both typed languages but the feature set is not even comparable. Swift is a huge language
    - _bxg1 7y ago
      I'm not saying they're equivalent, I'm saying if you're used to reading TypeScript then Swift will be very familiar, syntactically. That matters if you're thinking about splitting your codebase across two languages.
jjtheblunt 7y ago
Swift is not at all Javascript-like, I think. Interesting.
boringuser1 7y ago
>Now if only Apple would put more effort into cross-platform support for Swift... You made the mistake of thinking Swift is a programming language and not just the Apple API.

GreaterFool 7y ago

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.
- 7y ago

bouh 7y ago

Seems that swift is gaining a lot of traction. It has also have drawn interest in the Machine learning community

yingw787 7y ago

I love the talk on "The Birth and Death of JavaScript" by Gary Bernhardt: https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death... Highly encourage everybody to watch it and how people may interact with JavaScript more and more through things like WASM. Very funny talk too :)

adamnemecek 7y ago
There's little relationship between wasm and js.
- diegoperini 7y ago
  The talk predicts that Js will be dead (for user space) the moment it conquers the OS. Dead in this context means it will be invisible to the app developer just like C.
- _bxg1 7y ago
  The talk is more about the web as an application platform, and its values, coming down to OS userland. Whether that means JS or Wasm or both doesn't really matter.
- bobajeff 7y ago
  At the time, asm.js looked like it was going to possibly be the universal bytecode that runs everything. WebAssembly hadn't gone public at that time.
mythz 7y ago
The age is nigh, its already become the easiest way to run and install Safari's JavaScriptCore on every platform: $ wapm install -g jsc Can then use `jsc` to execute .js, as a REPL or inline expressions: $ jsc -e "console.log([1,2,3].map(x => x*2).reduce((x,acc)=>acc+x))"
- syspec 7y ago
  You can also symlink the JavaScript core framework which contains the executable there without installing anything as an alternative

pumanoir 7y ago

There is also https://www.elementscompiler.com/elements/default.aspx https://www.elementscompiler.com/elements/default.aspx which is a pretty good compiler and webassembly is one of the compile targets.

robertAngst 7y ago

>programming language developed by Apple Inc I would be too worried about Apple going full Apple and screwing devs to ever learn Swift. I think this is a permanent disadvantage for anything B2B.

Razengan 7y ago
C#/.Net has done fine despite its birth in a company with a far worse reputation for abandonment. Same for Go.
- simonh 7y ago
  Java ending up with Oracle was a bit of a worst case scenario as well, yet people still write Java. Exclude languages originating with a big corporate sponsor or owner, and that's half the development ecosystem gone.
  - Razengan 7y ago
    Yes, I mean look what just popped up today: "Microsoft Throws in the Towel on UWP, Elevates Win32" https://news.ycombinator.com/item?id=19883351 https://news.ycombinator.com/item?id=19883351 Before I jumped ship to the Apple ecosystem around 10 years ago, I was even then already sick of Microsoft abandoning or being indecisive about their platforms.

mastrsushi 7y ago

Can someone explain to me what makes Wasm any better and/or different than Javascript bytecode.

sanxiyn 7y ago
WebAssembly has 64-bit integers and 32-bit floating points, which is difficult to do fast in JavaScript because everything is 64-bit floating points there. (32-bit integers are exact in 64-bit floating points, so that works.) This is the main advantage. WebAssembly is also easier and faster to parse for now, but won't be for long, because JavaScript binary AST work is in progress: https://github.com/binast https://github.com/binast JavaScript has better access to DOM and is superior otherwise.
- mastrsushi 7y ago
  Wouldn't fixed 64-bit integers be more of a memory usage issue than performance? I'd argue that having to decide between 32 and 64 would unavoidably add some slow down.
  - sanxiyn 7y ago
    WebAssembly 64-bit integer arithmetics compile to machine instructions on 64-bit architectures. To do that in JavaScript, you need to pattern match on long multiplication emulated with 32-bit integers.
- MiroF 7y ago
  And wasm is a compilation target for languages that aren’t JS, a pretty big advantage in my book
  - sanxiyn 7y ago
    JS also is a compilation target for languages that aren't JS, so that is no advantage. What advantage there is boils down to 64-bit integers and 32-bit floating points.