4 ms·

This all looks like Flutter to be honest.

by mda 7y ago

Razengan 7y ago
Indeed, but I prefer SwiftUI's syntax though, and the property wrappers + view modifiers paradigm, as well as Apple's Combine framework for processing data/events. Appears to result in less verbose and much cleaner, modular code compared to Dart+Flutter.
dep_b 7y ago
Yeah I really liked Flutter so I was excited that some of it's best ideas were coming to Apple. But Flutter is so young it's hard to imagine they rewrote whatever they had in a few months and got it ready to ship in just a few months for all of their major platforms. So I don't think they've borrowed it from Flutter, but if they did it might be even more impressive.
- mda 7y ago
  The first commit to Flutter was made in Oct 23 2014 (Initial name was Sky), It is almost as old as the Swift language itself. So, IMO, Swift UI had quite a bit inspiration from Flutter. If you look at the samples, the similarity is uncanny.
  - akmarinov 7y ago
    Isn't Flutter just a reimagining of React Native anyway?
    - seniorivn 7y ago
      It is in a way, it supposed to be a crossplatform declarative ui that feels native, isn't slow and etc
    - hajile 7y ago
      In theory, there are four fundamental approaches. 1. Separate stacks, native widgets 2. Shared stack, native widgets 3. Separate stacks, custom widgets 4. Shared stack, custom widgets React Native uses methods 1 and 2. They have unified components that can be used across platforms, but they lack features, so most complex apps use the second approach. The big wins are a more known language (JS) and sharing a bunch of the "backend of the frontend". The big downside happens when you add more systems (eg, web, OSX, Windows, Linux, etc). When you do this, the intersection shrinks and the potential for bugs in the shared widget increase dramatically. Flutter uses methods 3 and 4. Rather than using the native widgets, they carry along Skia to do the rendering for them. This neatly skips most of the UI intersection issues because if the native widget for X lacks a certain feature, you can add it yourself in your custom widget. When dramatically different looks are desired, you can still use separate widgets for different systems. Adding additional systems is usually less difficult because rather than writing hooks into everything on the system, you only need more basic system hooks and the effort to get the renderer working. The big downside here is development time and little inconsistencies. Instead of leveraging the work already done by the native developers (who probably know their system much better than the library's devs), everything must be built from scratch. Getting 90% there is easy, but getting every little detail working so it feels native is much harder. In addition, you must keep up with native widget changes which generally adds a lag time between their release and your catchup (but on the plus side, you may have already implemented some features they were missing). It should also be added that some UI features may not be available on some platforms (despite the shared widget) simply because the underlying OS does not support them, so multiple components may still be necessary for some things. Both approaches have been tried in the past. Qt is probably the most successful at cross-platform design and they use the 3rd and 4th methods. I'm inclined to think its a better solution in the end even if it is more costly.
      - dep_b 7y ago
        React Native doesn't use native widgets, only Xamarin does that.
      - sansnomme 7y ago
        To be fair, on Android Flutter is indistinguishable from native material design.
      - gurkendoktor 7y ago
        As a typical Mac snob, I used to care a lot about using native widgets. But UIKit doesn't even ship with a good-looking button class, and native apps often rewrite UI elements because the builtins are not very flexible (hello UITabBar). In theory that should make it easier for toolkits like Flutter to gain ground.
        zapzupnz 7y ago
        > But UIKit doesn't even ship with a good-looking button class There are so few times when one should want to use a plain button in iOS anyway. Most times when a user needs to make a choice or start a task, they pick it from a UITableView, UIAlertController presented as an action sheet, or press a UINavigationItem. > often rewrite UI elements because the builtins are not very flexible (hello UITabBar) What's specifically missing here? You have items, each has an icon and text, they can also have badges. Tapping on items changes the currently shown content view. What's a tab bar supposed to do besides that? A lot of the times I see these sorts of basic UI paradigms recreated, or the typical iOS HIG ignored by recreating an Android-style UI, the app can sometimes break when iOS has a major (or even minor) update or ignore accessibility guidelines. They're usually not significantly different in function, usually just aesthetics, and not usually sufficiently so to justify the cost.
        gurkendoktor 7y ago
        > There are so few times when one should want to use a plain button in iOS anyway. Almost every first-party app starts with a "Data & Privacy"/"What's New" dialog that uses a blue pill button, and almost every third-party app has a big fat "log in" button. Or look at Apple's redesigned Maps app. I don't know if I've ever worked on an app that didn't have its own ad-hoc button class. > What's a tab bar supposed to do besides that? Facebook, Instagram, Tweetbot etc. seem to have their own implementations because they want to hide the labels. Spotify has one to animate the icons when tapped. Audible has one to show the album art in the middle item. I'm going through my third-party apps right now, and only WhatsApp seems to use UITabBar as it was intended. > the app can sometimes break when iOS has a major (or even minor) update So did UITabBar earlier this year: https://stackoverflow.com/q/53084806 https://stackoverflow.com/q/53084806 I nudge my clients towards stock UIKit components as much as possible, for all the reasons you mentioned, but I don't think UIKit is that much better than e.g. Flutter in the way that AppKit is many times better than Electron.
fit2rule 7y ago
And Flutter looks like what has been done in Lua elsewhere, &etc.

This all looks like Flutter to be honest.

by mda 7y ago

This all looks like Flutter to be honest.

Indeed, but I prefer SwiftUI's syntax though, and the property wrappers + view modifiers paradigm, as well as Apple's Combine framework for processing data/events. Appears to result in less verbose and much cleaner, modular code compared to Dart+Flutter.

dep_b 7y ago

Yeah I really liked Flutter so I was excited that some of it's best ideas were coming to Apple. But Flutter is so young it's hard to imagine they rewrote whatever they had in a few months and got it ready to ship in just a few months for all of their major platforms. So I don't think they've borrowed it from Flutter, but if they did it might be even more impressive.

mda 7y ago
The first commit to Flutter was made in Oct 23 2014 (Initial name was Sky), It is almost as old as the Swift language itself. So, IMO, Swift UI had quite a bit inspiration from Flutter. If you look at the samples, the similarity is uncanny.
- akmarinov 7y ago
  Isn't Flutter just a reimagining of React Native anyway?
  - seniorivn 7y ago
    It is in a way, it supposed to be a crossplatform declarative ui that feels native, isn't slow and etc
  - hajile 7y ago
    In theory, there are four fundamental approaches. 1. Separate stacks, native widgets 2. Shared stack, native widgets 3. Separate stacks, custom widgets 4. Shared stack, custom widgets React Native uses methods 1 and 2. They have unified components that can be used across platforms, but they lack features, so most complex apps use the second approach. The big wins are a more known language (JS) and sharing a bunch of the "backend of the frontend". The big downside happens when you add more systems (eg, web, OSX, Windows, Linux, etc). When you do this, the intersection shrinks and the potential for bugs in the shared widget increase dramatically. Flutter uses methods 3 and 4. Rather than using the native widgets, they carry along Skia to do the rendering for them. This neatly skips most of the UI intersection issues because if the native widget for X lacks a certain feature, you can add it yourself in your custom widget. When dramatically different looks are desired, you can still use separate widgets for different systems. Adding additional systems is usually less difficult because rather than writing hooks into everything on the system, you only need more basic system hooks and the effort to get the renderer working. The big downside here is development time and little inconsistencies. Instead of leveraging the work already done by the native developers (who probably know their system much better than the library's devs), everything must be built from scratch. Getting 90% there is easy, but getting every little detail working so it feels native is much harder. In addition, you must keep up with native widget changes which generally adds a lag time between their release and your catchup (but on the plus side, you may have already implemented some features they were missing). It should also be added that some UI features may not be available on some platforms (despite the shared widget) simply because the underlying OS does not support them, so multiple components may still be necessary for some things. Both approaches have been tried in the past. Qt is probably the most successful at cross-platform design and they use the 3rd and 4th methods. I'm inclined to think its a better solution in the end even if it is more costly.
    - dep_b 7y ago
      React Native doesn't use native widgets, only Xamarin does that.
    - sansnomme 7y ago
      To be fair, on Android Flutter is indistinguishable from native material design.
    - gurkendoktor 7y ago
      As a typical Mac snob, I used to care a lot about using native widgets. But UIKit doesn't even ship with a good-looking button class, and native apps often rewrite UI elements because the builtins are not very flexible (hello UITabBar). In theory that should make it easier for toolkits like Flutter to gain ground.
      - zapzupnz 7y ago
        > But UIKit doesn't even ship with a good-looking button class There are so few times when one should want to use a plain button in iOS anyway. Most times when a user needs to make a choice or start a task, they pick it from a UITableView, UIAlertController presented as an action sheet, or press a UINavigationItem. > often rewrite UI elements because the builtins are not very flexible (hello UITabBar) What's specifically missing here? You have items, each has an icon and text, they can also have badges. Tapping on items changes the currently shown content view. What's a tab bar supposed to do besides that? A lot of the times I see these sorts of basic UI paradigms recreated, or the typical iOS HIG ignored by recreating an Android-style UI, the app can sometimes break when iOS has a major (or even minor) update or ignore accessibility guidelines. They're usually not significantly different in function, usually just aesthetics, and not usually sufficiently so to justify the cost.
        gurkendoktor 7y ago
        > There are so few times when one should want to use a plain button in iOS anyway. Almost every first-party app starts with a "Data & Privacy"/"What's New" dialog that uses a blue pill button, and almost every third-party app has a big fat "log in" button. Or look at Apple's redesigned Maps app. I don't know if I've ever worked on an app that didn't have its own ad-hoc button class. > What's a tab bar supposed to do besides that? Facebook, Instagram, Tweetbot etc. seem to have their own implementations because they want to hide the labels. Spotify has one to animate the icons when tapped. Audible has one to show the album art in the middle item. I'm going through my third-party apps right now, and only WhatsApp seems to use UITabBar as it was intended. > the app can sometimes break when iOS has a major (or even minor) update So did UITabBar earlier this year: https://stackoverflow.com/q/53084806 https://stackoverflow.com/q/53084806 I nudge my clients towards stock UIKit components as much as possible, for all the reasons you mentioned, but I don't think UIKit is that much better than e.g. Flutter in the way that AppKit is many times better than Electron.

fit2rule 7y ago

And Flutter looks like what has been done in Lua elsewhere, &etc.