Like with Unity, the power of cross-platform development leads many to just assume apps work across platforms automatically. This is absolutely not the case, you need to properly QA any code you write and code it to accommodate each platform's quirks.

I would not buy a screwdriver if a salesperson walked up to me, said "look how great this screwdriver is" and then the chair they were holding as an example immediately fell apart in their hands. There's a difference between a dev community building apps that perform badly and the actual platform advocates showing off apps that can't perform.

All the Flutter demos I've seen today are saying "Do you want your app to, at best, take a long time or even fail to load, feel like scrolling through molasses, break when you click a button, and spin text around at 25 fps like a 2005 Flash animation? Well, have we got a framework for you!"

I haven't seen one.

I like Flutter, but I don't think the Flutter Web design is very viable for production apps. It renders everything in canvas. Dart is already sluggish on native, and cross compiled to JS it's usually unusable.

I think Flutter will be a good choice for mobile and Desktop soon-ish, but for web ... maybe in a few years. Maybe.

ps: for me the Gallery is extremely laggy in Firefox, but works decently well on Chrome. Maybe wasm is enabled on Chrome only.

I strongly disagree re: Dart vs. TS, but then, I was a JS dev before I worked with Dart/Flutter, so probably a bit biased. But I think that is a very subjective statement, not objective.

I am really hopeful for it and am going to keep using on it for hybrid apps.

I try to just tell devs to try it, then judge it. Because it does seem weird up front, but it is such a nice experience for devs and can make great mobile apps.

Dart still does not even have union types, probably the best feature of TS. I would hold off on that claim for now..

But for me the main use for TS union types is to make discriminated unions, which is very useful wherever you have some form of a state-machine:

    type AppState =
      | { state: "loading", progress: number }
      | { state: "selecting_level", }
      | { state: "playing", level: Level }
      | { state: "success" }
      | { state: "failure", wantsRetry: boolean }
      | { state: "error", reason: string }

You can switch on that and the compiler will know what variant you're talking about, and it will apply exhaustiveness checks (ensures your code will handle all possible states)

    abstract class AppState {}
    class AppLoading extends AppState {
      final int progress;
    }
    class AppSelectingLevel extends AppState {}
    class AppPlaying extends AppState {
      final Level level;
    }
    ...

If you instead only cared about one case, you would be able to do:

    if (appState is AppPlaying) {
        doSomething(appState.level);
    }

The TS code indeed looks cool. This is an area we're looking at.

One point, though: we try to be very careful to not regress performance or developer iteration time (e.g., type checking time) when we introduce new language features. E.g., structural typing can be more expensive in general to type check since we need to recurse.

Have you considered not going full-on structural-typing but still providing some sort of union? In fact, you could go for one with even stronger guarantees, like the sum types in Rust or F#. (with Rust going as far as to call them enums too)

I'll admit I have the faintest notion on what causes that kind of complexity on a compiler, so my suggestion might be an even worse idea.

I work on Dart. The terminology gets really confusing here. "Discriminated unions" and "union types" are two quite different things, though they get a little blurry in TS.

The short answer is, yes, we're investigating pattern matching with exhaustiveness checking and making the language more graceful at expressing algebraic datatype-style code. The last half of that sentence sounds weasely because any object-oriented language can (except for exhaustiveness checking) model an algebraic datatype using subtyping. The parent comment using an abstract base class is how you do it.

So there isn't anything really fundamental that Dart can't express already. It's mostly a question of giving users syntactic sugar to make code in that style look more terse and familiar. I personally really like pattern matching and ADTs and I also particularly like multi-paradigm languages, so this is a subject close to my heart.

The language team has been pretty busy with null safety, but now that that's out the door (woo!), we can start working on the next batch of features, which with luck includes pattern matching. Here's an in-progress proposal:

https://github.com/dart-lang/language/blob/master/working/05...

