I think that it would be helpful to have better interoperability between Swift and JavaScript. There are a lot of useful packages on NPM that don't have equivalents for Swift. It would be helpful if there were easier ways to use NPM packages in a Swift project. Currently, the JavaScriptCore framework is missing many standard things used in many packages, like the fetch API. It would be helpful to be able to run sandboxed JavaScript code inside of a Swift app but allow access to specific domains, folders, etc., using a permissions system similar to Deno. It would be nice to have official support for JavaScriptCore on Linux.
1 Like
JavaScriptCore is maintained as a part of WebKit, not Swift. While this feature request is off-topic here, please feel free to file it on the WebKit bug tracker.
Bun uses JavaScriptCore and supports Linux, so it looks like there is already a way to run JavaScriptCore on Linux. However, you can't currently just import JavaScriptCore in a Swift program and use it on Linux. I don't currently use Swift on server and am not very familiar with it but I would be interested in exploring it more in the future. One of the biggest problems it currently looks like I would have with it is that there are many JavaScript libraries that don't have Swift equivalents. Being able to easily run JavaScript code in a Swift program would solve this problem.
Something like this would be great for swift, here you can find an example: GitHub - noppoMan/node-native-extension-in-swift: An experimental repo for Node.js native addons that written in Swift.
I am looking to call JavaScript code from Swift, not Swift from JavaScript, although that could still be useful for other things.
Just curious, what sorts of packages are missing that you would need JS for? I’ve built a fairly complex product using Swift on the server, and I haven’t once felt like I was held back by the inability to use a JS dependency.
One of the best outcomes of building a web app in Swift is how safe and reliable the code is. Introducing JavaScript dependencies would either sacrifice that, or increase the cost of it substantially.
There are probably niche cases where this would be helpful, but I think for the vast majority of projects, mixing in JavaScript on the server would just make them more complicated and less stable.
Effort here is probably better spent on thoughtful ports of JS packages that are missing in Swift.
3 Likes
First of all, the “…but our restrictions work for me and my needs, what weird junk are you doing?” attitude of too many devs is why I’m in pain just reading the docs for this language and platform. But, I digress…
Swift is missing just about everything with hype or excitement around it lately, which is important whether that hype turns out to be “real” in the end or not.
Real time syncing databases with ergonomic config like Convex or Spacetime. Convex apparently has a Swift package now that I check again, but they didn’t for long enough that I stopped caring to try it out.
The entire AI/ML space. Outside the limited, and mutually exclusive, scopes of MLX and CoreML, at least. And even then, Swift is the secondary option, in our own frameworks. You’re porting models over to MLX to even try them out, or you’re optimizing manually for CoreML to run well on NE, after converting with a python package from Apple. And then you’re using a hot mess of a mostly-python project for anything involving audio, with a tiny folder for Swift stuff carved out, housing a subset of functionality, and licensing restrictions… Sure, fluid inference or whatever exists, too. But only as a vibe-coded disaster that nobody is gonna contribute to in that state.
Having jumped into Swift, in large part, because advances in NLP and speech synthesis got me hyped about making coding, and my own devices, reliably accessible for once, I was repeatedly crushed by the lack of JS/TS or Python interop. Given the dearth of Swift support for anything that was exciting to me (and most everyone else) across the past year or so, it just feels like a comfy, but completely dead, language catching up on every front.
Sure, I’m now at the point where I could port libraries over, or help the folks who ported some of hf-transformers over and promptly declared “1.0! What comes next: Honestly, we don’t know.” while asking for suggestions over unspecified social media to the maintainers, to be found… somewhere? But like… why would anyone look at that, see open and discussed “great first issues” that look fixed in a stalled merge of two projects with little detail available, and go “yeah, lemme jump into that directionless disaster”.
The industry is shifting rapidly, the job market has been trash for ages, and Swift has Java interop in progress, but nothing of interest to those it needs most right now and into the future. The legion of ambitious, unemployed, increasingly hopeless would-be juniors that have little else to do but free labor to port libraries from JS and Python. Or fix docs and DocC to generate anything at all that won’t crash screen readers. But, they need a reason to do that here instead of for another ecosystem doing everything right that turns people away from Swift.
Most other languages and platforms get this, and they put serious effort behind it. My read is that Swift is way too comfy with its perceived monopoly position over an uncontested niche, and will lose the most once the talent pipeline dries up. It’s easy to see a future where everybody’s on React Native or KMP, reluctantly mixing in a bit of Swift here and there.
Swift has a massive advantage, roping in people with an iPhone by default when they want to build something that web can’t do in their pocket. But between the lack of anything with hype, and just how cold and unapproachable the entire Swift ecosystem feels compared to any other language I’ve spent time around? It’s destroying every bit of that advantage when it could be investing in staying competitive, becoming welcoming (not just in the fake way), and keeping the interest of those comprising the future of the industry. Slow sunset or juggernaut status, that’s the fork here.
Interrogating the use cases of people who ask for interop for an incredibly popular language everywhere else but here, and suggesting they port libs over themselves, in this context, when even the legends of this niche broadcast they have no clue what they’re doing? It’s giving sunset years…
There are multiple benefits to being able to use JavaScript in Swift even if there are Swift equivalents to JavaScript libraries.
- Gradual adoption. This could allow incrementally adopting Swift by starting out wrapping the entire JavaScript program with Swift and then slowly reimplementing parts in Swift. Even though there are many Swift alternatives to popular JavaScript libraries, it may take a lot of work to switch to using them.
- Consistency with other platforms. Some apps may have JavaScript code that works in a very specific way and it could be helpful to be able to re-use it easily across all versions of an app instead of having to carefully re-implement it in Swift while making sure it works identically to the JavaScript version that may be used on other platforms.
- Security. By running third party libraries in a sandboxed JavaScript environment it could allow using third party libraries in a safer way without having to thoroughly audit them.
I've been using JavaScript and Swift both at work and on side project for a while, but I don't think there's a direct way to "bridge" Swift and JavaScript.
JavaScript is very environment-bound and fragmented. What kind of environment do you want to run JavaScript in, and what environment does the JS package author intended for their package to run in? This changes a lot of things. If you are trying to run Swift along with JavaScript in browser, then JavaScriptKit actually does it pretty well. But for server side it's very complicated. Most JS libraries won't work in a plain JS environment like JSC (because it lacks all that Web API and Node.js API stuff), but to get Web API and Node.js API (not mentioning the other popular API sets offered by newer runtimes like Deno and Bun) working in JSC is definitely not a job Swift language itself should take. What you are asking, is to basically writing and maintaining a fully-fledged JS runtime just for that JS interop, and in JS communities nobody seem to agree on what's the boundary of what should and should not be included in a JS runtime.
So, is there any concrete examples you can provide, that you may see fit to be bridged to Swift? Is there any precedents you want to mention that bridges with JS in the way you proposed? I personally am interested in actual use cases. I know people uses JSC to run things like highlighter.js for syntax highlighting stuff on iOS apps, but including a JS runtime on server basically requires you to have the expertise in operating both Swift and (Node.)js at scale, and from a DevOps perspective I would much more prefer re-implementing whatever JS lib I need in Swift, which is not that burdened since LLMs can do it fairly well and usually ends up have better performance and resource usage than having a JS VM there.
By the way, have you tried to look into the JS package? I find it more likely that a JS lib I need is actually a wrapper of other native libraries, likely originally written in C / C++ / Golang / Rust. In that case, it's actually easier to use Swift's C/C++ interop to bridge the original lib in.
1 Like
One example that I can think of would be sharing code across different apps on many different platforms. JavaScript seems like it would be one of the best options for a cross platform scripting language. I have been looking into RSS readers and there are a lot of things that could be shared between them. For example, there could be a set of scripts for scraping websites that don't have RSS feeds and generating feeds for them. Some RSS readers have built in web scraping features but it isn't well standardized between different RSS readers. It would be helpful to have a shared standard for scripts for scraping websites and making RSS feeds where the scripts could be written in JavaScript and shared across many different RSS reader apps that are written in many programming languages for many different platforms. It wouldn't make sense to reimplement scrapers for every website in every language.
RSS Guard has a feature for doing article filtering in JavaScript.
Like what you see, the hardest part of that is these RSS readers don't have a common interface for these scraping rules & program. They might be using JavaScript, sure, but there's no standard interface.
Anyway, I don't think this is related to Swift language itself. It's an application-specific functionality that requires standardization in the problem scope, rather than a language problem to solve. If you want a plugin / extension mechanism in your Swift app, it's possible to use JavaScriptCore on Apple platforms or bind QuickJS on other platforms. The effort won't be trivial but it isn't too complicated. Things like fetch will require more effort as they are not part of ECMAScript standard, but part of ever-evolving Web API, so not implemented by most JS engines and require some manual binding. There's not really much Swift language can do: All of that implementation will be very different depending on what engine you pick (JSC, QuickJS, V8, Hermes, etc.), what subset of JS API you want (ECMAScript 2015 or later, Web APIs, Node.js API, Deno API, Bun API, etc.), and ultimately depends on what capability you need. It doesn't make sense for Swift language itself to do any of these.
1 Like