Server-side Swift is making waves in the web and services worlds, and developers from iOS, web and other coding backgrounds are increasingly joining the server-side Swift community. There’s just one problem (a good one): How do you choose which open-source Swift framework to use?
In a just-released post from our friends at Ray Wenderlich, “Vapor vs. Kitura: Choosing a Server-Side Framework“, Beezwax Mobile Lead and Senior Application Architect Brian Schick provides a detailed review and selection guide featuring the two server-side Swift heavyweights: IBM’s Kitura, and the independent Vapor platform.
Here’s a summary of this comparison, and key factors in choosing a Server-side Swift Framework for your own project.
The Roots of Server-side Swift Frameworks
When viewed in contrast with more established JavaScript, PHP and Ruby frameworks, the Swift roots shared by both Vapor and Kitura are evident — and highly compelling. As we’ve long known at Beezwax, Swift in general — and Server-side Swift in particular — brings a lot to the table.
In a web context, both Kitura and Vapor are disruptive — in a good way! Both integrate Swift’s core type safety, compiled security and performance advantages, and much more. Like Swift itself, each framework is fully open sourced, and each can be deployed not only on Apple-branded operating systems, but also on Ubuntu Linux, Docker and ultimately virtually any desktop or cloud platform.
Contrasting Vapor and Kitura
Having seen what Vapor and Kitura have in common, we learn what sets them apart. And when compared side by side, each displays a distinct personality, philosophy and approach.
IBM’s ongoing sponsorship of Kitura ripples throughout the platform’s choices and architecture. At a high level, this gives Kitura a consistently conservative, predictable, and backward-compatible flavor. On the other hand, the Vapor platform’s deep independence and focus on developers lead to very different tendencies: Vapor adopts new Swift technologies and protocols as quickly as possible, and its APIs typically change much more profoundly between versions. We see how these philosophical differences play out in specific cases — for example, in their differing timelines in adopting Apple’s highly regarded, low-level NIO framework, and in their contrasting valuation of backwards-compatibility versus rapid incorporation of new linguistic capabilities.
Developers coming from other platforms will look for common industry conventions. Both Kitura and Vapor incorporate MVC and other industry-wide design patterns. But Kitura’s broader industry emphasis has led it to incorporate the syntax of common JavaScript and Ruby tools such as Mustache, Express and more. Conversely, Vapor’s Swift developer community focus is expressed in pure, full-stack Swift implementations and APIs designed to express Swift-y best practices and approaches. We see that both approaches are technically sound, but that Kitura and Vapor each will appeal to different types of developers.
For fuller details of these differences, see Brian’s full post at raywenderlich.com.
What’s the verdict?
Brian concludes that both Vapor and Kitura have rapidly matured into exceptionally capable, performant and battle-tested frameworks: “There’s no obvious winner… the Swift community is deep and robust enough to support multiple thriving server-side platforms, each with their distinct approach and advantages… Technologically, there’s simply no wrong choice… [it] comes down to your own priorities, needs and style.”
What’s this mean for us?
First, it’s great to know that the Server-side Swift technology we’ve embraced is increasingly being lauded and embraced by the larger tech community.
Second, Brian’s analysis reflects our ongoing approach: Rather than dogmatically establishing a single favorite tool, a better approach is for developers and stakeholders to coordinate and together choose the framework best suiting their unique organizational and project needs. As Brian concludes: “Ultimately, the answer to the question, ‘Which framework is right for me?’ will be based in a secondary question: ‘Which one best matches my own approach and priorities?’… You can’t go wrong with either.”
We couldn’t agree more!