turbo-ios VS hotwire-rails

If you're a SwiftUI developer, I've had an issue open at https://github.com/hotwired/turbo-ios/issues/8 to get Turbo SwiftUI off the ground.

I've talked to a few folks about it and have heard responses ranging from "it's a bad idea/can't be done" (mainly because of SwiftUI bugs) to "why would you want to do that?". I think it would be amazing to have a declarative of building out a Hotwire Rails application inside of iOS. Bonus if the Turbo SwiftUI component could run on macOS.

For the mobile side, start with each platform's respective Turbo package: https://github.com/hotwired/turbo-ios and https://github.com/hotwired/turbo-android. Each has a demo app you can run in XCode/Android studio. To get a basic app building, follow each one's "Getting Started" guide. It's actually pretty easy to get a basic native app building, the hard part comes in integrating native components and services, as well as release management.

turbo-ios and turbo-android are the shell/wrapper apps handling native navigation, written for native iOS and Android. They are provided for you, and works out-of-the-box, but you risk having to fiddle with iOS and Android development for maintenance/debugging later on.

Ruby on Rails, Hotwire, Postgres, Redis

Does anyone have experience with https://github.com/hotwired/turbo-ios or https://github.com/hotwired/turbo-android ?

1. Turbo Native

I use Turbo Native on iOS to do exactly this.

You render your mobile web view like normal, wire up a JavaScript handler (formerly known as Turbolinks), and push native screens on iOS. It works really well for CRUD and "boring" SAAS apps with little interaction outside of forms. And when you need higher fidelity dropping down to SwiftUI or UIKit is straightforward.

https://github.com/hotwired/turbo-ios

To make things even simpler, I built Jumpstart iOS, which takes care of all of the Swift boilerplate. Navigation, authentication, and push notifications all work out of the box after adding a few endpoints to your server.

https://jumpstartrails.com/ios

Adding to the already mentioned solutions, another alternative may be to develop your app with Phoenix and [Hotwire](https://hotwired.dev/), using Turbo on the backend and [Turbo-ios](https://github.com/hotwired/turbo-ios) for your app.

turbo-ios and turbo-android are small wrappers around your web views. You write native Swift and Kotlin wrappers but the frameworks display your web content. They also handle navigation and data transmission between the views and native code.

I’d like to see this integrate more tightly with Rails Turbo framework. Ideally it would understand Visitables and plug into SwiftUI. I took a swing at that at https://github.com/hotwired/turbo-ios/issues/8 but have struggled to get it working … that and Strada hasn’t come out yet, which I assume is the equiv of the native plugins within Portals.

Applications generated with Rails 7 will get Turbo and Stimulus (from Hotwire) by default, instead of Turbolinks and UJS. Hotwire is a new approach that delivers fast updates to the DOM by sending HTML over the wire.

For Ajax-y stuff, I am really excited by the new crop of "HTML-as-a-Service" or "HTML-over-the-wire."

https://htmx.org/

https://hotwired.dev/

For all the turbo/stimulus/hotwire mix, you want to add a new feature just for the sake of adding it? or do you have a use case that fits the feature? if you have then you probably already have an implementation with a different technology (stimulus reflex? some custom websockets or ajax implementation? something with anycable?) and you have to check how to migrate from that technology to hotwire. If you just want to use the feature with no real need for it to practice then just pick any tutorial from the internet (like the intro in the official website https://hotwired.dev).

I was recently interested in similar topic. Here are 3 similar solutions I found:

* https://htmx.org/

* https://unpoly.com/

* https://hotwired.dev/

My personal preference is Unpoly (the idea of "layers" is awesome). But the best explanation of concept as a whole (HATEOAS, keeping app state on server using partial page updates, etc) is at HTMX homepage, and in these essays:

* https://htmx.org/essays/hateoas/

* https://htmx.org/essays/locality-of-behaviour/

At the end of 2020 the Basecamp team released a collection of Javascript libraries called Hotwire. Modern web stacks have popularized javascript-rendered front ends and JSON transmissions. Hotwire's primary motivation is to reduce the Javascript footprint and allow application front ends to be created in primarily HTML. It pairs very nicely with the Ruby on Rails ideology and is often demonstrated in that context. I aim to write a series on how Hotwire can be used in any application to simplify development and reduce the need for heavy Javascript downloads. Hotwire currently consists of two javascript libraries: Turbo and Stimulus. The first part of this series introduces Turbo.

I've been doing that a while until I just got sock of the JS spagetti and often duplicated code and went full on Angular CSR and never looked back. That being said, I've been seeing a lot recently about Laravel's Livewire and Symfony and Ruby on Rail's integration with Hotwire (stimulus+turbo).