> but it's also the fastest way to support Mac, Windows, and Linux all at once.

Flutter exists too, and supports iOS and Android in addition to the desktop OSes. The dev time is pretty fast too imo.

That said, idk how the performance compares to Electron or Native apps.

As a small team, optimizing for "actually getting the thing shipped" is so much better than optimizing for speed anyway.

▲

wiseowise 7 hours ago | parent | next [-]

> Flutter exists too, and supports iOS and Android in addition to the desktop OSes. The dev time is pretty fast too imo.

Flutter is a joke on the web, and it consumes as much as Electron, sometimes worse, on a desktop.

▲

ifh-hn 7 hours ago | parent | next [-]

You got sources to back this up, or is this just you're opinion?

▲

moritzwarhier 7 hours ago | parent | next [-]

Regarding the "joke on the web", there's plenty of HN threads about Flutter where you will see this sentiment, not only about performance, also about UX (e.g. text rendering, selection, scrolling...).

I'm not sure if the web render engine has gotten better since then, and am too lazy to look up the links rn, but threads should be easy to find using HN search.

Still seems like a common source language + GUI toolkit that targets the web platform and various native platforms (mainly Android, iOS, macOS, Windows, and desktop Linux of course) without significant overhead has not been achieved yet. And it's questionable whether it's possible, given the special requirements (and capabilities) of the web platform and the different native platform.

	▲	satvikpendem 6 hours ago \| parent [-]
		Dioxus Native supports both web and native platforms because they serve HTML and CSS for the web and then on native they turn that into canvas rendered code just like Flutter, not a webview, because they built their own HTML and CSS renderer. For Flutter web, yes as it's canvas based it doesn't have all the same web features but generally for crud apps it doesn't much matter, especially if it's near zero effort taking your Flutter mobile and desktop app and putting it on the web. With the new impeller renderer and Wasm improvements it has gotten quite faster too.

▲

nxc18 4 hours ago | parent | prev [-]

Try using any demo app from their user showcase on web.

▲

satvikpendem 6 hours ago | parent | prev [-]

Where does it consume more than Electron?

▲

derfurth 7 hours ago | parent | prev | next [-]

In my experience performance is about the same as native on mobile. On desktop I cannot compare as I thankfully never had to make cross platform desktop apps using native platform SDKs, but Flutter is doing fine. I am a working on a non trivial desktop app, and I am pretty happy about it.

Hopefully the desktop story is going improve as Canonical is now leading the Flutter desktop side.

	▲	Zigurd 2 hours ago \| parent [-]
		I'm working on an app that's cross-platform on mobile devices. I do builds for macOS as a convenience for my colleagues demoing the app. Pretty much zero effort to add that as a target. I get some benefits out of it too in the form of being able to see how well the UI responds to unusual screen dimensions, running in a resizable window.

▲

satvikpendem 6 hours ago | parent | prev | next [-]

Flutter is great, still the fastest way to make cross platform mobile apps and you get desktop and web support essentially for free.

Performance is very fast as it's all natively AOT compiled machine code without any web views like Electron.

▲

greekrich92 5 hours ago | parent [-]

On desktop does flutter have native access to the machine it's running on? Can it talk to printers for example?

	▲	Zigurd 2 hours ago \| parent \| next [-]
		I have successfully added AppFunctions on Android to a Flutter app. I figure that's about as hairy a platform-specific feature as it gets. So far nothing has interfered with other platform build targets. I look forward to adding Apple's agentic tool calling interface, too.
	▲	satvikpendem 5 hours ago \| parent \| prev [-]
		Of course, via FFI. Not sure why one would think it couldn't, it's just a programming language based GUI framework after all.

▲

vips7L 6 hours ago | parent | prev | next [-]

Darts an amazing language too.

▲

pjmlp 5 hours ago | parent [-]

It is basically a revamped Java.

Google lost the opportunity to actually make it take off, had they replaced the Java stack with Dart, instead of staying in the Java world and adopt Kotlin.

However the Android team was never a great supporter from Dart in first place, hence why you won't find anything Dart on https://developer.android.com.

▲

Zigurd an hour ago | parent | next [-]

Google uses Flutter/Dart for their own apps fairly frequently. Obviously not the right choice for the most complex apps. Android system programming and cross platform apps are use cases that are divergent enough that trying to smash them together would result in nobody being happy about the outcome.

▲

vips7L an hour ago | parent | next [-]

Pretty sure AdWords is built on dart too

	▲	pjmlp 39 minutes ago \| parent [-]
		Of course, they were the ones that saved Dart in first place, after DartiumVM was killed. Having just finished moving from GWT into AngularDart.

▲

pjmlp 40 minutes ago | parent | prev [-]

Except for AdWords and Google Pay, which ones?

As far as I am aware, most teams would rather use J2Objc or KMM than Flutter.

▲

vips7L 2 hours ago | parent | prev [-]

They should have pushed dart instead of Go imo.

	▲	pjmlp 2 hours ago \| parent [-]
		Google never pushed Go, the UNIX/Plan 9 and Oberon folks did, as means to avoid doing C++, with support of their line managers as their 20% project. Kubernetes was originally written in Java, and Docker in Python, it was thanks to early Go advocacy, that those projects got rewritten in Go, and then they got lucky. Just like the download server rewrite into Go, that was done by someone from Go team, as part of their advocacy. Check how many public projects does Google do, outside anything related to CNCF project landscape.

▲

psychoslave 4 hours ago | parent | prev [-]

https://www.qt.io/development/qt-framework#platforms looks to comply with the stated specifications.

	▲	throwaway_95283 an hour ago \| parent [-]
		yes, but the unstated caveats for fastest are "i can't program, i only make CRUD apps" "i don't write anything that requires computation" "i do server side rendering on a serverless platform" in reality rails runs circles around typescript for productivity for CRUD/webapps.