Live data from Hacker News

Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

developers.googleblog.com

151–160 of 467 posts

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#151
post #97

Earlier quoted context omitted.

> You were a WWDC scholarship recipient, interned at Apple, and seem to base your career on Apple tech. I dabble in Android and Linux as well ;) > You are not a typical user, you will notice things most ordinary people would never think to notice. The vast majority of apps on a phone aren't even kept open by a user long enough for it to matter. Agree on both counts, but I like to think that users aren't completely cl…

I agree. Typical users aren't going to complain "hey this app doesn't feel native" or even know what that means! However, they will likely find it harder to use without an explanation why. If most of the apps a user uses follow the guidelines of Android/iOS, and they are primarily a user of one platform, and your app doesn't follow either, it seems obvious that they won't be able to use their built-up knowledge of ho…

I kinda wonder about this stuff. Seems like it depends on your user base and I'd like to see the user study.

Helping older relatives who find touchscreens to be disconcerting (due to mistaken touches that they don't instinctively recover from by hitting the back button), I think native look and feel doesn't go nearly far enough to make things easy to use, for some audiences anyway.

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#152
post #144

No one has (yet) mentioned the main reason I ignored Flutter when it initially came out and why I continue to have reluctance - It's google. They have a terrible track record with products AND with libraries. GWT? Dart (pre flutter)? NaCl? How about all those initial Angular devs? That's not a statement on the quality of the result (though some of those examples do indicate concerns), but if I'm not alone in avoiding…

What source would you prefer an open source UI library come from, that would avoid this concern? Open source software lives and dies with adoption. Starting off with a (paid) development team, marketing team, and large initial user base (google internal) puts a piece of software in a good starting position, but doesn’t guarantee success. Disclaimer: I work at Google, though not in a Flutter-related role.

Not the OP but I've quite a lot of trust in Microsoft when it comes to long term support and stability of their frameworks. They have their problems, but when they commit to something it's usually supported and stays around.

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#154

No one has (yet) mentioned the main reason I ignored Flutter when it initially came out and why I continue to have reluctance - It's google. They have a terrible track record with products AND with libraries. GWT? Dart (pre flutter)? NaCl? How about all those initial Angular devs? That's not a statement on the quality of the result (though some of those examples do indicate concerns), but if I'm not alone in avoiding…

GWT lived for over a decade (how many web libraries do you know that have survived for for that long?), AngularJS is still in maintenance mode, Dart died when it didn't get browser support and Typescript was obviously the better alternative. At the end of day though, I look at if Google itself is using it extensively, because that's when a library will have the best support/longevity.

Dart for the web may not be popular, but it's actively maintained [1] and being used by AdWords.

There was some Dart web framework churn before they settled on AngularDart.

[1] https://github.com/dart-lang/angular/commits/master

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#156

Earlier quoted context omitted.

I tested it, and the "Hello, World" example results in a 560k js package. Uglified and minified takes it down to around 480k. Gzip takes that to 140k and Brotli compression to 100k. That's a lot to bootstrap an app with, but it's not unreasonable, considering what most frameworks these days will start you with.

it's not just what goes over the wire. that's 560k of JS that has to be parsed and compiled, which is a shitload.

Yes, but it’s more or less in line with current single page apps. In fact, quite possibly a bit smaller.

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#157
post #2

Dart could very well end up being the secret weapon behind Flutter. Not only does Dart compile to JavaScript -- it's done this from day 1 -- but it also compiles to ARM binary via LLVM for iOS applications... meaning that compiling to WASM should be a trivial option to enable bringing near-native computational speeds to any targeted platform.

What's so impressive?

Kotlin compiles to about three times as many different targets already.

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#158

Love the concept, love the push. But to be sincere, won't touch it with a pole because of Dart. However,... Why o why is this thing not written with/for TypeScript?

They needed to work with a language team that's willing to modify the language to meet their requirements. Dart needed a killer app and was willing to work with them. The rest is history.

JavaScript was invented for similar reasons (though by one person).

Re: Flutter: a Portable UI Framework for Mobile, Web, Embedded, and Desktop

#160
post #44

Earlier quoted context omitted.

I have Flutter up and running on Windows 10 with the virtual Android device connected up and running my simple apps I'm playing with.

Are you using an Intel or AMD processor? Looks like some Bios config are specific to Intel.

I gave up. I have to run a VirtualBox VM for my work which means I have to have HyperV disabled, which means the Android emulators don’t work... also tried the arm images but no cigar.

I’m running a Ryzen CPU and I feel like that’s half the battle.

Post reply on HN