5 ms·
I'm wondering about this as well, actually this weekend been doing Flutter 'Test Drive' of their tutorial and experience was not that great. I'm still forcing m
by pzo 3y ago
I'm wondering about this as well, actually this weekend been doing Flutter 'Test Drive' of their tutorial and experience was not that great. I'm still forcing my brain to parse this complex structure with very simple widget structure from their samples.
Its Flutter:
```
class MyHomePage extends StatelessWidget {
@override
Widget build(BuildContext context) {
var appState = context.watch<MyAppState>();
var pair = appState.current;
return Scaffold(
body: Center(
child: Column(
mainAxisAlignment: MainAxisAlignment.center,
children: [
BigCard(pair: pair),
SizedBox(height: 10),
ElevatedButton(
onPressed: () => appState.getNext(),
child: Text('Next'),
),
],
),
),
);
}
}
```
versus SwiftUI:
```
struct MyHomePage: View {
@StateObject private var appState = MyAppState()
var body: some View {
VStack {
BigCard(pair: appState.current)
.padding(.bottom, 10)
Button("Next") {
appState.getNext()
}
.padding()
.background(Color.blue)
.foregroundColor(.white)
.cornerRadius(8)
}
.frame(maxWidth: .infinity, maxHeight: .infinity)
.padding()
}
}
```
versus React Native:
```
const MyHomePage = () => {
const [pair, setPair] = useState(/* initial pair /);
const getNext = () => {
// Logic to get the next pair
// You'll need to implement this function
};
return (
<View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
{/* Replace BigCard with appropriate React Native components */}
<BigCard pair={pair} />
<View style={{ marginVertical: 10 }}>
<Button title="Next" onPress={getNext} />
</View>
</View>
);
};
```
- sgt 3y agoWith the help of the IDE (Android Studio is what I use for Flutter development) it is actually pretty OK. It's easy to use keyboard shortcuts to see / explore function parameters and so on. I also indent regularly so I can easily undo if something is clearly out of whack. That said, SwiftUI is clearly the supreme leader in this declarative approach.
- kazinator 3y agoI don't program in anything resembling any of this stuff. The Flutter looks the best to me, out of those, hands down.
- jcelerier 3y agoI'm curious at the point you are trying to make - I don't know any of the three but Flutter looks by far the most obvious and easier to read and understand
- pzo 3y agoI recommend putting those code snippet I shared to VSCode and using default formatting - this will be more visible in IDE. But other annoying things for me: 1) SwiftUI feel more like jquery so that you can chain styles like padding, color, font etc. Because of that : - code completion just works and is fast you just press a '.' and see all choices - it's easy refactor the code if you wan't to change styling or layout 2) Flutter abusing too much composition and adapter pattern to the point they using refactoring in VSCode to add simple padding etc. Just have look at this official GIF from 'Test Drive' - how many times 'down arrow' got pressed: https://codelabs.developers.google.com/static/codelabs/flutter-codelab-first/img/6b585b43e4037c65.gif https://codelabs.developers.google.com/static/codelabs/flutt... Now imagine designer come to you and telling you we change layout and styling slightly - in flutter I feel it's easier to throw away such layout code and start from scratch than trying to refactor it. In swift UI you just change VStack to HStack, change maybe some parameters and move around chain of .padding().color() around and are done with it. What would improve flutter readability is extending Dart to have something like Swift: - first parameter can be marked as optional specifing parameters name such as '_ child:' - escaping parameters in Swift so you instead of doing ... children: []) you can just close previous Widget and make also 'children' parameter name optional so that you can write : Row(.min) { ElevatedButton( onPressed:() { appState.getNext(); } ) { Text('Next') } } - similar enum behavior like in Swift when you can just type '.red' instead of 'Color.red' - this is even more useful for more nested enums. edit: I gave up with proper formatting of code here in HN, super annoying.