Excellent questions! I’ll copy-paste them in above my answers so it’s easy to follow.
- I saw on X that you released the bridge components library. How many years of “frustration” or “repetitive boredom” did you endure before you made the decision that bridge components were necessary?
I started thinking about a library of sorts the first time I copy-pasted a component from one project to the next. But it wasn’t until a few weeks ago that I realized I finally had enough experience to make solid abstractions for the most common use cases. It requires writing a lot of apps to know what folks will need!
- The Swift/Kotlin thing that sets up the Hotwire app has a way of tripping up anyone who is interested in Hotwire Native. I know in the video you mentioned that you ease developers down that path, but what can be done in the Hotwire Native documentation to make things easier?
I think the new docs are a huge step in the right direction. They outline the major features of the framework and explain just enough rationale behind each.
I’d love to see the docs recognize that the reader is most likely a Ruby on Rails developers. Like I assume in my book, this makes comparisons much easier for developers to understand because they already have a shared vocabulary.
- Along side the previous question, what specific sections of swift and kotlin are ideal for getting a good foundation with Hotwire Native. Think in terms of basic types, primitives, structures(classes/objects) etc. Be as specific as possible if you can.
Knowing the major differences between Ruby and Swift/Kotlin will provide the biggest bang for your buck. Knowing how Swift/Kotlin needs to be compiled (compile time errors vs. runtime errors), explicit null types (vs. Ruby’s "everything can be nil), and how code “flows” through the app are most important (e.g. route → controller → view in Rails).
- Have you ever abandoned a Hotwire Native app projected whether for self or a client and decided to go full native? If so, what were the reasons?
I’ve abandoned a few Hotwire Native projects in the past. But never because the app went fully native. Most of these occurred because of reasons outside of the developer ecosystem, usually related to funds or business decisions.
- Still in line with the previous question: as much as you love it, in your view what’s the best reason to NOT use hotwire native?
If you’re building an offline-first app you should go with a fully native app (or React Native). You’ll be fighting Hotwire Native the entire time trying to get that to work and are better off just going all in and building the app with native APIs directly.
- I recall a few years ago, hotwire native was Strada. Looking at the ReadMe and it says Hotwire Native is consolidation of Strada and Turbo Native. Could you breakdown the distinction(if it actually exists) between Turbo Native and Hotwire Native. Imagine you were explaining to a noob.
Turbo Native + Strada = Hotwire Native
Everything you can do with Hotwire Native you could do with Turbo Native, you would just need more “glue” code to get it working.
- Still in line with the previous question: why the name change i.e what was/is wrong with the name Strada?
Mostly because it was confusing! Developers thought that to build native apps you needed Strada but weren’t even aware of Turbo Native. Consolidating both of them into a single framework with a single name makes a lot more sense - build mobile apps with Hotwire Native, nothing else needed.