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

Flutter desktop isn’t there yet

plei.one

Post reply on HN
Print view View original

211–220 of 242 posts

Re: Flutter desktop isn’t there yet

#211

Post by synergy20 »

munificent wrote: post #199
synergy20 wrote: post #73

Earlier quoted context omitted.

same here,keep up the great work. by the way dart is my favorite cross platform language nowadays beyond flutter.

I work on Dart, and I'm glad you like it. I always like getting feedback from users. If there was something you could change about Dart, what would you pick? What would you keep just as it is?

the syntax is similar to C/java/C++ so the out-of-box experience was great, please keep it. I do hope there is a `dart build`(similar to `dart run`) to run pub-get-then-compile-exe as that's what Go and rust have, it's nothing major, just handy.

I use dart for scripting as well, which works really well.

For deployment I wonder if Dart can be made a little like Go (or C/C++): to build into a single static executable instead of depending on system C shared libraries.

I gave up on Go and embraced Dart, so the `dart build` and `static binary` are kind of what I missed from Golang when started with Dart.

Re: Flutter desktop isn’t there yet

#212

Post by pen2l »

munificent wrote: post #198
pen2l wrote: post #188

Earlier quoted context omitted.

Something being highlighted about Flutter is that it ultimately compiles to native code so unlike RN which transpiles to native widgets, its UI animations should technically be buttery smooth. But in watching the flutter announcement video https://youtu.be/Nu5m1FiS5X4?t=60 (timestamped link) on the screen as menus are opening and the mouse cursor is shown selecting different items, there is... a very perceptible stut…

There are a lot of levels of indirection here: * A video on YouTube... * Of a livestream... * Of a video made by a separate video production team... * Based a slideshow (probably Google Sheets)... * Containing a pre-rendered video... * Of a screen recording... * Of a Flutter desktop app. Any and all of those can introduce latency or lag in the video. It's a great form for showing users features, but probably not a gr…

On the one hand, ok... sure... on the other:

this just makes me think of the fact that this sort of thing would absolutely never fly at Apple. And I really, really want to say that is shouldn't fly at Google either. They're spending what, 400k on the median developer annually? Have standards, make them have some sense of responsibility and respect for their craft so they don't do this. I mean, like come on, one of the main value propositions for someone considering Flutter as opposed to RN is the fact that it isn't transpiled, there is thus an expectation for widget performance to be basically be similar to that of native code -- well, this is exactly where you proudly and loudly showcase this -- in an announcement video. Widget performance should be absolutely flawless in the presentations.

But all that said, no I don't think that's what's going on here. The things shown right thereafter are stutter free. I think this is a quirk with Flutter. While for mobile/desktop it compiles to native code, for web it does transpile to JS and I think that's perhaps what is being shown there. Though I would think if they wrap it in some sort of wasm the lag wouldn't be perceptible.

It just really grates me that in this day and age this is the reality of UI. If you'd told me 10 years ago that a simple menu shown in a major UI toolkit announcement by the main web player would have these kinds of problems I'd have assumed you were just bad at telling jokes. It also makes me sad because I want Flutter to succeed but seeing these kinds of missteps gives me a pause.

edit: I see now that you're a googler, I'd have phrased it differently if I'd known. Cheers.

Re: Flutter desktop isn’t there yet

#213

Post by c-smile »

2 cents from Sciter developer...

For the note: Sciter is an embeddable HTML/CSS/JS UI engine. For desktop and mobiles. By feature set it overlaps 96% with Flutter. It differs in ideology and implementation significantly though.

0. Dart

Not clear why Dart is used in Flutter. By architecture and feature set Dart is almost Java. Why the Dart then? My guess is this is an attempt to simply replace Java on Android without changing existing UI paradigms. Yes/No ?

1. Desktop-first vs. Mobile-first development

Desktop UI is windowed one - UI may consist of multiple desktop windows: frame, dialog and popup windows. There is also a concept of "kiosk mode" in Desktop UI - single window spanning whole screen.

Mobile UI is a windowless thing - UI canvas spans whole device surface. As you see Mobile UI is Desktop UI in Kiosk Mode - Mobile UI is a subset of Desktop UI.

Transition of large subset system to superset system is quite hard. On top of my mind I cannot tell any success stories of that. Anyone?

2. Separation of concerns

95% of UI development these days is a Web UI that uses three pillars: HTML as a semantic UI declaration, CSS as a style declaration of UI states and JS as declaration of event flows and UI state transformations. Essentially script is a definition (declaration, again) of flows/routes - how output of one native function is connected with input of other native function.

These three pillars, their purposes, are so different that their syntaxes should be different. Attempt to combine all these definition in single language is doomed to fail. If in doubts then look at WPF.

3. Notes on language-behind-UI...

If to consider #2 then such simple thing as JavaScript language and VM are quite adequate to the task. Language-behind-UI do not need to be that performant, but it must be flexible. I may express un-popular opinion but language-behind-UI should be typeless.

Simply put: don't do ray tracing in language-behind-UI. But! Such a language shall have simple mechanism of adding high performant functions. There are good languages that are specifically designed for performance: C, C++, D, Rust, Zig, WebAssembly, etc. You just need convenient mechanism to expose those functions to runtime of language-behind-UI. Like here: https://gitlab.com/sciter-engine/sciter-js-sdk/-/blob/main/d...

You need JITs, compilation, fat VMs and runtimes, strong types only if your language is the only mean to define algorithms in whole application. But expect that your code will always be sub-optimal - neither enough performant nor super flexible.

