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

301–310 of 322 posts

Re: Flutter desktop shells

#301

Post by abalone »

gaara87 wrote: post #218
abalone wrote: post #29

I just checked out a couple of Flutter’s showcase apps on iOS. The scrolling in the Hamilton app was atrociously stuttery, just really broken. This is on an iPhone X. Then I opened it again and it was fine. Seems like it was doing some initialization work that was blocking the main thread. Not sure if it’s Flutter’s fault but I never see broken scrolling like that on native apps. The other app I tried was some journa…

https://n8.to/ that's a brand new app still in development, but I think it's worth seeing what it's capable of

Thank you, this is pretty, but it is also non-standard UI so it's not what I mean by a "native looking" app. I understand Flutter has some native-looking widgets so I'm curious how they work out in practice.

Re: Flutter desktop shells

#302

Post by marton78 »

sroussey wrote: post #149
mattlondon wrote: post #106

Earlier quoted context omitted.

Same here - its a real shame they picked a niche language for this rather than the now universal Typescript like everything else. As such, I'll pass since this feels like a dead-end just like polymer was. It felt like polymer had the same hype cycle as flutter - was going to make development so much easier/faster/less error prone etc. It is now a semi-abandoned legacy hulk of a project that people hate working with (…

You compile ahead-of-time (AOT) with TypeScript? Where can I get details on this?

https://github.com/AssemblyScript/assemblyscript

Re: Flutter desktop shells

#303

Post by pjmlp »

zerkten wrote: post #226
mottosso wrote: post #131

Earlier quoted context omitted.

> So (3) is hardly better than (2). As someone developing GUIs with Qt bindings for Python daily, and has been for the past 8-9 years, I respectfully disagree. Understanding of the underlying types and memory management is rarely an issue (e.g. once every 3 months), and when it is it's incredibly straightforward (e.g. maintaining reference to a window you've just created else Python garbage collects it for you). Topi…

Putting aside the many resource problems with Electron apps, can you achieve the level of user experience that the Electron folks do? I see Electron devs being asked to match the slickness of an existing website with similar delivery time and productivity. You don't seem to be able to get close to that with native APIs, API frameworks, or higher-level tools without a lot of work. When you remove these UI and delivery…

Easily with XAML/QML.

Re: Flutter desktop shells

#304

Post by pjmlp »

pier25 wrote: post #91
SlowRobotAhead wrote: post #55

Earlier quoted context omitted.

Ok, but to parent’s point... is it going to last? Is it yet another thing Google will abandon? Is it worth learning, because learning another language has a real cost imo. If Google walks at any point, does Flutter or Dart survive? I’m with him, I want to like the idea, but I think the adoption has been slow and it doesn’t appear like it’s going to suddenly take off. I could be wrong, I just don’t see any successful…

AFAIK Flutter will be the primary SDK for writing apps in Fuchsia. If this is true, and if the other rumors about Fuchsia replacing Android are also true, then I doubt Flutter and Dart are going anywhere.

Not at all, Fuchsia has evolved for a pluggable UI via Scenic.

Re: Flutter desktop shells

#305

Post by pjmlp »

IshKebab wrote: post #257
kitsunesoba wrote: post #167

Earlier quoted context omitted.

Indeed, Flutter would be much more compelling if I could use it with Rust or Swift instead. Dart really doesn’t interest me.

One nice think about Dart I've found is that compile times are very fast (faster than Go) and when editing in VSCode the code intelligence is instant and 100% accurate in my experience. Compare that to Rust where compilation speed is almost as bad as C++, RLS is slower than e.g. Qt Creator's clang lints, and has auto-completions so innaccurate that they are almost worse than nothing. Buuut.... I wanted to make a deep…

Surely not faster than Delphi, oh well.

Re: Flutter desktop shells

#306

Post by pjmlp »

spaceheretostay wrote: post #62
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.

I'm personally excited about Flutter largely because it seems the preferred development environment for Fuchsia. People will complain that Google kills projects too soon and too often, but I feel like Google has an MO and when you figure it out you can guess which products will live and die. I think Fuchsia and Flutter are Google's primary likely plans for the future of their consumer platforms. I don't really know w…

Sorry to disapoint you, Flutter is now one option in Fuchsia among others.

Re: Flutter desktop shells

#307

Post by avinium »

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.

As someone in the process of picking up Flutter/Dart, the upside of Flutter significantly outweighs the downside of learning Dart.

Flutter is the best-designed framework I've encountered (whether mobile, front-end, back-end or machine learning).

The only downside is Dart, and while it's annoying, it's also very minor.

Re: Flutter desktop shells

#308

Post by avinium »

GeertJohan wrote: post #77

Shameless self-promotion: There's also https://hover.build , which builds a Go binary that runs the flutter engine to run your app. Can be used to easily deploy a Flutter app on desktop, and allows for cross platform plugins written in Go. It works, but is in early release. It is based on https://github.com/go-flutter-desktop/go-flutter

This looks awesome! I don't have any pressing need to develop on the desktop right now, but if and when we do, I've bookmarked Hover.

Re: Flutter desktop shells

#309

Post by tuarua »

csells wrote: post #153
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…

I'm the PM for the Flutter developer experience. I'm currently digging into the next steps for our desktop experiment with Flutter and I'm very interested to hear how your xplat desktop app dev options fall short. What do you need from an xplay desktop app dev framework and toolchain? Chris Sells csells@google.com

The closest comparison I have to Flutter is Adobe AIR which I use extensively (scoff all you want).

The premise is very similar (non-native UI on OpenGL/DirectX surface, AOT compiled language, C++ based runtime, near native performance) I would go so far to say Flutter is heavily based on AIR.

When I ran the current Flutter-desktop demo it appeared to have the stability and feature-set of AIR 1.0 beta which was released in 2008 (It is now v32.0 as of 2019). It's a great jumping off point but I don't necessarily understand the hype when I am seeing something I saw 11 years ago.

Features I would expect Flutter Desktop to provide to match AIR.

- Hardware accelerated Video

For multimedia apps

- WebView

This may seem counter-intuitive but a chromium/webkit based webview component is a must.

- read/write/delete access to files in the app's sandbox.

- saveAs, filePicker dialogues

- Multi window support

- Toast/Notification Support

- Extensibility

AIR has a C lib and header for passing vars between the AIR context and the native plugin. This means the conversion has limited overhead. We can pass bytearrays, bitmapdata and even call methods directly on the AIR vars from within native code.

Being limited to using JSON across the bridge is not ideal, as there is conversion overhead and also you lose type safety.

I have added bindings for Swift, C#, Kotlin in recent years for building plugins with these more modern languages. It also allows building extensions in .NET and not being restricted to C.

References

https://github.com/tuarua/WebViewANE

https://github.com/tuarua/FreSharp

https://github.com/tuarua/Swift-IOS-ANE

Re: Flutter desktop shells

#310

Post by Kiro »

coldtea wrote: post #118
Kiro wrote: post #115

Earlier quoted context omitted.

What's wrong with null?

A null is not a string or an integer or a MyClass instance, etc. So why does it pollute variables of all those types? https://medium.com/@hinchman_amanda/null-pointer-references-... https://www.infoq.com/presentations/Null-References-The-Bill... https://www.quora.com/Why-was-the-Null-Pointer-Exception-in-... https://www.lucidchart.com/techblog/2015/08/31/the-worst-mis...

Thanks. Stupid question but consider the following:

  entity = Entity.fetch(id)
  if (!entity) doSomething()
Entity.fetch returns null if it doesn't find anything. How would this work without null?
Post reply on HN