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

Flutter desktop shells

github.com

Post reply on HN
Print view View original

191–200 of 322 posts

Re: Flutter desktop shells

#191

Post by s_y_n_t_a_x »

stu_k wrote: post #138

Flutter looked great, until I realised that they were re-implementing all the OS controls themselves. For example: https://github.com/flutter/flutter/blob/1db5d66932b873e17c8c... This is the kind of thing that leads to an "uncanny valley" app, where things feel slightly off, or they look good until the OS changes something and Flutter doesn't keep up.

That's why ReactNative is my preference. There are forks of it that target Windows and MacOS using their native controls. Microsoft maintains the Windows ReactNative fork (https://github.com/Microsoft/react-native-windows) and they wrap React, ReactNative, and the desktop forks in their ReactXP project.

I don't trust Google to emulate a perfect UI among all platforms. I feel like they're generating too big of a workload for no reason, it's a big red flag. I think eventually they'll give up on emulating native controls and choose a unified appearance for all platforms (forcing Material design for everyone) as well as giving the option to customize. I think their endgame is to push Flutter as much as possible so they have Fuchsia developers, then let the other target platforms go unmaintained. Their language, their OS, their devices.

Re: Flutter desktop shells

#192

Post by rat9988 »

beojan wrote: post #126
weberc2 wrote: post #124

Earlier quoted context omitted.

Context: I was a Qt developer in a past life. The alternatives for cross-platform GUI are 1. Electron 2. Frameworks like C++/Qt C/Gtk 3. Bindings to (2) Using frameworks like Qt in native C++ sucks because C and C++ are just terrible languages for GUI development, even with the bolted on object systems and language extensions (Qt extends the C++ language). Using bindings to those frameworks is nice in theory because…

You've completely ignored QML / Qt Quick here. That 's the actual best option. Though Qt Widgets in C++ isn't too bad if you use the designer instead of insisting on doing everything in code.

I heard that qml/qt quick had worse performance.

Re: Flutter desktop shells

#193

Post by pier25 »

mamcx wrote: post #145
wellpast wrote: post #74

Every so often for the past several years I'll go evaluate options for cross-platform desktop app development and I always come back with an enormous handful of options and all of which fall short on some measure. I would really think that this "problem" would have a great solution by now. But I think most of the developer attention is on web for obvious reasons (more ease, more conducive to mistakes/novices/etc). Ho…

