9 ms·

Cross-platform frameworks that don’t use native controls have suffered from problems... - They inevitably don’t look or work like native apps in ways both big

by jmull 8y ago

Cross-platform frameworks that don’t use native controls have suffered from problems... - 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.) - 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. - 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. - there are cross-platform issues, like fonts that fit on one host OS get cut off in another, or differences in volume control etc. - 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). - 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. - 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. Building and maintaining an app twice is a very serious expense. But the expense of dealing with the issues with crosss-platform frameworks can be pretty big as well. Of course it depends on what you’re doing (shorter term and longer term) whether or not it makes sense. But go in with your eyes open. Consider other options (like examining your app architecture and see if you can’t find a way to factor some of your naturally cross-platform stuff into a shared library usable by the native apps of each platform you support).

coldtea 8y ago
>- They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. We're way past that in the mobile world, where both Google, Facebook, and other top dogs use non-native cross platform frameworks and looks (e.g. Material UI).
- pjmlp 8y ago
  Material UI just happens to be the official Android UI.
  - coldtea 8y ago
    Which is irrelevant to my point, which is that it's also used where it's not native.
    - pjmlp 8y ago
      So Cocoa is missing from your list given iTunes on PC.
      - deleted 8y ago
        [deleted]
      - frutiger 8y ago
        Given the usage of e.g. and offering the most charitable interpretation of coldtea’s comment, I guess it wasn’t supposed to be an exhaustive list, just the first (or most pervasive?) thing that came to mind.
      - coldtea 8y ago
        Sure, and many others are also missing. I gave some examples, not an exhaustive catalog. This is hinted at where I say "Google, Facebook, _and other top dogs_", and "_e.g._ Material UI" -- emphasis mine.
