aws-gocljs VS turbo-ios

i make two kinds of websites:

- static. markdown rendered to html using github’s api[1].

- dynamic. a go binary and an html file with inlined js zipped together and shipped somewhere[2].

it’s nice to never consider the machinery of either of these anymore. instead i think about building interesting things.

1.

https://github.com/nathants/render

https://nathants.com/

2.

https://github.com/nathants/aws-gocljs

https://gocljs.nathants.com/

have you tried cljs and reagent? it’s a different vibe.

my bootstrap: https://github.com/nathants/aws-gocljs

the project: https://reagent-project.github.io/

https://gocljs.nathants.com is 300kb gzipped on deploy in a single html file. setup is here: https://github.com/nathants/aws-gocljs.

aws, go, and clojurescript.

go is notoriously boring.

the reagent api for clojurescript hasn’t changed in a decade, though recent things like shadow-cljs do improve qol.

aws releases services with 2 in their name instead of changing existing ones. the old boring service will plod along forever.

aws apigateway v2 is much better, but i have many deployed projects i will never migrate because they are fine on v1.

i do it like this: https://github.com/nathants/aws-gocljs

lambdas updatecode api takes less than a second. using container instead of a zip for lambda has advantages, but speed is not one of them.

i auto rebuild my go zip and patch aws on every code change. it’s done before i alt tab and curl.

script: https://github.com/nathants/aws-gocljs/blob/master/bin/dev.s...

lambda + s3. add ec2 spot if you need it.

just make sure you understand how billing works. mostly it’s just egress bandwidth is expensive.

do something like this:

https://github.com/nathants/aws-gocljs

or with less opinions:

https://github.com/nathants/libaws/tree/master/examples/simp...

welcome to cloud, glhf!

using remote resources as a part of your local dev flow can be very useful if your local environment is constrained on:

- upload and/or download bandwidth

- cpu/ram/gpu/ssd

this can be as simple as an ephemeral ec2 spot machine that reacts every time files on it’s filesystem change. it then does stuff, like building and shipping.

your local setup then needs to rsync files from local to remote every time you save a file.

i’m on an upload constrained setup right now, and this[1] significantly speeds up my iterations uploading lambda zips.

fancier setups probably are similarly advantageous, but add tradeoffs proportional to their complexity.

1. https://github.com/nathants/aws-gocljs/blob/258ea5bb72d06a50...

go, clojurescript, and aws. all three of these have problems, but like linux are the least bad of the available options. from some angles they are even quite good.

- go, a natural fit for backend with types and compilers and speed

- clojurescript (and react via reagent), a natural fit for frontend with dynamism, flexibility, and data centrism

- aws, a natural fit for infra. like linux, literally everyone is using it. if you avoid architect advice and tape over most of the knobs it’s quite good

example:

https://github.com/nathants/aws-gocljs

on aws as scale to zero services. lambda, dynamo, s3, and ephemeral ec2 spot.

when egress bandwidth is needed i use cloudflare workers + r2 just like i would use s3 presigned urls.

typically i start from a full project template[1][2]. sometimes i start from scratch[3].

1. https://github.com/nathants/aws-gocljs

2. https://github.com/nathants/aws-exec

3. https://github.com/nathants/libaws

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.