Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Flutter 2

developers.googleblog.com

Post reply on HN
Print view View original

711–720 of 780 posts

Re: Flutter 2

#711

Post by saagarjha »

oscargrouch wrote: post #468
danShumway wrote: post #402

Earlier quoted context omitted.

I appreciate that building something that works even this well targeting Canvas must have been a metric ton of work, and I'm impressed. But that's kind of the issue -- it cannot possibly be more work to maintain a separate rendering/compilation pipeline for browsers than it is to rebuild the entirety of Chrome's DOM engine in WebGL for CanvasKit. I just don't see how Flutter is going to keep pace with "native" web ap…

Its nice to have absolute control of the rendering going over canvas if you are a flutter platform developer and i think even playing the catch-up game they should get there eventually. But i don't think this is the real issue here.. Flutter is more of a Flash and GWT lineage, and that's fine if that's what you are looking for. But i bet on the Web every time, its the most popular UI (and now much more) platform ever…

The price of infinite freedom in UI toolkits is that you get nothing for free. This has consistently been untenable: you quickly get stuck in the weeds reimplementing basic behaviors.

Re: Flutter 2

#712

Post by oftenwrong »

danShumway wrote: post #402
eseidelGoogle wrote: post #372

Earlier quoted context omitted.

[Flutter Eng. Dir. here] I really appreciate the feedback. We clearly have more work to do on the Web side of Flutter. Unlike the Mobile side which has shipped 100,000s of apps, the Web side may be up to like 1000. :) So many more issues to address as we work closely with more users to get their apps into production. If you'd like to track progress on any of these, I'd encourage you (or anyone else reading) to please…

I appreciate that building something that works even this well targeting Canvas must have been a metric ton of work, and I'm impressed. But that's kind of the issue -- it cannot possibly be more work to maintain a separate rendering/compilation pipeline for browsers than it is to rebuild the entirety of Chrome's DOM engine in WebGL for CanvasKit. I just don't see how Flutter is going to keep pace with "native" web ap…

It's disappointing the Flutter team members haven't addressed this justifiable concern about their big-picture strategy. I would really like to hear what they have to say on this.

Re: Flutter 2

#713

Post by saagarjha »

> Flutter allows you to handcraft beautiful experiences where your brand and design comes to the forefront.

This isn't strictly related, but can we instead make good, useful experiences that are consistent with the platform instead? I'm sick of companies making their app some lowest common denominator abomination to push their "brand"…

Re: Flutter 2

#714

Post by vsmenon »

axaxs wrote: post #358
vsmenon wrote: post #312

Earlier quoted context omitted.

[ disclaimer: I work on the Dart team ] It depends on how you run. Dart can either run in JIT mode or AOT mode. In general, when you ship a production app (e.g., for Flutter), you are using AOT - i.e., it's compiling to native machine code. In this case, there is no interpretation or compilation at runtime. We still bundle a runtime for garbage collection.

Which does 'compile exe' use? Essentially here is what I see - $ cat a.dart void main() { print("hello world"); } $ dart compile exe a.dart Info: Compiling with sound null safety Generated: /home/x/a.exe ~ $ strip a.exe ~ $ ./a.exe --version Dart SDK version: 2.12.0 (stable) (Thu Feb 25 19:50:53 2021 +0100) on "linux_x64" If I run without --version, it prints the same thing the 'dart' command does.

Thanks - not what I'd expect, but I can repro. Bug filed here:

https://github.com/dart-lang/sdk/issues/45197

It is AOT though. If you time `dart a.dart` vs `./a.exe` (pre strip :-), the latter should be considerably faster.

Re: Flutter 2

#715

Post by danShumway »

jug wrote: post #679
danShumway wrote: post #297

Earlier quoted context omitted.

The accessibility is a bigger concern, but flutterfolio.com also A) lags on my work machine when tabbing through fields B) doesn't handle HDPI screens well (the entire interface looks blurry) C) keeps fields visually indicated as selected even when I click outside of the browser (if I start typing, is it going to go into the field or not?) D) has a separate touch mode? Touch doesn't just work? Looked up another of th…

Strange how I don't see many of your issues on my side. (parent issue) Tab tabs through text fields only. A) No lag on my laptop B) Zooming to 400% reveals pure vectors for text as well as control decorations, even the fingerprint icon. Only the logo becomes pixelated but that one could of course simply be an SVG instead and not Flutter's problem. C) Yes, this is a common issue with web apps. One often needs to look…

Could be the browser/platform you're using? I'm not sure. I've seen some reports here that the demos work better in Chrome, but that's not exactly a point in Flutter's favor; this is supposed to be a cross-platform toolkit after all. Regardless, odd.

A) I'm on Firefox on a Mac Book Pro. My feeling is that should be able to handle a login form, but I mildly suspect that Flutter's dev team is not testing on Firefox at all.

B) Here's what I see when zoomed to 400%. No vectors anywhere, not even for text: https://i.imgur.com/7QFC40v.png Nothing that I see on the page is being handled as an SVG. Very strange to me that you're seeing vector graphics, as that would imply that the form isn't being rendered onto a Canvas for you?

C) This shouldn't be a problem with web apps that use :focus/:active CSS selectors. I understand if a from-scratch webapp doesn't handle focus loss, but I would expect any GUI toolkit to be able to.

D) On the web touch already for the most part just works. There's nothing on this login page that should require a separate interface. I think it's a problem if Flutter only provides adaptive interfaces "if you want them"; in a good GUI framework you should be getting the stuff that the web already handles for free regardless of whether or not you "opt in" to having your site work on an iPad.

