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

121–130 of 322 posts

Re: Flutter desktop shells

#121

Post by winter_blue »

nradov wrote: post #98
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.

In general it's just really disappointing that in 2019 the development frameworks we have available are still objectively worse in terms of developer productivity, reliability, and documentation than what we had with Microsoft Visual Basic or Borland Delphi back in 1996. I totally understand that these modern frameworks are superior when it comes to cross-platform compatibility and easy application distribution, but…

I learned Visual Basic 6 from a cousin when I was 8 years old. It was such a joy to use, and made me fall in love with programming. It was so intuitive to use as an 8 year-old. And while Dijkstra might disapprove, the Basic language of VB6 was really simple and easy to grasp as a kid.

The coolest part was distribution. Under the File menu, you had an option to build a .exe file. I would build it and put the .exe file on 1.44 MB floppy disk, and share my little VB6 programs with friends. Such wonderful memories!

Re: Flutter desktop shells

#122

Post by Hixie »

yunyu wrote: post #35
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…

iOS perf on Flutter has been broken for a while: https://github.com/flutter/flutter/issues/813 https://github.com/flutter/flutter/issues/28113 I wish the team would prioritize this more, but I guess that's Google for you.

We've done significant work on that particular issue in the past few months (primarily, caching compiled skia shaders). The issue wasn't iOS specific. If you have cases that are still problematic on the master channel (on iOS or elsewhere) please please please file a new bug with a test case so we can track down the issue.

Re: Flutter desktop shells

#123

Post by joshstrange »

sergiotapia wrote: post #109

Hot take: Who's to say Google's plan isn't to make this become big, then purposely give iphone a shittier experience just a few ms of more jank to make android look better? Think long, long term. I wouldn't trust this.

I don't know if they'd do that but Google does treat iOS users pretty shitty. Their apps are always a decent bit behind the upgrade curve. Like they didn't support the new iPhone X display for a good few months after it was released.

Re: Flutter desktop shells

#124

Post by weberc2 »

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.

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 don't have to manually manage your own memory or use their type system, but in practice you still need to understand how their types bridge to your language's types and how their memory management bridges with your language's memory management (typically a GC). So while you're dealing with C types and manual memory management less frequently, when you do have to deal with it, it's more complicated than dealing with it in standard C/C++. So (3) is hardly better than (2).

Electron is probably the most cost-effective option, but it has its own problems (notably the high resource consumption that comes from bundling a whole web browser).

With those considerations in mind, learning a new high level language is the least of all problems, especially if the GUI framework is high-quality.

Re: Flutter desktop shells

#125

Post by frou_dh »

bryanphe wrote: post #99
frou_dh wrote: post #17

Earlier quoted context omitted.

All these projects are trashing the accepted meaning of "native" GUIs. If it's not using, for example, Cocoa controls on macOS, then how is it native GUI?

"Native" is actually overloaded in the era of hybrid web apps - there are two pivots: - Native code - does the GUI framework compile to machine code? - Native widgets - does the GUI framework use platform widgets, or a platform agnostic layer? In the context of Revery, we used "native" to mean "native code", ie, "compiles to machine code" - and further clarify in the README. It's important for us to make this differe…

I dunno. Compiled -vs- Interpreted, and Desktop -vs- Browser seem like classic terms that gives 4 quadrants.

It's probably just Mac-heads that are particularly bothered by this topic, given that MS seems to create and sunset their native GUI frameworks fairly regular, and Linux has no single officially blessed one that everyone is attached to.

Re: Flutter desktop shells

#126

Post by beojan »

weberc2 wrote: post #124
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.

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.

Re: Flutter desktop shells

#127

Post by dodyg »

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.

This type of "why Dart" moans surface every time anything related to Flutter is announced. It's weird. Stop it. It's useless.

Re: Flutter desktop shells

#128

Post by moocowtruck »

skybrian wrote: post #94
Reedx wrote: post #79

Earlier quoted context omitted.

People keep saying that in Flutter threads, but it appears to be a small app for managing your ads? If it's just this, it wouldn't be hard to replace: https://itunes.apple.com/us/app/google-ads/id1037457231?mt=8 https://play.google.com/store/apps/details?id=com.google.and... Via https://flutter.dev/showcase

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?

Re: Flutter desktop shells

#129

Post by yunyu »

Hixie wrote: post #122
yunyu wrote: post #35

Earlier quoted context omitted.

iOS perf on Flutter has been broken for a while: https://github.com/flutter/flutter/issues/813 https://github.com/flutter/flutter/issues/28113 I wish the team would prioritize this more, but I guess that's Google for you.

We've done significant work on that particular issue in the past few months (primarily, caching compiled skia shaders). The issue wasn't iOS specific. If you have cases that are still problematic on the master channel (on iOS or elsewhere) please please please file a new bug with a test case so we can track down the issue.

I'm currently writing a test app that exhibits the issue on Flutter master, will get it to you guys shortly. This is already stated in the GitHub thread, but stuttering on open/app switch tends to happen with anything more complicated than a ListView with simple text content.

Re: Flutter desktop shells

#130

Post by 0x8BADF00D »

markdog12 wrote: post #84
danite wrote: post #61

Earlier quoted context omitted.

To me Dart is pretty disappointing. Modern languages like Swift and Rust have shown the power of incorporating functional features like sum types and pattern matching. Dart just feels like the same sort of OO language we've been getting since Java became popular. Edit: Also the continued existence of null in new programming languages is a baffling choice to me.

I don't blame you for being underwhelmed. The original goal was an easy to learn language. But since Dart 2.0 was completed, they are working on adding many other language features, including NNBD (Non-null by default). https://github.com/dart-lang/language/issues

It’s just hard to be productive in Dart. The Flutter IDE and simulators were so resource intensive, they literally locked up my laptop the last time I tried using them.

Dart is objectively a terrible language to be productive in for app development. The abstractions provided by the language are clunky to use for window elements on a device screen. Don’t get me started on Material Design, either.

Swift, Objective-C/C++, or even Java is way easier to start building apps with, in comparison. The tooling is mediocre for Dart as well.

Post reply on HN