Hacker News Reader

Comment by zigzag312 | Hacker News Reader

Dart is my biggest issue with Flutter. It's still missing ergonomic features like data classes and lower level things like unsigned 64-bit integers. There is no runtime reflection, which I think is a good thing for end user apps, but it's also missing static metaprogramming. And code generation is not integrated into a complier. Since, there is no runtime reflection, metaprogramming & integrated code-gen are sorely needed.

Flutter itself is slowly reaching maturity on mobile and is already quite good, if you can live with a few compromises.

View on HN

The biggest issue with Dart IMHO is not so much the language itself, but the ecosystem.

For the record, Swift suffers from this problem as well. Kotlin only avoids it because of Java interop, although even this becomes complicated because of Google’s half-assed implementation of Java on Android.

I think this is one of the biggest reasons to reach for JavaScript instead. It has a lot of flaws, but it has a huge ecosystem that works nearly everywhere.

Also worth keeping in mind some of the cross language extension points in Dart.

Compiles to Wasm and can work with other compile to wasm languages.

Has quite good support for C, C++, JS, Swift, Java and Rust interop where they have tools that will write all of the glue code for you.

Also has decent gRPC support meaning you can use any other language that also fits that category.

It’s a small Dart ecosystem but it’s fundamentals are great and it’s extension points are much better than you will likely find elsewhere.

It may lack things - true. But it's a pleasure to work in. I code quite a bit of Dart these days and the language never really holds you back. It flows quite easily. I use some code generation by having a build runner in the background.

I'm wondering how you deal with the pile of constructor calls needed to construct views in Flutter? Deeply nested expressions remind me of Lisp.

JSX is conceptually the same but somehow seems easier to read. Maybe it's the close tags?

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>
  );

}; ```

With 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.

I don't program in anything resembling any of this stuff.

The Flutter looks the best to me, out of those, hands down.

I'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

I 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/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.

I use the packages flutter_hooks and functional_widget. They remove most of the boilerplate required for Flutter.

> Deeply nested expressions remind me of Lisp.

Is this supposed to be a bad thing? :(

In Lisp, if you had piles of related constructors, you'd make a macro for that that would look like a declarative description of the view.

Isn't the need for code generation indicative of the language holding you back?

Isn't the need to drive a car indicative of living in the suburbs "holding you back"?

Code generation (and modification) tools are there to help you. You can choose to walk everywhere but once the car becomes ubiquitous, why walk?

I definitely like it more than Python () and probably more than Typescript (the best non-niche scripting language available today). But there are some quite glaring holes and weirdnesses. In particular:

* The support for tagged unions (Rust style enums) is pretty nonexistent.

* `int` is 64-bit but not on the web. I totally get why they did that and hopefully they can fix it with wasm at some point but it's very annoying for interop with languages that have the full range of int types.

* As many many people have said, it's quite verbose to make dataclass style types.

But it still deserves to be way more popular than it is. It's basically what JavaScript would be if it was designed by someone with taste.

I don't understand why this language exists. It just feels like a promotion vehicle by someone at Google who had enough clout to then get it shoehorned in to Flutter. If they had gone with JavaScript they could've made the switch to TypeScript later on. I realise this is being said with the benefit of hindsight but Flutter would be in a far better place today I suspect.

It compiles AOT to native code and supports tree shaking. It also has JIT mode with hot reloading/restarting. It has sound null safety and is statically typed.

It's not a bad language. It just lacks some needed features. They'll probably get implemented over a span of a few years.

Ecosystem is small, but at least there's FFI interop.

It also has some baggage from it's early days when it was meant as JavaScript replacement. Since we now have WASM (and soon WASM-GC) I think it would be best, if compilation to JS would be dropped, so more low level features can be implemented.

> Ecosystem is small, but at least there's FFI interop.

FFI continues to be a disaster (to be fair, this is not unique to Dart/Flutter).

The biggest problem with any cross-platform system on mobile is always getting performance out of the native interop. It's often easier to ship a computation to a server on the web and ship teh result back rather than execute it natively on another thread on the bloody phone. It's infuriating. We have a zillion cores, and every single phone OS tries it's damnedest to prevent you from using them because, heaven forbid, you might actually use up some of the battery. The Horror! The Horror!

The cross-platform systems for phones are really good at doing puzzle games or CRUD. Step outside of that and you enter "Here Be Dragons" territory very quickly.

> It's not a bad language.

I agree. The team behind the language is the real problem.

> It just lacks some needed features. They'll probably get implemented over a span of a few years.

For years they have dismissed calls to add multi-threading in the language, despite it being sorely needed for anything computationally non-trivial (isolates have ridiculous overhead).

The language exists because of AdWords, they had recently migrated from GWT to AngularDart when everything fell down, regarding Chrome team jumping off the DartiumVM integration, eventually with all this process most key designers like Gilad Bracha, and Kasper Lund leaving the project.

When Flutter came around, for whatever reason they decided to pick Dart, the original prototype was in JavaScript (the official reason being it wasn't good enough given the language semantics), and Dart 2.0 effort started, with the language gaining strong typing (it was dynamic with optional typing in Dart 1.0), and AOT compilation support.

Dart is actually hands down one of the most productive languages out there right now in terms of ergonomics. It’s still a tiny language ecosystem at the moment but there are already a lot of happy paths that will get you to an incredibly high level of quality with very little work.

I really wish somehow Flutter or react native would be written in Rust or some other language on the same level. I hate having to deal with JavaScript or some half baked compiler.

Reply on news.ycombinator.com