11–20 of 34 posts
Is there a cause for concern that a strada app might conflict with the App Store review guidelines?
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.
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.
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.
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.
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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 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 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.
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, 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:…