Re: Flutter 2

#716

Post by hajile »

mixedCase wrote: post #537
lordgroff wrote: post #183

Earlier quoted context omitted.

Maybe it's just me but I don't remotely think JS is a bad language since es6. Tooling is another story entirely.

What other languages have you been exposed to?

I’ve used quite a few. What are the popular scripting languages to compare with? Python, Ruby, PHP are probably the only real competitors (disregarding others like VB or Perl).

Functional programming is very difficult in those languages due to weird closures, bad lambdas, weird block/proc/lambda rules, etc. async from the ground up means that concurrency story is much better and allows lots of threading (with libuv or whatever low level library handling the difficult parts).

JS used to have less ergonomic syntax, but has benefited from adding it last, so it usually chooses the best version.

Stability of JS is much better. When the implementation is the spec, there are bound to be lots of little breakages. Asa result, there’s not much room for alternative implementations.

Tooling is far better than any other scripting language. Debugging and introspection tools are second to none in the category. All these other languages have broken compatibility so that old software won’t run on new versions. Webpack gets hate, but what other scripting language bundles its output? Babel gets hate, but if Python had something similar, the v2/3 switch would have been no big deal and all the “I can’t use that because REHL doesn’t support that version yet wouldn’t be an issue either. Likewise, minifiers reduce download size, improve performance by removing and simplifying parts of the code and improve parse time, but other scripting languages don’t bother.

Type support via typescript is miles ahead of the competition.

Finally, performance is one or even two orders of magnitude better compared to other scripting languages (luaJIT being a notable exception). In fact, modern JS JITs can come very close to the performance of Java or even C in many cases.

JavaScript isn’t the end all, be all of programming, but it’sa very solid choice with good reasons to like it.

Re: Flutter 2

#717

Post by mixedCase »

hajile wrote: post #716
mixedCase wrote: post #537

Earlier quoted context omitted.

What other languages have you been exposed to?

I’ve used quite a few. What are the popular scripting languages to compare with? Python, Ruby, PHP are probably the only real competitors (disregarding others like VB or Perl). Functional programming is very difficult in those languages due to weird closures, bad lambdas, weird block/proc/lambda rules, etc. async from the ground up means that concurrency story is much better and allows lots of threading (with libuv o…

Have you tried Elixir or any Scheme? If the scope is dynamic languages, both put JavaScript to shame with much more power, useful tools and far fewer non-sensical footguns.

If the scope is programming languages in general, since it was stated that JS isn't a "bad language" after all, then you can include a long, long list of type-safe languages that are much better for dealing with both its role in the browser and in the backend. Elm, Reason, F#, OCaml, Scala, Kotlin, Swift, Rust, Haskell, to name a few.

Re: Flutter 2

#718

Post by technofiend »

OvermindDL1 wrote: post #521
technofiend wrote: post #173

Earlier quoted context omitted.

The app works fine although as of today it's still tagged Beta in the Google Play store, which may give some people pause. NFC on the other hand is so unreliable as to moot the use of Google Pay, which is unfortunate. I really prefer tap-to-pay over anything else, but not at the expense of making people in line behind me wait as I try various workarounds like toggling NFC. I realize there's nothing you can do about i…

Wait, is this why my tap to pay mysteriously stopped working in the past few months on my Pixel 4?!

Maybe? It's been in the press for a while now.

https://www.androidpolice.com/2020/10/26/tap-to-pay-issues-w...

The work arounds seem to be:

0 - Remove any skins / bumpers / cases from the device.

1 - Lock and unlock the device.

2 - Toggle NFC mode.

3 - Reboot the phone.

I've seen some speculation that on the Pixel 4 it could also be due to some flexing in the case. During a two week period where I couldn't find my wallet I spent a lot of time trying to make it work because of Chase's allowing tap-to-authenticate on their ATMs. Out of 100+ tries using those work arounds and several different ATMs (in case that was the issue) it worked once.

I ordered a tile for my wallet since I can no longer rely on my Pixel 4 as a replacement credit card.

Re: Flutter 2

#719

Post by mraleph »

axaxs wrote: post #118
bilal4hmed wrote: post #17

Earlier quoted context omitted.

Not like electron at all. It compiles down to a native binary for the OS.

Eh, it's a little murky. I was playing with dart a little. It can in fact create a single binary, but it looks like it's just putting the interpreter with the code. I say that because if you strip or pack the binary, instead of working it shows the output of running dart with no arguments.

[I work on Dart VM team]

`dart2native` just concatenates two binaries together: AOT runtime binary and AOT snapshot binary. AOT snapshot is an ELF binary which contains native code generated from your original Dart code.

The approach is not pretty but was chosen as an implementation shortcut.

That's why `strip` does not actually do good things to the binary.

There is no reason to run `strip` on such binaries - because they don't contain anything strippable.

Re: Flutter 2

#720

Post by sombersonder »

hnedeotes wrote: post #605
0xFluegel wrote: post #461

Earlier quoted context omitted.

> Looking now at the demos at https://www.qt.io/qt-examples-for-webassembly , a lot of the same problems are jumping out at me. A complete lack of accessibility features, poor handling of scroll events, large load times, unfocusable fields, lack of keyboard controls, etc... I found that hard to believe. But, clicking that link and trying the pizza demo... Yikes. It's not exaggerated at all.

Qt for WebAssembly: Pizza Shop Application exit (TypeError: undefined is not an object (evaluating 'handle[name]'))

May I ask what browser and version you ran this in? It does look dated but ran okay for me on Firefox 86 and Chrome 89.
Post reply on HN