4. Conclusion

Flutter should be something Sciter-alike :) - use [X]HTML/JSX, CSS and some already well known language-behind-UI. JavaScript is the natural choice. If needed you should be able to use native UI components - like in Sciter you can use existing HWND based and windowless native components inside your UI. It may not follow Web UI model on 100% (that's impossible) but to be conceptually close so developers can reuse their skills. Web UI model is conceptually close to Mobile one - whole applications UI is constrained inside single window.

Re: Flutter desktop isn’t there yet

#214

Post by lern_too_spel »

miiiiiike wrote: post #140

If there's anything I've learned from using Google projects it's this: It's not going to get fixed. It almost doesn't matter what it is. If you've used any Google OSS project seriously you're going to come across an obvious defect and run to GitHub to open an issue. But, there's already an open issue for the problem.. And it's been open for almost as long as the project has existed. It will have an inscrutable priori…

You haven't really used a Google open source project unless you've filed a bug, had it assigned, had it automatically closed after months of inactivity by some PM cleaning possibly obsolete bugs, reopened the bug, rinsed, and repeated for a decade.

Re: Flutter desktop isn’t there yet

#215

Post by Andrex »

nomel wrote: post #189
phist_mcgee wrote: post #170

Earlier quoted context omitted.

The dreaded, 'closed due to inactivity' strikes again.

Every time I see "closed due to inactivity" implemented, the outcome is that new feature get added rather than fixing existing problems, because the memory of those problems only persists in the users day to day life. The developers have no useful record. But, I doubt that can scale. I imagine there's some happy place sitting near semi-automated "duplicate" recognition, and a voting system, to give the users a voice.…

This is why dogfooding is extremely important. You want the people making the reams to feel those 1000 papercuts.

Re: Flutter desktop isn’t there yet

#216

Post by Andrex »

buzzerbetrayed wrote: post #210
kitsunesoba wrote: post #125

Earlier quoted context omitted.

Having worked on projects for both mobile platforms with small teams, I find that cross platform UI frameworks only really make sense for somewhat simplistic apps. The more involved the app in question is, the more these frameworks incur overhead with the extra surface area for bugs to occur on which is multiplied by the number of supported platforms. The story on desktop is a little better but the same principle app…

I’m shocked they’re still using Dart. Even if Dart is good, it’ll still be what prevents flutter from being widely adopted

It's an obvious area for a PR boost if the chips are looking down.

I can see the HN headline now...

"Rust support added to Flutter [34,432 karma]"

Re: Flutter desktop isn’t there yet

#218

Post by munificent »

allenbrunson wrote: post #208
munificent wrote: post #199

Earlier quoted context omitted.

I work on Dart, and I'm glad you like it. I always like getting feedback from users. If there was something you could change about Dart, what would you pick? What would you keep just as it is?

i will start by saying i love dart. i learned it solely so i could make flutter apps. but now, three or four years later, i can say for certain that i love dart a lot more than i love flutter, which i have mixed feelings about. i've learned at least a half a dozen languages over the years, and dart is now my favorite. so much so that i am converting existing projects to it. for example, i have a series of scripts i w…

> my number one change would be to add configuration options to the formatting tool you wrote. i can see why consistency is a virtue for large projects, but for me, it is strictly a hindrance.

Yeah, I get that. In personal projects, there's something to be said for just Having It Your Way. But the formatter is focused on ecosystem level improvements where configurability is an anti-feature.

> my second big change would be to allow me to implement a big dart class in two or more implementation files.

You can sometimes accomplish that by moving chunks of methods out into seperate mixins and mixing them into your class. I think mixins are generally underused in Dart. But if that doesn't work, the proposal for augmentation libraries would probably help:

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

I'm glad you're enjoying Dart!

Re: Flutter desktop isn’t there yet

#219

Post by munificent »

synergy20 wrote: post #211
munificent wrote: post #199

Earlier quoted context omitted.

I work on Dart, and I'm glad you like it. I always like getting feedback from users. If there was something you could change about Dart, what would you pick? What would you keep just as it is?

the syntax is similar to C/java/C++ so the out-of-box experience was great, please keep it. I do hope there is a `dart build`(similar to `dart run`) to run pub-get-then-compile-exe as that's what Go and rust have, it's nothing major, just handy. I use dart for scripting as well, which works really well. For deployment I wonder if Dart can be made a little like Go (or C/C++): to build into a single static executable i…

> I do hope there is a `dart build`(similar to `dart run`) to run pub-get-then-compile-exe as that's what Go and rust have, it's nothing major, just handy.

It's "dart compile":

    $ dart compile --help
    Compile Dart to various formats.

    Usage: dart compile  [arguments]
    -h, --help    Print this usage information.

    Available subcommands:
      aot-snapshot   Compile Dart to an AOT snapshot.
      exe            Compile Dart to a self-contained executable.
      jit-snapshot   Compile Dart to a JIT snapshot.
      js             Compile Dart to JavaScript.
      kernel         Compile Dart to a kernel snapshot.

Re: Flutter desktop isn’t there yet

#220

Post by dmitriid »

satvikpendem wrote: post #162
dmitriid wrote: post #150

Earlier quoted context omitted.

It's open source the way Chrome is open source: the source is there, but the development is ~100% by Google

Not 100%, at least 30% of PRs are done by outside Google contributors.

How relevant are those PRs to the actual development of the product?

That is, fixing minor bugs or translation strings vs adding new web APIs etc.?

Post reply on HN