5 ms·

These seem like valid concerns at first glance, but I feel these are not really issues in practice (only in theory). >> - They inevitably don’t look or work li

These seem like valid concerns at first glance, but I feel these are not really issues in practice (only in theory). >> - They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. (... the spell-checker doesn’t work right or text selection is janky or unavailable where it should be, certain short-cuts work differently or have different gestures or keys, etc.) as `coldtea` points out below, this is not really an issue in today's ecosystem. Branding themes are more prevelant on most apps people are using than not. >> they don’t get updates to native controls... e.g. if the OS adds some new drag-and-drop capability to text fields the framework doesn’t get it unless and until the framework is updated (and the app is updated to use the newer version of the framework). Of course, some things are never deemed important enough to be adopted by the framework. If people are writing cross-platform apps and want to use new platform-specific features, wouldn't they have to write platform-specific code anyway if they were native? I'm not sure this is a newly introduced problem in any sense. >> - Ambitious frameworks that really try to minimize the gaps between apps build with the framework vs native app grow to be very large. They take on the role of the entire app-facing OS API, which is truely massive in today’s systems. This leads to slow-loading/building, resource-hungry apps. Each app becomes a mini-OS unto itself. I guess that's valid; but I'm curious about cases where code-heavy app sizes have actually hindered app downloads. I don't really know, but I haven't heard that this has been a big problem? For reference, a hello world flutter apk clocks in at 5 MB. >> - there are cross-platform issues, like fonts that fit on one host OS get cut off in another, or differences in volume control etc. Flutter renders all of its fonts itself natively, using the same way Chrome does it. Has this been a problem? >> - dealing with the cross-platform issues the framework doesn’t solve becomes very difficult for the app developer. They’ve got to find a way in, through, or around the framework (in an area it already isn’t handling well). >> - many potential third-party tools will have native support and bindings but most won’t make accommodations for your framework, so you end up having to support that yourself, or do without. Is this a remark on an incomplete cross platform framework (i.e., flutter needs more features) and that it hasn't reached enough popular usage, or that cross platform frameworks have this problem? If not, it feels like the alternative to not using a cross platform framework is to write everything for each platform in a platform-specific way, which might be considered much worse. What's the issue at hand here? >> - devs have yet another set of tech and tools they have to master. And I mean devs in the wide sense here, designers, coders, testers, etc. Some also have to become masters of how the framework and each host OS interact, in order to debug the inevitable problems. This feels like an emotional assessment of having to learn something new. If this technology is meant to simplify/remove problems that people have today, then isn't it worth learning? I guess you might feel this way if you felt that flutter isn't adding anything of value to other popular solutions today.

saagarjha 8y ago
> as `coldtea` points out below, this is not really an issue in today's ecosystem. Branding themes are more prevelant on most apps people are using than not. On iOS, the extent of "branding themes" end up is often limited. > Flutter renders all of its fonts itself natively, using the same way Chrome does it. Has this been a problem? There is no Chrome on iOS. So Flutter is different from everything else out there. > Is this a remark on an incomplete cross platform framework (i.e., flutter needs more features) and that it hasn't reached enough popular usage, or that cross platform frameworks have this problem? If not, it feels like the alternative to not using a cross platform framework is to write everything for each platform in a platform-specific way, which might be considered much worse. What's the issue at hand here? Flutter, and almost every other cross-platform framework, have this problem.
- JeremyBanks 8y ago
  Chrome on iOS exists. I think you meant to say it uses WebKit (and native font rendering) instead of Blink.
  - jeremyjh 8y ago
    A distinction without a difference.
    - JeremyBanks 8y ago
      ok