As I write in https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_wh... I think the solution is to split in 2: A UI back-end with logic, layout, etc and a UI front-end renders in each UI native toolkit. So when write Button(title="hello") is NOT a widget, but a struct with data. It must be pushed to UI.Coccoa.render(button) to show up. But not only that, is possible to say: Form when(toolkit=UIKit) Field(UILabe…

So controllers and views?

Re: Flutter desktop shells

#194

Post by skybrian »

moocowtruck wrote: post #128
skybrian wrote: post #94

Earlier quoted context omitted.

Not just mobile. Dart (though not Flutter) is also used by the AdWords web app, which is quite enormous. That said, Adwords used to be written in GWT. It's not impossible to migrate, but quite a big job.

right but the money maker of adwords is not in dart at all, common lisp i think?

I don't know what you mean? Google has many large ad customers who use the web UI to manage their campaigns.

Common Lisp was rarely used at Google when I was there, though it's a big company and you do see a little of everything, sometimes due to acquisitions. You might be thinking of ITA software, which is (was?) used for airline reservations.

Re: Flutter desktop shells

#195

Post by munificent »

mixedCase wrote: post #186
munificent wrote: post #157

Earlier quoted context omitted.

Hi, I work on Dart. > functional features like sum types and pattern matching "Functional features" means different things to different people. Dart (like most modern languages) has a lot of the core functional features: first-class functions, closures, lambdas, higher-order functions. Our built-in collection libraries are heavily oriented around functional-style transformations. You don't need an external library to…

> It makes some kinds of code nicer, but doesn't significantly affect the expressiveness or capability of the language. Sum types and exhaustive pattern matching aren't about expressiveness, they're tools for aiding code comprehension by increasing the locality of code that has no business being distributed into completely different classes, and decreasing the cost of making changes by heavily reducing the amount of…

> they're tools for aiding code comprehension by increasing the locality of code that has no business being distributed into completely different classes

That's true for some kinds of code but not others. This is the classic Expression Problem [0]. For some things, it makes sense to keep all of the code for a single operation together. For others, it makes more sense to keep all of the code for a single datatype together. ML-style languages optimize for the former, and object-oriented languages optimize for the latter.

In practice, for the kinds of code Dart is designed for, the latter is a better fit most of the time. There's a reason OO and UI have been married together for decades.

Ideally, a language provides both styles so you can choose the one that fits your problem best. You see that now with languages like Scala. I hope we get there with Dart too.

I don't think it's fair to say that subclassing and method dispatch is objectively wrong just because it's a bad fit for some kinds of code. (Though, naturally, if it's a bad fit for the kind of code you need to write, then an OO language might be an objectively bad choice for you.) Class-based method dispatch is annoying for some things (God knows I've written enough Visitor pattern implementations over object-oriented AST class hierarchies), but it's really beautiful for others.

Being able to define a new widget class that bundles its rendering and interaction behavior together and can seamlessly extend a UI framework is something so natural that we take it for granted, but is very difficult to express in a language like SML. In fact, in order to do it, you'll probably end up doing a "design pattern" that reimplements something like v-tables at the application level.

[0]: http://journal.stuffwithstuff.com/2010/10/01/solving-the-exp...

Re: Flutter desktop shells

#196

Post by xster »

stu_k wrote: post #138

Flutter looked great, until I realised that they were re-implementing all the OS controls themselves. For example: https://github.com/flutter/flutter/blob/1db5d66932b873e17c8c... This is the kind of thing that leads to an "uncanny valley" app, where things feel slightly off, or they look good until the OS changes something and Flutter doesn't keep up.

I'd definitely a concern and non-ideal for things that are not spec'ed out in https://developer.apple.com/design/resources/. Hopefully this is all temporary until we can build our own comparison tooling https://github.com/flutter/flutter/projects/9#column-3989168.

Disclaimer: I wrote that line :(

Re: Flutter desktop shells

#197

Post by cbhl »

yc-kraln wrote: post #3

I really want to like Flutter, but I someone really don't want to spend the time to learn Dart. I can't really quantify it--some mix of yet-another Proprietary Google Technology, yet another ecosystem, yet another X. I'm tired I just want to build stuff that solves problems.

One of the things I love about React and React Native is that it's possible to use them from "plain old JavaScript" (React.createElement and friends). And I work at le Goog; my org has mandated Polymer 2+TypeScript for all new desktop web code.

Sure, maybe in production you want to use JSX and/or TypeScript, but learning a new language and a new framework together is overwhelming, period. Pedagogically, it makes it hard to conceptually separate what is a language feature and what is a framework feature. (To this day, I still have trouble separating what parts are Ruby and what parts are Rails.)

Re: Flutter desktop shells

#198

Post by rhodysurf »

skinnyasianboi wrote: post #33
est31 wrote: post #23

Earlier quoted context omitted.

So what's your alternative? Java Swing? Proprietary Sun (now Oracle) technology. Qt? Proprietary Trolltech tech. Electron? You're back on square one of using Google technology. And winforms, WPF, application kit, etc are all far more proprietary than Flutter.

Kotlin native/multiplatform projects is the answer

Its not though.. the only IDE is CLion which does not have a free version. Thats a showstopper for a lot of people.

Its also pretty slow compared with other native solutions.

Re: Flutter desktop shells

#199

Post by darpa_escapee »

weberc2 wrote: post #177
beojan wrote: post #126

Earlier quoted context omitted.

You've completely ignored QML / Qt Quick here. That 's the actual best option. Though Qt Widgets in C++ isn't too bad if you use the designer instead of insisting on doing everything in code.

QML is in the category of "learning a new language", although last I tried it it was very much a work in progress. Can't speak to how good it is today.

Last time I played around with QML, it was basically Javascript.

Re: Flutter desktop shells

#200

Post by Barrin92 »

sbilstein wrote: post #7
yc-kraln wrote: post #3

I really want to like Flutter, but I someone really don't want to spend the time to learn Dart. I can't really quantify it--some mix of yet-another Proprietary Google Technology, yet another ecosystem, yet another X. I'm tired I just want to build stuff that solves problems.

If you are handy with Java, Typescript or Javascript, Dart is a breeze to learn. I didn't invest any time learning Dart to get productive with it while using flutter.

Same here. it feels like a very generic algol family language, and if you're familiar with any of them it's almost trivial to pick up to the point where you can just sort of write it and figure things out as you go.

That was in fact the most pleasant things about Flutter for me, the language was a non-barrier.

Post reply on HN