- malkia 8y ago
  Same in the desktop world - Qt emulates the widgets, but can theme them, then QML is another story. Also WPF (from what I've heard) uses (skia?) to paint own widgets. IMGUI is another example. Then using the native wrappers, like wxWidgets is often cumbersome to create customized control, and if you do you end up with some platform specific version (not end of the world, but pretty much why not use the OS toolkit directly). Also any wrapper soon or later suffers from "leaky abstraction" - where you hide things behind interfaces, but can't hide different performance characteristics, and getting the current line in a log dialog might just kill you, because underneath it might be scanning all '\n', '\r' until your cursor position.
dmix 8y ago
These are all excellent points. I'm curious how Flutter stands to address these risks/issues in the early days. I'd imagine it will take much more than 1.0 to get close to parity with the OS. Even if we assume it will always be 90% of the full OS experience (which is fine for the vast majority of use cases).
- exacube 8y ago
  It helps that the Flutter and Android teams can talk to each other (they're both part of Google). So atleast for Android, you might be able to expect Android platform features appearing on Flutter in sync'd release cycles. And in cases where you're using platform-specific feature that Flutter doesn't support yet, then your experience will be no different -- the burden remains on you to write platform-specific code. It's unclear to me that this is a sticking point.
  - jakub_g 8y ago
    Two Google teams talking to each other and syncing their agendas and deliveries (or two teams in any big company) is quite a major assumption.
    - exacube 8y ago
      Only one team needs to sync with another in this scenario. It's also assuming that the Flutter team wouldn't consider do that considering they have that kind of information available to them -- it's in their best interest, after all.
      - iainmerrick 8y ago
        If only one team needs to sync, how is it any advantage for Flutter and Android to be within the same company? How is the situation any different from Flutter and iOS? I agree with the other commenter -- don’t expect any close cooperation between Flutter and Android because that’s just not how Google (and other huge companies) tends to work.
fit2rule 8y ago
There's one place where none of this matters: Games engines. Games have the same, consistent (hopefully) easy to use interface across every platform they support. They either accomplish this, or they simply don't survive on the market. It has to be said that most modern UI frameworks ARE game engines, anyway. Or maybe its a tautology: game engines eventually become platforms, which become "OS's on other OS's". Which means that in this scenario: > 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. .. It becomes moot whether you're using an engine or an OS's own specific platform. You have either an 'engine developer' or a 'user-facing developer', where the former does everything needed on the target OS to support the latter. My personal preference: treat onboard native UI frameworks as a plug-out interface to the engine, port the engine everywhere, have my apps look and feel and function the same, no matter where they are running. Screw the OS vendors and their UI's - they change their frameworks so frequently and for no good reason other than to lock in the poor developer who thinks he has to learn their framework, or else not be competitive. That may be true, but the real competition is in building an app that functions - and functions well - wherever you port it. To accomplish that, you've gotta be willing to be both an expert at the native framework, while also abandoning it ...
- npunt 8y ago
  Game engines are a place where it makes sense to roll your own UI framework many times, so on that point I agree with you. The purpose of a game is generally immersion and escape, so makes sense to remove users from their device's UI in many instances. Game UIs tend to have their own conventions so frequent players don't have much of a learning curve. But in general players accept some learning curve because games are about taking on a challenge. However, apps are not games. They're tools. And tools are not about giving your users challenges. They're about fulfilling a purpose as easily as possible. UI frameworks and conventions matter here because they lower the learning curve and cognitive switching cost, and they respect a user's preferences for how they wish to engage with their device (including valuable OS-wide capabilities like accessibility). Companies that choose to use their own UI frameworks or avoid the platform's guidelines are doing so to the detriment of their user experience. - Some do it accidentally, because they don't know the UX guidelines or subtleties of the platform - Some do it for expedience, because they need to put out a product quickly with few resources - Some do it strategically, because they want the user experience worse since it serves other purposes for them Yes, UI frameworks change as OSes change, but it's rarely for 'no reason'. Stepping back, devices have gotten way more capable and their UX way more sophisticated... which does necessitate change. Though that's some extra work for developers, it's not about you. It's about your users.
exacube 8y ago
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.
jetako 8y ago
I share your concern regarding text fields. That's the one area where I never want to mess with native behavior. The search results for "flutter ios text field copy paste" aren't encouraging.
chiefalchemist 8y ago
> "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." Good product is a team effort. The question is: Can you find the right people - not just any people but the right people - to come on-board, use / learn the tools you've chosen, and make magic happen? Sheer technical prowess of tools and/or people is not enough. That aside, to your points, there are __always__ tradeoffs. Some more detrimental than others. But again, preserving is a function of team. Someone somewhere is doing what your team is doing, and doing it better. They have the same technologies. So then the question is: why.

by jmull 8y ago

coldtea 8y ago

>- They inevitably don’t look or work like native apps in ways both big and small, frustrating and annoying users. We're way past that in the mobile world, where both Google, Facebook, and other top dogs use non-native cross platform frameworks and looks (e.g. Material UI).

pjmlp 8y ago
Material UI just happens to be the official Android UI.
- coldtea 8y ago
  Which is irrelevant to my point, which is that it's also used where it's not native.
  - pjmlp 8y ago
    So Cocoa is missing from your list given iTunes on PC.
    - deleted 8y ago
      [deleted]
    - frutiger 8y ago
      Given the usage of e.g. and offering the most charitable interpretation of coldtea’s comment, I guess it wasn’t supposed to be an exhaustive list, just the first (or most pervasive?) thing that came to mind.
    - coldtea 8y ago
      Sure, and many others are also missing. I gave some examples, not an exhaustive catalog. This is hinted at where I say "Google, Facebook, _and other top dogs_", and "_e.g._ Material UI" -- emphasis mine.
malkia 8y ago
Same in the desktop world - Qt emulates the widgets, but can theme them, then QML is another story. Also WPF (from what I've heard) uses (skia?) to paint own widgets. IMGUI is another example. Then using the native wrappers, like wxWidgets is often cumbersome to create customized control, and if you do you end up with some platform specific version (not end of the world, but pretty much why not use the OS toolkit directly). Also any wrapper soon or later suffers from "leaky abstraction" - where you hide things behind interfaces, but can't hide different performance characteristics, and getting the current line in a log dialog might just kill you, because underneath it might be scanning all '\n', '\r' until your cursor position.

dmix 8y ago

These are all excellent points. I'm curious how Flutter stands to address these risks/issues in the early days. I'd imagine it will take much more than 1.0 to get close to parity with the OS. Even if we assume it will always be 90% of the full OS experience (which is fine for the vast majority of use cases).

exacube 8y ago
It helps that the Flutter and Android teams can talk to each other (they're both part of Google). So atleast for Android, you might be able to expect Android platform features appearing on Flutter in sync'd release cycles. And in cases where you're using platform-specific feature that Flutter doesn't support yet, then your experience will be no different -- the burden remains on you to write platform-specific code. It's unclear to me that this is a sticking point.
- jakub_g 8y ago
  Two Google teams talking to each other and syncing their agendas and deliveries (or two teams in any big company) is quite a major assumption.
  - exacube 8y ago
    Only one team needs to sync with another in this scenario. It's also assuming that the Flutter team wouldn't consider do that considering they have that kind of information available to them -- it's in their best interest, after all.
    - iainmerrick 8y ago
      If only one team needs to sync, how is it any advantage for Flutter and Android to be within the same company? How is the situation any different from Flutter and iOS? I agree with the other commenter -- don’t expect any close cooperation between Flutter and Android because that’s just not how Google (and other huge companies) tends to work.

fit2rule 8y ago

There's one place where none of this matters: Games engines. Games have the same, consistent (hopefully) easy to use interface across every platform they support. They either accomplish this, or they simply don't survive on the market. It has to be said that most modern UI frameworks ARE game engines, anyway. Or maybe its a tautology: game engines eventually become platforms, which become "OS's on other OS's". Which means that in this scenario: > 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. .. It becomes moot whether you're using an engine or an OS's own specific platform. You have either an 'engine developer' or a 'user-facing developer', where the former does everything needed on the target OS to support the latter. My personal preference: treat onboard native UI frameworks as a plug-out interface to the engine, port the engine everywhere, have my apps look and feel and function the same, no matter where they are running. Screw the OS vendors and their UI's - they change their frameworks so frequently and for no good reason other than to lock in the poor developer who thinks he has to learn their framework, or else not be competitive. That may be true, but the real competition is in building an app that functions - and functions well - wherever you port it. To accomplish that, you've gotta be willing to be both an expert at the native framework, while also abandoning it ...

npunt 8y ago
Game engines are a place where it makes sense to roll your own UI framework many times, so on that point I agree with you. The purpose of a game is generally immersion and escape, so makes sense to remove users from their device's UI in many instances. Game UIs tend to have their own conventions so frequent players don't have much of a learning curve. But in general players accept some learning curve because games are about taking on a challenge. However, apps are not games. They're tools. And tools are not about giving your users challenges. They're about fulfilling a purpose as easily as possible. UI frameworks and conventions matter here because they lower the learning curve and cognitive switching cost, and they respect a user's preferences for how they wish to engage with their device (including valuable OS-wide capabilities like accessibility). Companies that choose to use their own UI frameworks or avoid the platform's guidelines are doing so to the detriment of their user experience. - Some do it accidentally, because they don't know the UX guidelines or subtleties of the platform - Some do it for expedience, because they need to put out a product quickly with few resources - Some do it strategically, because they want the user experience worse since it serves other purposes for them Yes, UI frameworks change as OSes change, but it's rarely for 'no reason'. Stepping back, devices have gotten way more capable and their UX way more sophisticated... which does necessitate change. Though that's some extra work for developers, it's not about you. It's about your users.

exacube 8y ago

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.

jetako 8y ago

I share your concern regarding text fields. That's the one area where I never want to mess with native behavior. The search results for "flutter ios text field copy paste" aren't encouraging.

chiefalchemist 8y ago

> "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." Good product is a team effort. The question is: Can you find the right people - not just any people but the right people - to come on-board, use / learn the tools you've chosen, and make magic happen? Sheer technical prowess of tools and/or people is not enough. That aside, to your points, there are __always__ tradeoffs. Some more detrimental than others. But again, preserving is a function of team. Someone somewhere is doing what your team is doing, and doing it better. They have the same technologies. So then the question is: why.