Swift as a replacement for JavaScript

Ever since Swift was available for public I foresaw a future where swift would take over the world by replacing JavaScript. After all, it is popular because it is used for websites!

In html you could write

To specify that the script between the tags in JavaScript. It was done this way so that other languages could be used. Imagine if we could replace it with “text/swift” and enter any swift code!

I am not aware of anything like this has been done.

I found this link. Which actually takes a different approach where swift is compiled into JavaScript.

I am more interested in having swift replace JavaScript as a web language.

People talk about getting swift to work on windows which I assume will allow people to develop apps in swift.

However I feel as though swift would gain more popularity faster if it replaces JavaScript for web apps.

Thoughts?

3 Likes

It's conceivable that Swift code could be compiled to WebAssembly some day. It's highly unlikely that JavaScript will be "replaced" by any other language any time soon, but WebAssembly runs alongside JavaScript, and is a natural target architecture for compiled languages like Swift. You would still need a compilation step*—so not quite as simple as <script type="text/swift">—but if you're interested in being able to write web apps in Swift, it's your best bet.

*unless you wanted to port the entire Swift compiler and all of its dependencies to WebAssembly and ship that with your app as well :nauseated_face:

6 Likes

My guess is the client side Swift-on-web story will revolve around WASM and/or compiling into JavaScript. I don't think Swift would work (well) as a JS-style scripting language without some sort of compilation step or a very different runtime.

I personally have high hopes for WASM to alter the current landscape, and Swift is certainly a great contender for usage in that world. Unfortunately that will likely be a decade(s) long process.

In the meantime there are already Swift --> JS projects (.e.g shift-js). Something I would love is if server-side-Swift took off and someone created a rails-esque web-app platform with Swift --> JS compilation as the client-side component. If anyone has a few years to devote to a project like that, I'll be one of the first in line :slight_smile:

Aside: somebody did compile clang itself to WASM (Clang In Browser), which allows you to run a C/C++ sandbox without any server support besides hosting the files. Check out the loading time. Downloading and executing the compiler would take vastly longer than running your actual application. It's cool for these kind of programming sandbox websites, though. I hope we can do something like that for Swift in the future.

3 Likes

I think the future would be web assembly. So, it would be better if the next Swift (v7, v10?) would be able to produce web assembly code, instead of JavaScript. :blush:

1 Like

isn’t that more of an llvm problem than a swift problem

FWIW I would expect LLVM to officially support WASM within the next year or two. So Swift, Objective-C, Kotlin-native, etc. will all be compatible! :confetti_ball::man_dancing:

However WASM isn't really a direct replacement for JS, and unfortunately I can't imagine JS not being the major client side language for the next decade. So Swift->JS conversion will have a lot more utility for the near future.

1 Like

Couldn’t the browser just link to the swiftc/llvm libraries and let them handle it? I mean, JavaScript engines generally live inside the browser because not much else uses them, right?

Sure, it could, but good luck getting that standardized, implemented and maintained in all major browsers. Besides, offloading Swift's long compilation times onto users would be a bad idea. I also get nauseous just thinking about source compatibility in this system.

:laughing: yeah, I know. Everything starts out like that, though. Flash kinda took over the world for a while without even being an open standard.

I think that's mostly the type inference system... Don't compile times go down a fair bit if you don't use it? Still, server-side would certainly be better.