Vapor vs. Kitura: Choosing a Server-Side Swift Framework

Implementation and Deployment

One of the really nice things about Kitura’s broader industry focus is that it embraced Docker implementations very early on. This decision has once again provided stability and continuity across Kitura versions. And it means that it’s long been possible to implement Kitura solutions wherever Docker extends.

The Vapor community was initially less enthusiastic about Docker as a deployment target, but with Vapor 3, Docker implementations have become much more common. At this point, both platforms are largely on par in this respect, and it seems clear that streamlining Docker deployment will be central to the future evolution of both platforms.

Extensibility

We’ve focused largely on internals so far. Another big consideration when choosing a web framework is its breadth and extensibility. How readily can you add new integrations and capabilities to it as your project grows?

Kitura benefits from a strong library of packages. Currently, there are over 50 IBM-supported packages. For its part, Vapor provides a wide array of community resources, currently numbering over 100.

In perspective, while both frameworks have done a lot on this front in a short period of time, neither has come close (yet) to achieving the breadth and richness of available packages that competing frameworks have developed over time. By any metric, this is currently a growth pain being experienced by the entire server-side Swift community.

In practical terms, if you’re looking to do something outside the current crop of official Kitura packages or Vapor Community frameworks, you’ll likely have to do some bushwhacking on your own. Depending on the specific problem, solving a case like this at present may mean adapting an existing open-source framework or having to implement a new capability from scratch.

Vapor and Kitura are members of the SSWG helping to steer direction on an initiative to enable future packages to be interchangeable. This means that that new packages built on top of NIO and following common conventions should soon work with both Vapor and Kitura. This, in turn, has the potential to transform the extensibility landscape across the entire server-side Swift landscape very much for the better in the near future.

Which Should You Choose?

By now, it’s likely clear that choosing which framework is right for you comes down to deciding which fits your own coding style and the needs of any specific project.

Here’s a recap of the key comparisons of these two great frameworks:

Summing Up

Where to Go From Here?

There’s no obvious winner. And at the end of the day, that’s a great thing. We should appreciate that the Swift community is deep and robust enough to support multiple thriving server-side platforms, each with their distinct approach and advantages. It’s also worth appreciating that both platforms give back to the community by actively contributing to the ongoing evolution of Swift itself.

Technologically, there’s simply no wrong choice. If you’re looking to dive into server-side Swift, you should take the plunge! The water’s just fine, and both the Vapor and Kitura ends of the pool are great places to swim. :]

Ultimately the choice comes down to your own priorities, needs, and style. I’d strongly encourage you to play with both platforms and decide for yourself. Take a closer look at the resources available on the Vapor and Kitura sites. I also encourage you to consider our Kitura and Vapor books as well as our complete Vapor and Kitura web courses. You can’t go wrong with either. :]

If you have any questions or comments, join the forum discussion below!)

• What’s most important to you? Stable, backwards-compatible API’s or early adoption of new Swift technologies as soon as possible after they emerge? If you need to ensure that code you write today will run unaltered as long as possible, Kitura may appeal to you more. If you prioritize maximizing fresh Swift goodness and can accept the cost of potentially significant breaking changes between releases, Vapor’s your likely choice.
• Do you prefer tools and APIs drawn from the broader web industry, or would you prefer them to maximize Swift sensibilities? If you’re coming from a Rails / JavaScript / PHP perspective and generally like the tools you’ve used, Kitura will likely appeal most. If you’re coming from iOS and native Apple development and don’t have a heavy investment in JavaScript API’s, Vapor’s approach will likely call to you. This same dynamic continues as we consider the tech stacks of each framework. If you know and like common web tools, you’ll likely be happy having non-Swift, industry-standard tools and grammars in your tech stack. Swift purists and iOS developers without deep web tool investments will likely prefer a pure Swift stack top to bottom.
• What about the API style? If you’re a fan of functional programming and are comfortable with its abstractions, Vapor is likely going to appeal greatly. On the other hand, Kitura’s more traditional approach could be a better match if you prefer your code less abstract and, arguably, simpler to get your head around.
• How and where do you want to deploy your web apps? The difference between the two is less pronounced here than it has been in the past, but differences in emphasis and support remain. If you happen to have an investment in IBM’s cloud offerings, Kitura’s a clear winner. Beyond that, both platforms provide increasingly strong support for Docker and by extension virtually all major cloud platforms.
• How is the performance? In a word, fantastic. Both frameworks provide exceptionally strong performance and efficiency at scale. Generally, if efficiency or performance are major considerations, this is a potentially strong reason to choose either of these server-side Swift frameworks over other industry competitors. At this point, there just aren’t strong reasons to choose between Kitura and Vapor on this basis.
• How much functionality do you want to build from scratch? We’ve seen that both Vapor and Kitura have relatively strong sets of third party and extended frameworks available in their respective ecosystems. But neither comes close to what’s available to more mature JavaScript, Ruby, PHP and other frameworks. If you’re looking to add a lot of functionality outside the box of what either platform supports, this is a likely indicator that the project you’re considering isn’t (yet) a great candidate for Server-side Swift.