after experimenting for a couple weeks in my spare time with Swift WebAssembly (How far can i get with Swift WebAssembly in 30 minutes?, Running a Swift WebAssembly application at near zero cost ) and evaluating the basic capabilities of the technology, i am pretty thoroughly convinced this is a promising opportunity, and i am now in the process of evaluating how feasible it would be to start adopting Swift WebAssembly in bigger projects.
i’ve gotten a good understanding of the logistical workflow for building and deploying Swift WebAssembly, and i’ve been able to fill in the missing gaps in existing tooling (such as carton), so i think the logistical story with Swift WebAssembly is pretty solid.
and i think Swift itself (the language) is an excellent fit for WebAssembly and possesses some major inherent advantages over other languages targeting WebAssembly.
however, i really feel that JavaScriptKit is just not usable in its current state, and i essentially agree with @svanimpe ’s assessment here:
i think these are the problems the WebAPIKit project was initially launched in order to solve, but the project seems to have stalled years ago, and it’s not clear to me if it’s really ready to become a load-bearing layer of a software stack. i would appreciate clarification on these points:
- who is currently working on the WebAPIKit project today? (it has had just one commit in the past 1 ½ years)
- who (or what entity) currently steers WebAPIKit today? who currently allocates resources between WebAPIKit and other related technologies?
- are there any organizations currently backing the development/maintenance of WebAPIKit, or Swift WebAssembly in general?
- how risky is it (from a project management perspective) to begin integrating with WebAPIKit? are we better off toughing it out with JavaScriptKit, which has aformentioned drawbacks but appears to be noticeably better-maintained?
- are there any alternatives to WebAPIKit i haven’t considered?
thanks in advance 