Strada – Create fully native controls, driven by your web app(strada.hotwired.dev)
strada.hotwired.dev
Strada – Create fully native controls, driven by your web app
https://strada.hotwired.dev/
33 comments
I'm not sure I fully understand how it works. The intention is to start out with a WebView app, but slowly replacing the components that might need it with native components, right?
This isn't a React Native Web like approach where you try to cover the same surface area, but rather an individual implementation of each screen, so you could tweak and modify it for the given platform if needed?
Is it possible to embed native controls inside a webview or does this approach only work top down, i.e. does a components parent need to be native for it to be possible to be rendered natively?
This isn't a React Native Web like approach where you try to cover the same surface area, but rather an individual implementation of each screen, so you could tweak and modify it for the given platform if needed?
Is it possible to embed native controls inside a webview or does this approach only work top down, i.e. does a components parent need to be native for it to be possible to be rendered natively?
Turbo Native's goal is to reuse all your existing mobile web screens in your native apps. Strada helps progressively enhance them by slapping on a native component here and there.
You get baseline HTML coverage for free – Strada makes it easier to make things a bit more native.
You get baseline HTML coverage for free – Strada makes it easier to make things a bit more native.
If your like this approach to building hybrid native mobile apps, I highly recommend following Joe Masilotti at https://masilotti.com/
I only read three emails newsletters, and Joe’s is one of them because it’s roughly once per month and it keeps me current on all the things happening with Hotwire and Turbo Native apps.
I only read three emails newsletters, and Joe’s is one of them because it’s roughly once per month and it keeps me current on all the things happening with Hotwire and Turbo Native apps.
Oh hey, that's me! Thanks for the shout out, Brad.
I'm writing up my thoughts on the Strada launch right now. It will hit my newsletter, blog, and RSS feed tomorrow morning.
tl;dr - Strada alone doesn’t unlock new features for Turbo Native apps. Everything you can do with the framework you could already do before. Albeit with much, much more code. Strada provides structure and organization to the tangled mess that is the JavaScript bridge.
I'm writing up my thoughts on the Strada launch right now. It will hit my newsletter, blog, and RSS feed tomorrow morning.
tl;dr - Strada alone doesn’t unlock new features for Turbo Native apps. Everything you can do with the framework you could already do before. Albeit with much, much more code. Strada provides structure and organization to the tangled mess that is the JavaScript bridge.
subscribed because I saw your comment about newsletter tomorrow. Looking forward to it
Thank you!
This is a pretty interesting approach.
We've been doing a similar pattern already, because we have our web app iframed and communicating with outlook (via Office.JS) and gmail (via InboxSDK.JS) in order to read changes to the To: field and insert contents into the compose page based on that:
* stimulus encapsulates the javascript logic that "bridges" to Outlook and Gmail, including initializing the To: field listener * stimulus actions can trigger the "bridge" as well
It's worked out very well - though I really hate dealing with native stuff in general - especially compatibility nightmares with older versions of Outlook. Probably less of a problem with iOS/Android.
We've been doing a similar pattern already, because we have our web app iframed and communicating with outlook (via Office.JS) and gmail (via InboxSDK.JS) in order to read changes to the To: field and insert contents into the compose page based on that:
* stimulus encapsulates the javascript logic that "bridges" to Outlook and Gmail, including initializing the To: field listener * stimulus actions can trigger the "bridge" as well
It's worked out very well - though I really hate dealing with native stuff in general - especially compatibility nightmares with older versions of Outlook. Probably less of a problem with iOS/Android.
Something like Strada is the final piece for me to give Rails a real shot. I've been running with Django + htmx recently. I'm having to do backend-for-frontend and write redundant JSON APIs for mobile. And of course I lose the SSR in those cases.
Did you try Hyperview (https://hyperview.org/)? It´s discussed in the Hypermedia book like the htmx for mobile.
I use Django (python) and htmx to get away from React/JS/npm (or deno, or bun). Not trying to dunk on JavaScript/React devs, but the language and its ecosystem suck the joy out of me.
The experience using Django & htmx is very similar to using Django & Hyperview. In both cases, you are primarily working with Django views and templates to build your app. You don’t need to touch JS using either library unless you want custom client-side interactions.
Strada isn’t dependent on Rails, but Turbo.
Impressive! Would this be considered an alternative to Capacitor JS? https://capacitorjs.com/
Is there a cause for concern that a strada app might conflict with the App Store review guidelines?
Strada is just a standardized communication layer between native code and your Turbo web app. Turbo native is the native wrapper for the web app and that has been available for years and is used by a bunch of apps.
Thank you 37 signals. Nice to get relived from writing JavaScript.
I can’t believe this, I have been monitoring the page every week for two years. It felt like this would never get released.
Finally!
Finally!
It's honestly just sad how complicated the engineering is to make a modern CRUD app that works on the various platforms users expect and behaves normally. It doesn't seem tenable long-term to have to build your app three or four times, or use weird glue projects like this. This seems like a decent solution, to be sure, but still.
I built a thing that makes it much simpler to make apps: https://www.applin.dev
You make a web server that returns JSON defining your UI. Then you make a native iOS app by copy/pasting the provided Main.swift file and adding the URL of your server. The app uses an iOS client library, fetches the JSON page definition, and builds/updates the page with native widgets. I'm planning to eventually build Android, web, and desktop clients.
You make a web server that returns JSON defining your UI. Then you make a native iOS app by copy/pasting the provided Main.swift file and adding the URL of your server. The app uses an iOS client library, fetches the JSON page definition, and builds/updates the page with native widgets. I'm planning to eventually build Android, web, and desktop clients.
What sort of customers does this bring in? Looks very interesting, are there any public apps made with this or is it more of a internal-data-entry type of people who use it?
Applin is a brand new product. I plan to use it to build and finally launch https://www.cozydate.com/ .
Right now I'm building a web app, but I'm at the point where when it comes to phones, it's either fully native apps - or nothing. I take some relief knowing that only the "R" and a subset of "U" really needs to be in the app to satisfy almost everyone but staff in my case.
We migrated all our native apps to webapps. No fancy 3d apps. But mostly news apps. Lists, detail screens. Our approach shows no decrease in performance. But development becomes 10 times easier. Its a pita to work with iOS, but specially Android SDK is such a crap framework.
You still need a bit of native code. But at least all the UI related stuff can be created with css.
I developed and maintain two apps, both in native versions. We do quite a bit of custom graphics, prefer animation, lots of BLE (we push it in interesting ways, both characteristic counts and throughput) as well as have a mapping component that includes custom overlays which are user editable through direct drawing/dragging on top of the map. Oh, and some on device persistence, basic http fetching, and mqtt as well.
I agree with the sentiment that Android is just such a years long train wreck. I am currently rewriting one of the Android apps in 100% (as much as possible) "modern" and @Compose Android. So far... it seems better. But maybe the newness will eventually wear off. Some will the credit the "paradigm", but UIKit demonstrated to me that you could be a solidish "OO" ADK. I attribute @Compose to just being better engineered as a quasi functional approach than Android original stuff ever was as a Java implementation.
I am so worn out with the overall approach though. It is a ton of duplicate work. But I despair that the alternative would be no better? It seems that while today, I duplicate a lot of work, I get to choose how complex and coupled the various layers are. I do my best to just use stock stuff and not mash a bunch of stuff in. With a "web tech" solution, it seems the duplicity just rotates, so that the duplicity is just replaced by the complexity of trying to coordinate lots of disparate technologies, having to grow versed in even more domains, so that intelligent assesments can be made when things don't work as expected, and in which bucket/layer to focus ones efforts for each feature.
All that said, would you still encourage me to do as as you've done? I am honestly open.
I agree with the sentiment that Android is just such a years long train wreck. I am currently rewriting one of the Android apps in 100% (as much as possible) "modern" and @Compose Android. So far... it seems better. But maybe the newness will eventually wear off. Some will the credit the "paradigm", but UIKit demonstrated to me that you could be a solidish "OO" ADK. I attribute @Compose to just being better engineered as a quasi functional approach than Android original stuff ever was as a Java implementation.
I am so worn out with the overall approach though. It is a ton of duplicate work. But I despair that the alternative would be no better? It seems that while today, I duplicate a lot of work, I get to choose how complex and coupled the various layers are. I do my best to just use stock stuff and not mash a bunch of stuff in. With a "web tech" solution, it seems the duplicity just rotates, so that the duplicity is just replaced by the complexity of trying to coordinate lots of disparate technologies, having to grow versed in even more domains, so that intelligent assesments can be made when things don't work as expected, and in which bucket/layer to focus ones efforts for each feature.
All that said, would you still encourage me to do as as you've done? I am honestly open.
A nice benefit to the Turbo/Strada approach is that you can progressively enhance the apps over time. So you can start off with full functionality facilitated by the web app and overtime if it makes sense for the app you implement particular screens fully natively.
[deleted]
Ah, this is part of the Turbo project that had the whole controversy earlier this month around DHH unilaterally removing TypeScript, citing only his own experience, despite overwhelming community disapproval: https://github.com/hotwired/turbo/pull/971
It's a really cool pattern to have server-side rendering drive a specification that's used by web and native components alike. Airbnb uses this pattern to great effect: https://medium.com/airbnb-engineering/a-deep-dive-into-airbn... - and ironically, they speak to the importance of strong typing of the data model as a way to control complexity.
I really hoped that Turbo would be a way to make this pattern more mainstream. But, much like Unity, 37signals seems intent on taking actions that hurt its developer community, and it's hard to justify moving towards a solution with such antagonistic governance.
It's a really cool pattern to have server-side rendering drive a specification that's used by web and native components alike. Airbnb uses this pattern to great effect: https://medium.com/airbnb-engineering/a-deep-dive-into-airbn... - and ironically, they speak to the importance of strong typing of the data model as a way to control complexity.
I really hoped that Turbo would be a way to make this pattern more mainstream. But, much like Unity, 37signals seems intent on taking actions that hurt its developer community, and it's hard to justify moving towards a solution with such antagonistic governance.
Ah yes. Because your preferences are the only right ones. There are many more developers out there who doesn't want / need typescript, and aren't driven by the evangelist influencer opinionated nonsense.
I don’t think you can compare this to the Unity situation.
Turbo is free and open-source. Nothing stops people from forking and keeping TypeScript alive in the fork.
Turbo is free and open-source. Nothing stops people from forking and keeping TypeScript alive in the fork.
What bothers me a bit, while it's still open source with permissive license, the direction is dictated by 37signals. Which is known for its questionable decisions. Related both to software and community side of things.
I am quite hesitant to use 37signals tools for now. Partially because they pretty much didn't ask anyone dropping TypeScript. But also because in general open source software owned by one single company sometimes goes to the direction community of engineers don't want them to go.
For example, Tensorflow dropped Windows support. While it's Apache License 2.0, and alternatives, there are dependencies.
Do I want to introduce dependency that I will regret in the future? With 37signals the answer is most likely yes. The same for Unity, for example. Or Unreal engine -- even though they didn't do anything wrong... yet.
37signals do not value their reputation too much as well. After mass exodus I expected them too be a bit nicer. But TypeScript situation just tells me it's ongoing issue, there is element of surprise.
I will be happy to know I am wrong, since the tool itself looks like I want to use it.
I am quite hesitant to use 37signals tools for now. Partially because they pretty much didn't ask anyone dropping TypeScript. But also because in general open source software owned by one single company sometimes goes to the direction community of engineers don't want them to go.
For example, Tensorflow dropped Windows support. While it's Apache License 2.0, and alternatives, there are dependencies.
Do I want to introduce dependency that I will regret in the future? With 37signals the answer is most likely yes. The same for Unity, for example. Or Unreal engine -- even though they didn't do anything wrong... yet.
37signals do not value their reputation too much as well. After mass exodus I expected them too be a bit nicer. But TypeScript situation just tells me it's ongoing issue, there is element of surprise.
I will be happy to know I am wrong, since the tool itself looks like I want to use it.
Strada is an optional add-on for Turbo Native apps that enables native components driven by the web. It unlocks progressive enhancement of individual controls without converting entire screens to native.
For example, converting a <button> to a UIBarButtonItem on iOS or rendering a HTML modal with ModalBottomSheetLayout on Android.
It’s important to call out that Strada alone doesn’t unlock new features for Turbo Native apps. Everything you can do with the framework you could already do before. Albeit with much, much more code.
Strada provides structure and organization to the tangled mess that is the JavaScript bridge. It simplifies and standardizes communication between web and native components, which makes building robust native elements a joy.
Just my 2¢, having worked with Turbo Native for 6+ years now.