Call this crazy or premature, but since everyone is asking themselves “can Swift truly run everywhere”, I’ve decided to explore the opportunities browser-side, not just server-side.
Servers, Android and beyond!
Going open-source was the best thing that could’ve happened to Swift.
Many iOS developers held off embracing Swift initially due to changes in syntax, debugger issues and a mostly Obj-C codebase in all apps built pre-Swift (just search for any respected iOS developer on Twitter and add “Swift” to find out). Rightly so, it’s hard to justify the cost of switching with the primary reason being novelty.
However, open-source Swift means countless opportunities. During the WWDC2015 Keynote, I’m sure many developers felt same as me that we’d soon start seeing Swift in small web services and native platforms beyond iOS and OS X. Anyone who’s spent a lot of time having to re-write large chunks of code just to port some functionality from one platform to another has seen a light at the end of a tunnel that day.
Many are still holding off, but the tangible proof of Swift finally running on Linux has gotten the whole community particularly excited. Since then we’ve seen a number of promising web frameworks and a merged PR of Swift’s Port to Android NDK, but why stop here? Could code re-use be beneficial in the browser and how do we do this?
State of Web development
The web vs native community couldn’t be further apart. With only a few exceptions there are almost no common technologies for Front-end Web Development and Native app development (not counting WebViews). Except for “hybrid” development efforts, “web vs native” is almost an all-out war.
We use completely different tools, IDEs, languages and the way we implement the UI couldn’t be more different either. Overall this has split development into 3 segments:
- Native development — Obj-C/Swift on iOS utilising iOS Frameworks. Java on Android utilising its SDK.
We used to have two choices:
- Fat Server/Thin Client — keep things server-side and render all requests as either full or partial pages.
- Thin Server/Fat Client — keep the server light, render things client-side thus making the pages more dynamic.
Now there’s a third choice:
Coding for the Browser
The more settled Swift is, the more feasible it becomes to maintain a transpiler, but there’s certainly much left to be done to achieve full compatibility. With a growing level of complexity, it might be better to look towards an LLVM-based solution.
Unable to compile a simple Swift file (maybe not possible?) · Issue #2427 · kripken/emscripten
Hi team, playing around with Emscripten in earnest for the first time, not my usual area of work so apologies if this…
Accessing the DOM
No surprise many emerging back-end frameworks are similar to Express.js, they are using productive and proven patterns. Swift doesn’t have to re-invent web development, it can borrow a lot of good ideas and learn some lessons from Node.js, React and ES6 to avoid any mistakes made in the past. I’d argue the same for potential Front-end solutions.
Make no mistake: templating and DOM are issues that are already coming up for Swift-powered web services.
As I’ve mentioned before, Obj-C is still abundant in iOS/OS X projects. For transpiling or Emscripten to work, all Obj-C would have to go. Right now we’re still enjoying being able to mix our codebases. This includes a large number of commonly used dependencies, however an increasing amount of libraries driven by the usage of Swift Package Manager are going pure-Swift.
We’re still just getting into the Swift framework wars. Express.js emerged in 2009 and became a part of the Node.js Foundation this year (2016). It became the most popular web framework for Node.js earlier than that of course, but there were a number of other promising frameworks around. The term for “MEAN stack” — another popular pattern — was first coined in 2013.
I imagine a Swift Isomorphic framework would have to be built on top of a reliable HTTP-server framework and an ORM library compatible with both Linux and native mobile platforms.
Any dependencies you’re planning to use on the Front-end would have to transpile or compile as well. This includes Foundation. While the Swift port is designed for portability, it’s still in the works. There is some risk in how large the output would end up being with all dependencies statically linked and distributed through your website. To be fair, this is already happening in the JS world with webpack and browserify, so I suspect this is a matter of how efficient that process will be.