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

171–180 of 322 posts

Re: Flutter desktop shells

#171

Post by [deleted] »

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

[deleted]

Re: Flutter desktop shells

#172

Post by networkimprov »

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…

And there's the "localhost web app", where the app relies on whatever browser is installed.

Jupyter Notebook does this.

https://jupyter.org/

Re: Flutter desktop shells

#173

Post by shalabhc »

mraleph wrote: post #163
GordonS wrote: post #151

Is it possible to work with Flutter using Typescript, or is it Dart only? It really feels like Typescript won the war to be something of a JS replacement a long time ago - I like the look of Flutter, but I really don't want to learn another language that I won't use for anything else. BTW, I realise Dart is likely similar to Typescript in many respects, and I wouldn't expect a big learning curve - but I already have…

> Is it possible to work with Flutter using Typescript, or is it Dart only? You might be thinking that Flutter underneath is using JavaScript - to which Dart compiles. However this is not how Flutter works, there is no JavaScript involved anywhere in the stack. Dart is its own language - and it can run natively, unlike TypeScript - which is just a type system over JavaScript and needs to be compiled to JavaScript to…

Random Dart question - how is the standalone Dart VM implemented? What is it written in, is there a bytecode, etc?

And is there a place where more details are available?

Re: Flutter desktop shells

#174

Post by [deleted] »

Kiro wrote: post #115
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.

What's wrong with null?

[deleted]

Re: Flutter desktop shells

#175

Post by leppr »

rubber_duck wrote: post #6
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'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…

> Dart feels like a better TypeScript

That's only if you use Typescript as a class-based OOP language. If you're more used to functional programming and prototypal inheritance, then Dart will bear no familiarity.

Due to its adherence to classical OOP, it feels way more like Java than Javascript.

As someone who never did any serious programing in those classical OOP languages, I struggled a lot to find the right abstractions to implement any kind of clean business logic. It was the first time I had to actually read up about "design patterns" and unironically consider writing factory factories.

It seems that due to Dart's rigidity and adherence to classical OOP, any library which needs to deviate from this paradigm has to hook into an additional build step (e.g. built_value for immutable types, has to use build_runner). That's an acceptable compromise for lib users, but adds a huge burden to actually writing those libraries, let alone incorporating those in your app's code.

Re: Flutter desktop shells

#176

Post by SlowRobotAhead »

Apocryphon wrote: post #140
stephenr wrote: post #136

Earlier quoted context omitted.

So, dart is safe until google moves onto the next thing it invents. How’s GWT looking these days?

It lasted for about eleven years which is not bad as far as frameworks go.

But this isn't a framework alone. It's a framework (flutter) and a language (dart). And at this point both are entirely dependent on each other, if I'm not mistaken.

Re: Flutter desktop shells

#177

Post by weberc2 »

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.

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.

Re: Flutter desktop shells

#178

Post by qwerty456127 »

> Work is ongoing to extend Flutter to support desktop as a target environment, allowing developers to create macOS, Windows, and Linux applications with Flutter.

OMG I wait for this so much... Finally a modern, high-level, really cross-platform JavaScript-free GUI framework...

Re: Flutter desktop shells

#179

Post by robmccoll »

skybrian wrote: post #105
robmccoll wrote: post #53

We finally have an answer to "how do I write GUI apps that work on all three major desktop OSes, both major mobile OSes and the web?" that isn't just run a web browser instance per application. Nothing wrong with Javascript these days, but it's hard to get consistency and the performance just isn't there. Something that compiles AOT and renders its own controls directly through OpenGL sounds great. Technically Qt can…

Well, no, we don't have it yet. Still in progress, no announced ship date.

Got me there. Hopefully "soon".

Re: Flutter desktop shells

#180

Post by munificent »

markdog12 wrote: post #90
lenkite wrote: post #64

Please let Dart compile to native executables on desktop OS'es

It already does, and they're working on making it easier. https://github.com/dart-lang/sdk/issues/34343 Not sure if this will use AOT or JIT though.

> Not sure if this will use AOT or JIT though.

You can do either. You can compile a snapshot and run that on the JIT VM. This basically gives you faster startup because it doesn't have to do all the source parsing, resolution, type-checking, etc. but gives you the general runtime performance of a JIT VM (think V8 or the JVM).

Or you can AoT compile your app all the way to native code. It's similar to how a shipped Go or OCaml works where it compiles your code and the language's runtime together into a single executable.

Post reply on HN