jmull 8y ago
>... but I feel these are not really issues in practice (only in theory). Ha, I wish! I've been down this road a few times and this list came from contemplating some of my old battle scars. > ...as `coldtea` points out below, this is not really an issue in today's ecosystem. That's not quite the same thing as it not being a problem. I know it can be done, but it's harder than when using native controls. This is something the "big dogs" can handle (they can bring massive resources to high-profile projects if need be) -- especially if they control the framework. > ...cases where code-heavy app sizes have actually hindered app downloads... Well, look around for people complaining about bloat. It's not usually the download itself, by the way. Memory is filled and runtimes have to initialize, buffers allocated, etc. It all takes time and uses runtime resources. This is fine to a point, but once you use too many resources or take too much time, it has a negative impact on the app (and as the developer, you have to deal with it in some way... e.g., perhaps spend time to alleviate the issues or perhaps walk away from lower-end devices). Any app, no matter the tech used to develop it can face these issues as it grows. But with an engine you start off closer to the limits and have less control over resource usage, so you generally reach them more quickly. > Flutter renders all of its fonts itself natively, using the same way Chrome does it. Has this been a problem? Hey, if flutter solves cross-platform text in 1.0 as you suggest, then good for them. Believe me, that's a massive accomplishment. (Though I'll note: if they aren't using native facilities, they'll have to duplicate them, which goes back to the point on bloat.) > Is this a remark on an incomplete cross platform framework...? No, I'm saying apps -- at some point -- generally eventually need to incorporate third-party libraries/tools to best accomplish their purpose. A PDF generator, a .csv parser, an image processor, an AI library, whatever. (A framework can't include an API for everything and shouldn't try, so it's not a matter of an incomplete framework). However whatever third-partly library you're interested in probably won't provide direct support for your framework, so you'll have to figure it out and do it yourself. It really depends on the library and the framework and how/whether they overlap how much harder this is. E.g., suppose you want to incorporate an image rendering library of some sort into your app. The library supports iOS and Android and can output to UIImage on iOS and Bitmap on Android and their site provides samples showing how each of these work. But you're using a framework that has "XImage" and "XImageView". So now you need to delve into the platform's "XImage" to figure out how to load a UIImage into it on iOS and a Bitmap on Android. Maybe you find it works in terms of OpenGL textures and you realize going through a UIImage/Bitmap is an extra, inefficient step, so now you're learning about how to load directly from the library output into an OpenGL texture and you learn OpenGL textures can have different color formats so you start using the complicated low-level API of the image library to get output in the color format of the OpenGL texture. Whew! What would have been a few lines of code in each native app turned into a couple days of work, but you're done and release it.... and shortly thereafter, you start getting reports that the images are flipped on certain devices. Uh Oh... Now, maybe flutter doesn't have this particular problem, but this is just an example. This kind of thing will pop up as you integrate the third-party libraries you use with the UI platform. The more "opinionated" the UI platform is, the more quickly you'll run into these kinds of problems. > This feels like an emotional assessment of having to learn something new. Oh, come on. I'm pointing out an additional cost to adopting this kind of platform. That's a real concern to anyone developing apps, not something you can dismiss as an "emotional assessment" (Not sure even what that means -- laziness?). Note, this is an additional cost since you'll need native expertise in any case.

saagarjha 8y ago

> as `coldtea` points out below, this is not really an issue in today's ecosystem. Branding themes are more prevelant on most apps people are using than not. On iOS, the extent of "branding themes" end up is often limited. > Flutter renders all of its fonts itself natively, using the same way Chrome does it. Has this been a problem? There is no Chrome on iOS. So Flutter is different from everything else out there. > Is this a remark on an incomplete cross platform framework (i.e., flutter needs more features) and that it hasn't reached enough popular usage, or that cross platform frameworks have this problem? If not, it feels like the alternative to not using a cross platform framework is to write everything for each platform in a platform-specific way, which might be considered much worse. What's the issue at hand here? Flutter, and almost every other cross-platform framework, have this problem.

JeremyBanks 8y ago
Chrome on iOS exists. I think you meant to say it uses WebKit (and native font rendering) instead of Blink.
- jeremyjh 8y ago
  A distinction without a difference.
  - JeremyBanks 8y ago
    ok

jmull 8y ago

>... but I feel these are not really issues in practice (only in theory). Ha, I wish! I've been down this road a few times and this list came from contemplating some of my old battle scars. > ...as `coldtea` points out below, this is not really an issue in today's ecosystem. That's not quite the same thing as it not being a problem. I know it can be done, but it's harder than when using native controls. This is something the "big dogs" can handle (they can bring massive resources to high-profile projects if need be) -- especially if they control the framework. > ...cases where code-heavy app sizes have actually hindered app downloads... Well, look around for people complaining about bloat. It's not usually the download itself, by the way. Memory is filled and runtimes have to initialize, buffers allocated, etc. It all takes time and uses runtime resources. This is fine to a point, but once you use too many resources or take too much time, it has a negative impact on the app (and as the developer, you have to deal with it in some way... e.g., perhaps spend time to alleviate the issues or perhaps walk away from lower-end devices). Any app, no matter the tech used to develop it can face these issues as it grows. But with an engine you start off closer to the limits and have less control over resource usage, so you generally reach them more quickly. > Flutter renders all of its fonts itself natively, using the same way Chrome does it. Has this been a problem? Hey, if flutter solves cross-platform text in 1.0 as you suggest, then good for them. Believe me, that's a massive accomplishment. (Though I'll note: if they aren't using native facilities, they'll have to duplicate them, which goes back to the point on bloat.) > Is this a remark on an incomplete cross platform framework...? No, I'm saying apps -- at some point -- generally eventually need to incorporate third-party libraries/tools to best accomplish their purpose. A PDF generator, a .csv parser, an image processor, an AI library, whatever. (A framework can't include an API for everything and shouldn't try, so it's not a matter of an incomplete framework). However whatever third-partly library you're interested in probably won't provide direct support for your framework, so you'll have to figure it out and do it yourself. It really depends on the library and the framework and how/whether they overlap how much harder this is. E.g., suppose you want to incorporate an image rendering library of some sort into your app. The library supports iOS and Android and can output to UIImage on iOS and Bitmap on Android and their site provides samples showing how each of these work. But you're using a framework that has "XImage" and "XImageView". So now you need to delve into the platform's "XImage" to figure out how to load a UIImage into it on iOS and a Bitmap on Android. Maybe you find it works in terms of OpenGL textures and you realize going through a UIImage/Bitmap is an extra, inefficient step, so now you're learning about how to load directly from the library output into an OpenGL texture and you learn OpenGL textures can have different color formats so you start using the complicated low-level API of the image library to get output in the color format of the OpenGL texture. Whew! What would have been a few lines of code in each native app turned into a couple days of work, but you're done and release it.... and shortly thereafter, you start getting reports that the images are flipped on certain devices. Uh Oh... Now, maybe flutter doesn't have this particular problem, but this is just an example. This kind of thing will pop up as you integrate the third-party libraries you use with the UI platform. The more "opinionated" the UI platform is, the more quickly you'll run into these kinds of problems. > This feels like an emotional assessment of having to learn something new. Oh, come on. I'm pointing out an additional cost to adopting this kind of platform. That's a real concern to anyone developing apps, not something you can dismiss as an "emotional assessment" (Not sure even what that means -- laziness?). Note, this is an additional cost since you'll need native expertise in any case.