After waiting for what feels like forever, I’m excited to finally explore the last missing piece of Hotwire.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
[+] [-] joemasilotti|2 years ago|reply
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.
[+] [-] leononame|2 years ago|reply
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?
[+] [-] bradgessler|2 years ago|reply
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.
[+] [-] joemasilotti|2 years ago|reply
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.
[+] [-] pkcsecurity|2 years ago|reply
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.
[+] [-] foooorsyth|2 years ago|reply
[+] [-] nomdep|2 years ago|reply
[+] [-] joshmn|2 years ago|reply
[+] [-] tones411|2 years ago|reply
[+] [-] thehenster|2 years ago|reply
[+] [-] chris24680|2 years ago|reply
[+] [-] mindaslab|2 years ago|reply
[+] [-] Alifatisk|2 years ago|reply
Finally!
[+] [-] wilg|2 years ago|reply
[+] [-] mleonhard|2 years ago|reply
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.
[+] [-] gjsman-1000|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] sashenka|2 years ago|reply
[deleted]
[+] [-] btown|2 years ago|reply
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.
[+] [-] porsager|2 years ago|reply
[+] [-] steve1977|2 years ago|reply
Turbo is free and open-source. Nothing stops people from forking and keeping TypeScript alive in the fork.
[+] [-] hokumguru|2 years ago|reply
[deleted]
[+] [-] RomanPushkin|2 years ago|reply
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.