NoMansCanvas VS hummingbird

It also uses a local SQLite db instead of a separate MySQL server, which makes deployment quite trivial (git clone && make run). The web client is still built with React, I've been thinking of rebuilding it with a single .html file and minimal JavaScript.

[1] https://github.com/vkoskiv/NoMansCanvas

Earlier this year I set out to completely rewrite an old project[1] using minimal, battle-tested dependencies to avoid having to constantly patch code rot associated with more modern languages and toolchains. The rewrite[2] is now complete, more performant and lightweight than the old one, and I'm confident I won't have to touch it much, if at all, and it will compile and work in 20 years.

[1] https://github.com/vkoskiv/NoMansCanvas

[2] https://github.com/vkoskiv/nmc2

Such a shame. Swift has many beautiful language features.

I give swift a try every once in a while.

Problems of my last attempt:

- The Swift REPL (lldb to be precise) depends on libpython-dev (v3.8). WSL (ubuntu 22.04) comes with 2.7 and 3.10, so the lldb dependency depends on an old python version. The fix was to copy the 3.10 binary to the directory where lldb expects it, and rename it to libpython3.8.so. It seems that it's backwards compatible so it worked on my machine.

- I tried to compile and statically link a hummingbird (web framework, more light weight than vapot, https://github.com/hummingbird-project/hummingbird) hello-world example. I had a liking error. Luckilly someone in the swift forums helped me. The problem was that my package.swift file had the "-static-stdlib" flag only as a swiftSettings. It needed to be also a linkerSetting.

In the end I was able to build my example. But at this point I already spent multiple days debugging problems that are unrelated to my applicationn or the Swift language.

It's a shame because I see its potential. Fixing the (linux/windows) tooling problems would probably only take "some" developers. Apple has near infinite money and could sponsor them if they wanted to., but they gain little by it. Besides them, not many are invested in it.

Also look at: Hummingbird https://github.com/hummingbird-project/hummingbird Smoke https://github.com/amzn/smoke-framework Swift NIO https://github.com/apple/swift-nio

Hummingbird is probably the fastest/lightest backend. You can switch to it after mastering Vapor's Fluent ORM.

I'm using Hummingbird hooked up to MongoDB with Vapor Fluent. I declared input/output structs that I share to the client code via a library. All my core business logic sits on the server. I can cache the structs client side on sqlite.

If you don't need all the features of vapor, you can just use Fluent's ORM and Hummingbird. The documentation and code examples are more up to date.

Another Devil's Advocate: Why would I choose it over Hummingbird? https://github.com/hummingbird-project/hummingbird