Unless I'm mistaken, if one were to later implement a new class that extends AppState, all existing code would compile, but possibly fail or misbehave at runtime, unless you meticulously checked every place that tries to determine something based on those derived types.

In TypeScript, adding a new case for an union and not handling it everywhere is a compilation error on every incomplete usage site.

For example, try deleting one of the arms of the switch in this playground: https://www.typescriptlang.org/play?ts=4.2.2#code/C4TwDgpgBA...

I have to say, the default diagnostic isn't brilliant, but some tooling will give a better error and actually point out the missing arms, instead of complaining about the return type.

All in all, sufficiently analogous to not consider unions a missing feature of the dart language? Seems nice to have, but, maybe not very necessary. Especially if the only difference is whether it is considered an error by the syntax, or a warning by the linter.

Scala 2 also had `sealed` classes that could be used in places where you needed enums parameterized by runtime values and that's been generalized in Scala 3 IIRC.

But, in practice, a language's type system tends to optimize for the data structures that are idiomatic in the language. TypeScript is a heavily structural type system because idiomatic JavaScript often throws together unrelated types in this way (which makes sense when you're coming from dynamic types).

In a language that is built more strongly on objects and static types, it's less common to see APIs that "return one of these, or one of these, or on Sunday one of these things". So there is relatively less use for union types.

In other words, because people express unions at runtime less frequently in Dart (and other languages like Java and C#), there's less value in supporting them statically. Still some, definitely, but I don't think it's as critical of an omission as you might expect coming from TS/JS.

The "people use fewer unions in Java" argument is like saying people used fewer lambdas in Java 1.6. Build it, and they will use it.

I think you're confusing union types and sum types, which are very distinct features. SML, Haskell, and Rust don't have union types.

OOP languages can model sum types already. It's mostly a question of how much the surface syntax encourages that style.

I think _closed_ union types (the syntax `a | b | c`) are almost as good as sum types, since they bring exhaustiveness checking to the mix. They also act as documentation. Crystal is a good example of a language leveraging this feature.

The OO model of just subclassing a common class is quite poor by itself. Scala and Kotlin have a 'sealed' modifier to at least recover the exhaustiveness check. Both also have ways of safely doing the case switch on the object's class and simultaneously downcasting (Java too with its recent `match` construct, afaik). Does Dart have anything like that?

The natural OOP way to model an operation that must exhaustively be supported by a set of types is by making it an abstract method on a shared superclass. For problems where it's natural to keep the operations textually near each type, that works great.

Otherwise, yes, you'd ideally have some notion of a sealed family of types so that you can do case analysis with exhaustiveness checking. That lets you ensure all operations are covered when you program either in OOP or FP style.

Something I find odd is that FP folks often criticize OOP languages for not supporting exhaustiveness checking, but I rarely hear them admit that most FP languages don't have support for the other style that OOP does well, which is abstract methods.

- Scala has the whole OOP stuff - F# as well - SML: you probably need to do it by hand, with a record of closures, or something like that. It's ugly but it works. - OCaml has objects (it's in the name), first-class modules, or records-of-functions; all of which can replace abstract methods successfully. - Haskell can rely on typeclasses to do the virtual dispatch, I think. Not an expert on that.

So I'd say it might not be as ergonomic, but the capability is still 100% there.

my_type = my_list | my_object

?

You can see why this is better :-)

Big part of it is thanks to the community which is providing all the handy packages to add some native stuff easier (such as permission, localization etc.)

I agree with other comments that Flutter Web is not ready yet I've tried to build web version for wish list sharing based on Flutter and I was struggling, so in the end I've switched to Tailwind + Vue. Some issues I had was that website didn't behave like website. For example I couldn't select text with my mouse. It felt and behaved more like a mobile app through the browser.

For mobile though it works (almost) perfectly, my example of the mobile iOS and android app build with Flutter: https://wishpy.com/

Although it loads a bit long at the beginning and I still need to figure out how to show images and icons without an uncomfortable glitch at the screen start.