Published on
September 2020 Update
Welcome to the SwiftWasm blog! The amount of work happening in the SwiftWasm ecosystem is growing, so we decided to start publishing blog updates to give you an overview of what happened recently. This update for September is big enough to be split into different sections for each area of our work, so let's get started. 🙂
Libraries
JavaScriptKit 0.7 has been released. It adds multiple new types bridged from JavaScript, namely JSError
, JSDate
, JSTimer
(which corresponds to setTimeout
/setInterval
calls and manages closure lifetime for you), JSString
and JSPromise
. We now also have documentation published automatically for the main
branch.
New features of JavaScriptKit allowed us to start working on closer integration with OpenCombine. The current progress is available in the new OpenCombineJS repository, and we plan to tag a release for it soon. At the moment it has a JSScheduler
class wrapping JSTimer
that implements the Scheduler
protocol, enabling you to use debounce
and other time-based operators. Additionally, OpenCombineJS now provides a helper publisher
property on JSPromise
, which allows you to integrate any promise-based API with an OpenCombine pipeline.
We also saw a lot of great progress with DOMKit in September thanks to the outstanding work by Jed Fox and @Unkaputtbar, which was unblocked by the recent additions to JavaScriptKit. With DOMKit we're going to get type-safe access to the most common browser DOM APIs. It will be expanded in the future to support even more features that currently are only available via JavaScriptKit through force unwrapping and dynamic casting.
That is, compare the current API you get with JavaScriptKit:
import JavaScriptKit
let document = JSObject.global.document.object!
let divElement = document.createElement!("div").object!
divElement.innerText = "Hello, world"
let body = document.body.object!
_ = body.appendChild!(divElement)
to an equivalent snippet that could look like this with DOMKit:
import DOMKit
let document = global.document
let divElement = document.createElement("div")
divElement.innerText = "Hello, world"
document.body.appendChild(divElement)
Lastly on the libraries front, Tokamak 0.4 is now available, enabling compatibility with the new version of JavaScriptKit, and utilizing the aforementioned JSScheduler
implementation.
Developer tools
Following the new 0.7 release of JavaScriptKit, carton
0.6 has been tagged, shipping with the appropriate JavaScriptKit runtime compatible with the new release. It also includes support for the new carton bundle
command that produces a directory with optimized build output ready for deployment on a CDN or any other server. Notably, both carton bundle
and carton dev
support SwiftPM package resources, allowing you to include additional static content in your SwiftWasm apps. These could be styles, scripts, images, fonts, or whatever other data you'd like to ship with your app.
This version of carton
also ships with the latest version of wasmer.js, which fixes compatibility with recently released Safari 14.
Toolchain/SDK work
The upstream Swift toolchain has switched to LLVM 11 in the main
branch, which caused a substantial amount of conflicts in our forked repositories. Resolving the conflicts and making sure everything builds properly consumed a lot of our time in September. You could've noticed that the previously steady stream of nighly development snapshots stalled for most of September, but it resumed starting with wasm-DEVELOPMENT-SNAPSHOT-2020-09-20-a
.
As for the 5.3 branch, with the upstream Swift 5.3.0 release now generally available, we're now preparing a stable SwiftWasm 5.3.0 release. It is based off upstream 5.3.0 with our patches applied to the toolchain and the SDK. We've created a checklist that allows us to track the progress of this effort.
One of the issues we wanted to resolve before tagging SwiftWasm 5.3.0 is the inconsistency between WASI and Glibc APIs. While parts of those look and works the same, the rest are significantly different. Because of this, in subsequent snapshots our users need to use import WASILibc
instead of import Glibc
if they need to access to libc on the WASI platform. This has already landed in the swiftwasm-release/5.3
branch with swiftwasm/swift#1773 and is available in wasm-5.3-SNAPSHOT-2020-09-23-a
or later. It was also implemented in the main swiftwasm
branch in swiftwasm/swift#1832, all thanks to the amazing work by Yuta Saito.
Upstream PRs
The divergence between the SwiftWasm toolchain/SDKs and their upstream version is still significant and causes regular conflicts that we have to resolve manually. We're working on making our changes available upstream, but this takes a lot of time, as upstream toolchain and SDK PRs need high level of polish to be accepted. Here's a list of PRs that had some progress in September:
Foundation
- Add locking primitives for
TARGET_OS_WASI
inCFLocking.h
apple/swift-corelibs-foundation#2867. Status: merged. - Add support for WASI in
CFInternal.h
apple/swift-corelibs-foundation#2872. Status: merged. - Add WASI support in
CoreFoundation_Prefix.h
apple/swift-corelibs-foundation#2873. Status: merged. - Add support for WASI in
CFDate.c
apple/swift-corelibs-foundation#2880. Status: in review.
SwiftPM
- Propagate PATH to UserToolchain to fix sysroot search apple/swift-package-manager#2936. Status: merged.
Contributions
We hope you can contribute to the SwiftWasm ecosystem, either to any of the projects listed above, or with your own libraries and apps that you built. We'd be very happy to feature your open-source work in our next update! Our swiftwasm.org
website and this blog are open-source, so please feel free to open an issue or a pull request with a link to your work related to SwiftWasm.
A lot of the progress wouldn't be possible without payments from our GitHub Sponsors. Their contribution is deeply appreciated and allows us to spend more time on SwiftWasm projects. You can see the list of sponsors and make your contribution on the sponsorship pages of Yuta Saito and Max Desiatov.
Thanks for reading! 👋