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

91–100 of 322 posts

Re: Flutter desktop shells

#91

Post by pier25 »

SlowRobotAhead wrote: post #55
rubber_duck wrote: post #6

Earlier quoted context omitted.

I've tried dart back in the Angular 2 beta days with Angular Dart and after using it I have the exact opposite feeling about it. It's a thing that solved a lot of very real problems that are still halfassed by NPM and Node ecosystem - package manager, build system, tooling around it - it was all a step above the quality of TypeScript/NPM/JS. Saner object semantics, good standard library, good tooling - it just got me…

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.

Re: Flutter desktop shells

#92

Post by neves »

jonny_eh wrote: post #25
tadzik_ wrote: post #13

Earlier quoted context omitted.

Sure it is, but I can see why OP looks down on it – just like their web rendering engine, it may be open source, but it's Google holding all the cards and ultimately making all the decisions. It may be opensource now while it's useful for them, but it may end up just like Android over the years: more and more closed bit by bit.

Is Google any worse than some "benevolent dictator for life" like other open-source languages?

Sure Google is worse. A BDFL usually started it as a personal project, has deep interest in making the software flourish in the most places possible. Google interest is their bottom line, and it will base their technical decisions.

Re: Flutter desktop shells

#93

Post by expliced »

StreamBright wrote: post #57
sbilstein wrote: post #7

Earlier quoted context omitted.

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.

Yes but there is also the question why don't I learn React, Rust or Clojure instead of Dart. Am I going to be better of knowing Dart?

Dart is based on js and flutter is based on react. Going from js+react to dart+flutter will not be that difficult. Learn both.

Re: Flutter desktop shells

#94

Post by skybrian »

Reedx wrote: post #79
grayrest wrote: post #70

Earlier quoted context omitted.

> is it going to last? Is it yet another thing Google will abandon? It's apparently the primary language for Google Ads. As such, I expect it to be maintained as long as Google continues to sell ads and if they do move away from it you'll have plenty of warning.

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.

Re: Flutter desktop shells

#95

Post by lostmsu »

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…

You should write a blog post with comparison!

Re: Flutter desktop shells

#96

Post by slantyyz »

Scarbutt wrote: post #82
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 hate using services and having my data all on some remote service w/ little options for privacy and safety/backup, etc. How would non-tech users handle backups?

By copying a data file to a USB flash drive?

Re: Flutter desktop shells

#98

Post by nradov »

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 everything else seems like a step backwards, or at best sideways.

Re: Flutter desktop shells

#99

Post by bryanphe »

frou_dh wrote: post #17
jasim wrote: post #8

I want to link to Revery - a native, cross-platform GUI library written in Reason/OCaml. It brings React's view=function(state) model to native applications, along with CSS box model and Flexbox. It has the developer ergonomics of Electron, but without the need for its heavy runtime. It is still under development and I'm looking forward to playing with it next time I try writing a GUI app. https://github.com/revery-u…

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 differentiation - because often people look at the framework and assume its JavaScript.

Do you have a suggestion on how to clarify this?

Note that, if you're interested in using the platform UI - there's a project called Brisk (https://github.com/briskml/brisk) that is very similar to Revery, but uses platform UI frameworks (Cocoa/Win32/etc).

Re: Flutter desktop shells

#100

Post by RandallBrown »

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…

Cross platform desktop app development will always fall short.

Not all platforms have the same user interfaces/paradigms. What is the Windows equivalent of the OSX dock? What is Linux's equivalent?

Most cross platform frameworks solve that kind of problem by letting you write platform specific code. The problem there of course is that you're just writing multiple apps again, often in a non-native or at least second class, language. (By second class I mean it's not what the OS authors intended their apps to be written in.)

Post reply on HN