|
| 1 | +--- |
| 2 | +date: 2020-11-30 14:34 |
| 3 | +description: An update on what happened in the SwiftWasm ecosystem during November 2020. |
| 4 | +--- |
| 5 | +# What's new in SwiftWasm #4 |
| 6 | + |
| 7 | +## SwiftWasm 5.3.0 and 5.3.1 releases |
| 8 | + |
| 9 | +As you may have seen in [our previous post](https://blog.swiftwasm.org/posts/5-3-released/), we've |
| 10 | +published [our first stable |
| 11 | +release](https://github.com/swiftwasm/swift/releases/tag/swift-wasm-5.3.0-RELEASE) recently. Shortly |
| 12 | +after that, [@flavio](https://github.com/flavio) reported [an issue |
| 13 | +with `JSONDecoder`](https://github.com/swiftwasm/swift/issues/2223). Following [an |
| 14 | +investigation](https://github.com/swiftwasm/swift/pull/2240) by |
| 15 | +[@kateinoigakukun](https://github.com/kateinoigakukun) into the root cause of the issue, we've |
| 16 | +published [SwiftWasm |
| 17 | +5.3.1](https://github.com/swiftwasm/swift/releases/tag/swift-wasm-5.3.1-RELEASE), which also |
| 18 | +included updates from the upstream 5.3.1 patch release. |
| 19 | + |
| 20 | +(If you're interested in technical details, the `JSONDecoder` issue was caused by a peculiar |
| 21 | +assumption about memory layout in Swift runtime, which wasn't applicable to WebAssembly's linear |
| 22 | +memory. [Check the PR diff](https://github.com/swiftwasm/swift/pull/2240/files) for |
| 23 | +more details.) |
| 24 | + |
| 25 | +## Libraries |
| 26 | + |
| 27 | +### JavaScriptKit |
| 28 | + |
| 29 | +A major update since the latest 0.8.0 release of JavaScriptKit is [newly added support |
| 30 | +for throwing functions](https://github.com/swiftwasm/JavaScriptKit/pull/102) developed |
| 31 | +by [@kateinoigakukun](https://github.com/kateinoigakukun). It required an update |
| 32 | +to the JavaScript runtime part, but was an additive change to the Swift API. As we try to publish |
| 33 | +releases regularly, [new 0.9.0 release](https://github.com/swiftwasm/JavaScriptKit/releases/tag/0.9.0) |
| 34 | +was tagged that includes this feature. |
| 35 | + |
| 36 | +[A PR with support for Asyncify transformation](https://github.com/swiftwasm/JavaScriptKit/pull/107) |
| 37 | +was created by [@yonihemi](https://github.com/yonihemi). It allows calling asynchronous JavaScript |
| 38 | +APIs with Swift code that looks as plain synchronous code, but through proper suspension that |
| 39 | +doesn't block browser rendering. The PR has some implications on how we build things, especially as |
| 40 | +it requires a specific optimizer transformation. It is still in the draft stage, and you're welcome |
| 41 | +to contribute to the ongoing discussion. |
| 42 | + |
| 43 | +### OpenCombine |
| 44 | + |
| 45 | +We still use [a fork of OpenCombine](https://github.com/TokamakUI/OpenCombine) in Tokamak due to |
| 46 | +our custom implementation of the `ObservableObject` protocol. In addition to that, our fork |
| 47 | +also contained some changes to the package manifest to make it build with SwiftWasm, but they |
| 48 | +made it incompatible with non-Wasm platforms. This issue was [resolved in the upstream OpenCombine |
| 49 | +repository](https://github.com/OpenCombine/OpenCombine/pull/191), which reduced the amount of |
| 50 | +customizations we apply, and brings us closer to using the upstream repository as is. |
| 51 | + |
| 52 | +### OpenCombineJS |
| 53 | + |
| 54 | +With progress on OpenCombine, it was time to publish the first version of |
| 55 | +[OpenCombineJS](https://github.com/swiftwasm/OpenCombineJS). Its code didn't change recently, but |
| 56 | +parts of it were used in Tokamak already, which gave us confidence that it was reliable enough to be |
| 57 | +released in a separate library for wider use. It currently doesn't contain much code, but this basic |
| 58 | +functionality should be enough for basic integration of JavaScriptKit types and OpenCombine. |
| 59 | + |
| 60 | +### Tokamak |
| 61 | + |
| 62 | +Following [the 0.5.0 release](https://github.com/TokamakUI/Tokamak/releases/tag/0.5.0), which added |
| 63 | +support for the latest `carton`, we published [a small 0.5.1 |
| 64 | +patch](https://github.com/TokamakUI/Tokamak/releases/tag/0.5.1) with support for editing Tokamak |
| 65 | +projects in Xcode with working autocomplete. Not long after that [an important |
| 66 | +bugfix](https://github.com/TokamakUI/Tokamak/pull/301) landed in |
| 67 | +[0.5.2](https://github.com/TokamakUI/Tokamak/releases/tag/0.5.2), which fixed an issue with display |
| 68 | +order of updated views in the DOM renderer. A few weeks later another [bugfix |
| 69 | +release](https://github.com/TokamakUI/Tokamak/releases/tag/0.5.3) was published as 0.5.3. In this |
| 70 | +update Tokamak now internally relies on the aforementioned OpenCombineJS library instead of |
| 71 | +providing its own `JSScheduler` type conforming to Combine's `Scheduler`. More importantly, it fixes |
| 72 | +[a bug with `Toggle` not being updated](https://github.com/TokamakUI/Tokamak/issues/287) after |
| 73 | +resetting it from a binding. |
| 74 | + |
| 75 | +## Developer tools |
| 76 | + |
| 77 | +### WasmTransformer |
| 78 | + |
| 79 | +[@kateinoigakukun](https://github.com/kateinoigakukun) |
| 80 | +[implemented](https://github.com/swiftwasm/WasmTransformer/commit/d79d945731e03a10cb2806cbafc0be0113a2b9bf) |
| 81 | +a `stripCustomSections` transformation in [the `WasmTransformer` |
| 82 | +library](https://github.com/swiftwasm/WasmTransformer). [According to the |
| 83 | +spec](https://webassembly.github.io/spec/core/appendix/custom.html), data in custom sections should |
| 84 | +not contribute to observed behavior of a given binary. In the case of binaries produced by |
| 85 | +SwiftWasm, custom sections contain debugging information that can now be stripped with |
| 86 | +`WasmTransformer`. |
| 87 | + |
| 88 | +### `carton` |
| 89 | + |
| 90 | +Previously, custom sections were stripped to reduce final binary size as a build step in `carton |
| 91 | +bundle` with the `wasm-strip` utility from [WABT](https://github.com/webassembly/wabt). Thanks to |
| 92 | +the new transformation in `WasmTransformer`, WABT is no longer needed as a dependency of `carton`, |
| 93 | +which makes installation for our end users simpler and faster. |
| 94 | + |
| 95 | +Initial support for presenting crash stack traces directly in `carton` has been completed, starting with [Firefox support](https://github.com/swiftwasm/carton/pull/162). Support for more browsers will be added in separate PRs. |
| 96 | + |
| 97 | +There was also work on [file downloader cleanup](https://github.com/swiftwasm/carton/pull/171), [support for browser testing](https://github.com/swiftwasm/carton/pull/173), and [simpler URLs for main bundle |
| 98 | +resources](https://github.com/swiftwasm/carton/pull/176). As soon as these are merged, a new version |
| 99 | +of `carton` will be tagged that will use the latest 5.3.1 release of SwiftWasm. |
| 100 | + |
| 101 | +## Contributions |
| 102 | + |
| 103 | +A lot of the progress wouldn't be possible without payments from our GitHub Sponsors. Their |
| 104 | +contribution is deeply appreciated and allows us to spend more time on SwiftWasm projects. You can |
| 105 | +see the list of sponsors and make your contribution on the sponsorship pages of [Carson |
| 106 | +Katri](https://github.com/sponsors/carson-katri), [Yuta |
| 107 | +Saito](https://github.com/sponsors/kateinoigakukun) and [Max |
| 108 | +Desiatov](https://github.com/sponsors/MaxDesiatov). |
| 109 | + |
| 110 | +Thanks for reading! 👋 |
0 commit comments