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

221–230 of 322 posts

Re: Flutter desktop shells

#221

Post by GordonS »

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…

Ah, I didn't realise that - I guess that puts the kybosh on the possibility of Typescript :)

Re: Flutter desktop shells

#222

Post by mamcx »

pier25 wrote: post #193
mamcx wrote: post #145

Earlier quoted context omitted.

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?

Yes, the "novel" idea is the split in the actual binaries/languages: Do the core on rust/c and the render on swift/kotlin/.net...

Re: Flutter desktop shells

#223

Post by 0xffff2 »

ralusek wrote: post #146
0xffff2 wrote: post #112

Earlier quoted context omitted.

While VSCode is great in a lot of ways, it does not have good performance. What is has is adequate performance and great extension support. It regularly stutters quite badly on my beefy Dell Precision when running on the integrated GPU. I use it as my daily driver, but its performance pales in comparison to something like Sublime.

Have to compare to eclipse/intellij/webstorm rather than sublime.

I disagree. I use VSCode as a text editor, not an IDE. If I was going to stop using it, I would switch back to Sublime, not Eclipse/IntelliJ/whatever.

Re: Flutter desktop shells

#224

Post by devwastaken »

mottosso wrote: post #131
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…

> 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…

Python probably does eliminate a lot of problems of QT, much of its being the static typing of c++. However you are still bound by qt's internal widgets. Creating custom widgets requires reasoning about the renderer and qt's internal code.

The styling system of qt is also quite limited. Their 'css' is a small set that does not work well on everything.

HTML+CSS allows for creating almost anything, it's the same on all platforms if the renderer is right. It's seperate from code and easily viewable and debuggable within a browser program. I have yet to see anything similiar with Qt, or a style heavy program like Discord made in Qt without becoming spaghetti.

Re: Flutter desktop shells

#225

Post by Dig1t »

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 completely agree. I use Flutter a lot, and even after getting used to Dart, I really hate it. It's not a fun language, and I just can't understand why they chose to use it.

Re: Flutter desktop shells

#226

Post by zerkten »

mottosso wrote: post #131
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…

> 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 requirements then almost all other frameworks seem to have a fighting chance.

Re: Flutter desktop shells

#227

Post by weberc2 »

darpa_escapee wrote: post #199
weberc2 wrote: post #177

Earlier quoted context omitted.

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.

QML is a declarative language; it has curly braces like JS, but that's about it. It also allows you to extend it with (some old, possibly noncompliant version of) JS, but the declarative markup is a distinct language.

Re: Flutter desktop shells

#228

Post by mraleph »

markdog12 wrote: post #212
mraleph wrote: post #182

Earlier quoted context omitted.

Dart VM is written primarily in C++. There is bytecode, but the story here is kinda complicated - there are actually 2 different versions: one is called DBC and is used during development of Flutter applications on iOS, there is another called KBC - that one is more like a classical bytecode, it is currently in development. > And is there a place where more details are available? You can get some high level informati…

> there is another called KBC - that one is more like a classical bytecode, it is currently in development I haven't heard of this. Why another bytecode version? Increased performance?

DBC is an interesting beast, the way it was implemented in Dart VM was not like a normal interpreter (e.g. you interpret and then you tier up into JIT which generates native code), but kinda like a pseudoarchitecture. DBC tiers up into... itself. An optimizing JIT in DBC mode would generate optimized DBC bytecodes, not native code. This all kinda makes sense in the environment for which DBC was created - iOS, where you can't JIT. However in environment where you can generate native code this makes no sense - and even prevents you from reaching peak performance.

KBC is an experiment in this space where you have a more classical interpreter which tiers up into native JIT. In KBC mode bytecodes are also given to VM rather than generated internally inside the VM like DBC does.

Theoretically KBC should have better startup latency than just JIT (because you can start executing code immediately, rather than spending time to generate native code) and peak performance that matches JITs - because it tiers up into JIT.

Re: Flutter desktop shells

#229

Post by zerr »

kerberos84 wrote: post #137
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…

Is java Swing/FX not cross-platfrom ?

It's with-platform :)

Re: Flutter desktop shells

#230

Post by richardwhiuk »

frou_dh wrote: post #31
s_y_n_t_a_x wrote: post #27

Earlier quoted context omitted.

If Revery makes use of react-native-macos like ReactXP does, it does infact use Cocoa controls, unlike Flutter.

> Revery is like flutter in that it does not use native widgets. This means more work for us, but also that we have more predictable functionality cross-platform!

That's a bad thing.

Your apps are more predictable to developers between platforms, but less predictable to users.

A user expects all apps on their computer to behave the same. If you bring your own widgets, you violate that convention.

Post reply on HN