We will grow to include more native code over time, but for now we are taking the approach of native shell/web views. This approach lost favor early in iOS days, but I believe it is a very valid approach these days. It is inspired by how Basecamp does things. Our tech stack is a bit different, but the ideas are the same.
By leveraging wkwebviews as much as possible, I think we can make this all pretty awesome and sync up with our web dev work pretty smoothly. And where it makes sense, we can re-implement certain things fully native, or build entirely native features. Life's a journey, not a destination.
Their argument is true. But you can still use Flutter for Android only dev.It may speed up your development. Plus I think it is important to have variety. I do intend this one to offer something little different (even less features than the official app eventually) rather than it being an exact clone of the webapp or official android app.
Their argument is true. But you can still use Flutter for Android only dev.It may speed up your development.
I do think it depends on the size of the company and what you're trying to accomplish. They have a functional PWA, they wrapped it in the respective platforms's webviews and obtained an app. They'll slowly add native features upon need.
I understand the argument pro Flutter but they hit a roadblock with the following issue and decided to go in a different direction:
By looking at the repo, it was fixed two months after the iOS app came out and the plugin is still currently in developers preview with quite a lot of bugs
I believe that's the reason why Flutter wasn't chosen at the time
Hi Rafi, if you want to know why the app is not in Flutter or other frameworks you can check out Ben's post about it:
Why Not React Native? Why Not Flutter? Why Not Meteor? Why Not NativeScript?
Ben Halpern
and the README of the iOS app:
DEV Community iOS App
DEV iOS💖
This is the repo for the dev.to iOS app.
Status:
Released first version, more info: twitter.com/bendhalpern/status/106...
Design ethos
We will grow to include more native code over time, but for now we are taking the approach of native shell/web views. This approach lost favor early in iOS days, but I believe it is a very valid approach these days. It is inspired by how Basecamp does things. Our tech stack is a bit different, but the ideas are the same.
m.signalvnoise.com/basecamp-3-for-...
signalvnoise.com/posts/3743-hybrid...
signalvnoise.com/posts/3766-hybrid...
youtube.com/watch?v=SWEts0rlezA
By leveraging
wkwebviewsas much as possible, I think we can make this all pretty awesome and sync up with our web dev work pretty smoothly. And where it makes sense, we can re-implement certain things fully native, or build entirely native features. Life's a journey, not a destination.Contributing
Their argument is true. But you can still use Flutter for Android only dev.It may speed up your development. Plus I think it is important to have variety. I do intend this one to offer something little different (even less features than the official app eventually) rather than it being an exact clone of the webapp or official android app.
I do think it depends on the size of the company and what you're trying to accomplish. They have a functional PWA, they wrapped it in the respective platforms's webviews and obtained an app. They'll slowly add native features upon need.
I understand the argument pro Flutter but they hit a roadblock with the following issue and decided to go in a different direction:
Presumably this requires some compositor work, similar to maps or video?
By looking at the repo, it was fixed two months after the iOS app came out and the plugin is still currently in developers preview with quite a lot of bugs
I believe that's the reason why Flutter wasn't chosen at the time
I do agree on that. That Flutter has lot to keep up with the native eco-system for now.