Provide a justification for using this over the desktop embedder

miyoyo commented 4 years ago

I know that the embedder isn't ready yet, but that can't be used as an argument, since Flutter Web isn't ready either.

But, in addition to having to ship both the massive electron runtime, which is already easily 50MB, then adding the flutter runtime on top of that, easily 5MB, and you're already at 55MB minimum for hello world.

There is also a MASSIVE performance hit. Both because of having to use V8 to run javascript-compiled Dart, but also because skia isn't used directly to render the UI, but instead, JS APIs have to be hit, making the overall experience strictly inferior to the embedder.

Since this is the Desktop, there aren't any restrictions on what can be used or not inside of the app, so it's 100% possible to embed a JS engine inside of your flutter app instead.

From an outsider's point of view, It just looks like this combines the worst of Web Technologies and Flutter, with few of their upsides, so it's important to highlight the reasons as to why one might want to use this (or one might want not to use this, if this is just an experiment).

nmcain commented 4 years ago

Yeah this seems like a waste. I have had a lot of trouble getting the desktop embedder working though.

rodydavis commented 4 years ago

Well for one the ability to use js/html libraries on the desktop is huge. I understand that you can bundle it, but this has it by default. If you use firebase on Flutter web like me, then porting to desktop means i have to have a firebase sdk for mobile , rest api firebase wrapper for desktop and firebase web library on the web. Same plugin but 3 implementations for simple abstraction.

Also Flutter makes a good PWA on the desktop and on chromebooks works really well. If you want advanced features on desktop them embedding on the desktop is a better choice. but for those with lighter web apps this we would be plenty fine. Electron has also made a lot of performance improvements so it will continue to get better.

I have extensively used Flutter web and Flutter desktop embedding in at least 5 applications. They both have their flaws but it is nice to have options.

Until Flutter desktop embedding gets auto updates then the electron approach is really nice. There is nothing stopping you from releasing it with electron and later have an update that reduces the file size by Flutter desktop embedding.

There could also be a hybrid approach too. I think that the Flutter Web will get much more support than Flutter desktop embedding.

miyoyo commented 4 years ago

Well for one the ability to use js/html libraries on the desktop is huge.

You're using Flutter, not JS, not HTML, Flutter. Replacing the entire UI stack with another, abstract one is literally the point of Flutter. If you want the Web, use a browser, if you want to release a Desktop app, use an actual Desktop app. VS Code is probably the exception that proves that, carefully done, an Electron app can be good, but it's the only one I've ever come across. Meanwhile other webtech-based apps like Spotify eat CPU and RAM like nobody's business (Seriously, I routinely see people using more than a GIGABYTE of RAM for an app that plays music.)

And as I said before, embedding JS is just embedding a node engine, not an entire damn browser.

firebase sdk for mobile , rest api firebase wrapper for desktop and firebase web library on the web. Same plugin but 3 implementations for simple abstraction.

That's what plugins and method channels are for.

Flutter makes a good PWA on the desktop and on chromebooks works really well.

If you want a PWA, let the user install it with their own browser, bundling Electron is almost insulting their

Battery life
Disk Space
Responsiveness when you could just be using Desktop.

Flutter's performance doesn't magically get 100x better just because it's Electron and not Chrome, they're effectively the same thing.

Until Flutter desktop embedding gets auto updates

That's probably already doable, if the app isn't installed in a privileged folder.

I think that the Flutter Web will get much more support than Flutter desktop embedding.

Instead of using the obvious choice that is Desktop, that has vastly superior performance and both exponentially smaller files and RAM usage, you prefer shipping an entire browser because it has 2-3 more libraries?

I know people use the "it's faster to program with" as an argument with electron vs native, but it's not really an argument here, as we're talking about the exact same UI framework in the end.

rodydavis commented 4 years ago

Don't get me wrong, I use Flutter Desktop embedding now with apps. I have been since they let hot reload work with it. I really love the stability and performance.

That being said electron has been getting better, VSCode, like you said, is a good example, so is slack https://www.theverge.com/2019/7/22/20703458/slack-desktop-app-performance-improvements-windows-mac-features-download.

Something that you can do by shipping the browser is being able to render on the dom. Just like on mobile with Flutter you can use Webview or UIKitViews, this is so powerful for adding functionality. Google maps, for example, you can use it on mobile, and web.. but how would you use it on the desktop? You would need the dom to take advantage of the existing libraries. I have a very extensive app i have built with Flutter web and can build HTML/JS webpages, but this is only possible because i can take advantage of the dom and Nodes.

I have other flutter apps that work better with the desktop embedding, like a midi synth and also powerpoint creator for sheet music. These work great with desktop embedding because they can and usually are offline, need the resources for the rendering and Firebase is not used.

But i also use Flutter for Enterprise B2B apps and they need to have it updateable, match the website or close to it, and always online. Plus we render a lot of HTML emails and marketing pieces and also need the dom and browser support.

I say all this to say that it really comes down to the application and the needs it has. This is just an option, not the only option.

I will always try to build for the native platform as close as possible, but i also will be in favor of tech that is more supported. right now electron has a lot of traction because of the big companies behind it.

It is possible in the future for election and Flutter to work off of web assembly and then the code would we executed directly. I agree that with election Flutter can not draw on skia directly and maybe there are other ways around it. That should be addressed.

miyoyo commented 4 years ago

That being said electron has been getting better, VSCode, like you said, is a good example, so is slack

As I said, VSCode is an exception, the fact that slack even had to mention their performance, and spend so much time rebuilding their client speaks volume about Electron's performance.

how would you use it on the desktop?

Webview support isn't a new thing, and the desktop has been doing it for far longer than you might think. Active Desktop and many windows components are such examples, Qt has had a Webview for years.

But i also use Flutter for Enterprise B2B apps and they need to have it updateable, match the website or close to it, and always online. Plus we render a lot of HTML emails and marketing pieces and also need the dom and browser support.

Then use a browser, no need to worry about disk usage, upgrades, or even about the platform!

It is possible in the future for election and Flutter to work off of web assembly

WebAssembly isn't a magic trick that makes everything faster, it's just a compile target for any language to use in a platform agnostic way (Where have I seen that before? This time it's just on the web) It's slightly faster in some cases, sure, but it doesn't change the fact it's still being run by V8.

filleduchaos commented 4 years ago

No offence @hayderux, but have you considered that you don't in fact have to use Flutter for everything? It's a nice technology and all but twisting it into a position where it's straight-up worse than every available alternative isn't really the best use of time.

rodydavis commented 4 years ago

I disagree. This is still worth the time exploring.

filleduchaos commented 4 years ago

Oh it's certainly worth exploring in the curiosity sense, but if someone came to me looking for product advice I cannot think of a single reason to tell them to use this instead of just building their Electron app in JS (or even just plain Dart using dart:html) seeing as pretty much none of Flutter's strengths come through here.

RichLewis007 commented 4 years ago

Good discussion. One use for this repo is for a desktop app I need to send and receive data over the USB port as serial data, cross platform. I can get a Node.js library for serial communication to do this in Electron, but I can't find a Flutter/Dart plugin for this. I've found only Dart plugins for Bluetooth communication, as Flutter Desktop plugins are few.

nmcain commented 4 years ago

This is a great start for flutter web apps, but a pwa would be superior

rs5173 commented 4 years ago

Flutter Web + Electron may become more popular than embedded

Flutter embedded progress is very slow, plugin development is a very costly project, even if it is available (a cross-platform feature requires the native code to write three different desktops). At present, the Flutter team will spend more time on the Flutter Web, and relying on the powerful ecology of Node.js, you almost no need to pay attention to the development of plug-ins, you can find all kinds of existing plugin through npm. It’s easier to port applications to the desktop.

As for performance issues, Flutter Web is still in the preview phase, and with the release and continuous iteration, performance and compatibility will be greatly improved.

miyoyo commented 4 years ago

@luojieerr You can integrate Node inside of the embedder, but that's not even the issue here.

The problem with this repo is using Electron (Over 50MB, very high RAM usage) and Flutter Web (Which has to work around HTML/CSS/JS to work properly, therefore it will always be lower performance than native.) over using the Desktop Embedder directly, which has none of those issues.

Flutter Web, by definition, can't outperform or even match the Embedder, as, instead of directly telling Skia what to draw, it has to somehow do that using the limited APIs the Web offers.

rodydavis commented 4 years ago

High memory and Ram issues can be fixed. VSCode and Slack have both reached a solution.

If to help plugins you need node.js bundled then it should be bundled with the starter app. The flutter team will not focus on plugins for desktop and the community is not going to spend the time making the same plugin work for Mac/windows/Linux/android/iOS/web at most just iOS/Android/web

But if you want the best possible experience then use the embedded flutter. But for the vast majority of apps this would be fine.

miyoyo commented 4 years ago

You're assuming what the future holds, I wouldn't use those arguments.

VS Code, while one of the best electron apps, still has RAM issues, 150MB+ of ram to open a text file without any plugins isn't "A solution", it's just that VS Code is one of the rare apps to offer enough functionality for that not to matter. Slack is still a RAM hog for a simple chat app (237 MB when literally just opening a workspace and doing nothing).

And, again, the issue isn't Javascript, it's Electron. If you want to spit in the face of your user's resources, it's the fastest way, and, let's face it, VS Code and Slack are an exception built by companies that have dedicated weeks, if not months of work in order to make them performant. The average Electron app is still a disaster, and will never be fixed.

Stop ignoring performance for developper convenience, otherwise you'll end up with Etcher 2.0 (180MB for 2 DD commands, an sha256sum, and umount.)

AweiLoveAndroid commented 4 years ago

@miyoyo Flutter Web Beta can be used in the project now.So how to change to Flutter 1.12,can you solve this problem?Thanks.

jlcool commented 4 years ago

I hope that when the embedder is ready, I can directly transfer the code of flutter web + electron

Charlie9830 commented 4 years ago

For what it's worth. I have a justification for having to take this route, albeit it is a bit of an edge case. I am a single developer, building an app that relies heavily on real time updates, and thus, requires Firebase. I originally built this App in React and released it on Desktop via Electron and Mobile via a PWA. Unfortunately, due to reasons outside the scope of this discussion, the PWA platform wasn't quite cutting it for me. That was when I decided to start redeveloping the app in Flutter.

I began work on the Flutter Mobile implementation with the hope that by the time I was nearing completion, the Desktop shells would be at least at a point where I could start development, then eventually, release both the Mobile and Desktop versions together, under one codebase (or near enough to it).

Having one codebase and especially one language / framework is vitally important to me, developing is not my full time job. In fact my Full time job is in a completely different field. I just do not have the time or expertise available to manage multiple code bases across multiple frameworks / languages.

Fast forward to current day and Flutter desktop isn't quite moving at the pace I would have hoped. I am now nearing completion on the Mobile app, but the desktop shells aren't close to ready yet, and the general mood seems like the Windows shell won't be production ready for at least another year. That leaves me with a choice currently.

Option A

Rebuild the current React + Electron version of the app to bring it up to speed with the new Flutter Mobile version. Release both and manage two separate codebases, then, once Desktop is ready, and god willing Firebase release a Desktop SDK to compliment it. Migrate the Mobile Flutter code over into a Desktop shell and switch out the React + Electron version to the Flutter Desktop via an update.

Pros

~5mb lighter weight then Flutter + Electron (But really whats 5mb when Electron is already 50mb) initially. Then possibly lighter afterwards.
React obviously much more mature then Flutter Web.

Cons

Multiple codebases.
Longer time to market.
If Firebase don't release either a Native Dart SDK or a Desktop SDK, then I really am stuck. They have a C++ library but this is for Admin, not for client side. Implementing their REST API doesn't provide Real time updates.
Extra time lost bringing the React version up to date.

Option B

Migrate Mobile code into Flutter Web. Leverage existing Firebase JS libraries to achieve real time updates. Once Desktop shells catch up and if Firebase release a Desktop SDK. Transfer over to a Flutter Desktop Shell.

Pros

Quicker to Market.
Single Codebase (Except perhaps for some JS Binding)
Doesn't matter if Firebase don't release a Desktop or Native Dart SDK.

Cons

Possible performance issues if Flutter Web Performance doesn't improve.
Large download size.
Large memory footprint.

My choice currently is Option B. Perhaps, a feature for this quick-start would be an upgrade path for Apps in Production to supplant the Electron Runtime with the Production ready Flutter Desktop via OTA Updates so it would be near seamless for the end user. However I don't have enough experience in the field to know if there would be issues with Code signing.

Again I understand that this is indeed an edge case. But given the original question I ask, I still think it is valid.

Ofcourse I am open to discussion and suggestions should anyone have any.

rodydavis commented 4 years ago

@Charlie9830 I think that is a great use case. Really it comes down to the project and what works best for it. There are so many more plugins on web than desktop right now. And my unpopular opinion Is that with web assembly and wasi, mobile and web running on desktop becomes even harder to tell the difference.

It also depends on what type of desktop app you are building. If you are building a game, or graphics application that is a different story.

Don't feel bad about using electron. Just keep betting on Flutter!

jradxl commented 3 years ago

August 2020 I'm here reading this because sadly, the Flutter Linux Deskop as per Canonical's article doesn't really work.... https://snapcraft.io/blog/canonical-enables-linux-desktop-app-support-with-flutter It ends up with a package focused on Snaps that "have" to be published to their app store. The snap packaging uses the flutter plugin which in some way runs the bundle Otherwise one has to use, flutter run -d linux which does similar, but flutter run -d linux --release doesn't work. Perhaps this Flutter Linux Desktop is all to young at the moment.

nmcain commented 3 years ago

@jradxl You can use the SDK independently of Snap, and you can flutter build linux --release, to compile an executable bundle.

jradxl commented 3 years ago

Doesn't work for me, that's why I was looking here.

$ flutter build linux --release Building Linux application...
jradley@z390ma:~/Documents/programming/flutter/counter$ ./build/linux/release/counter embedder.cc (577): 'FlutterEngineCreateAOTData' returned 'kInvalidArguments'. Invalid ELF path specified.

(counter:59997): WARNING : 00:03:28.742: Failed to start Flutter engine: Failed to create AOT data

redfox-mx commented 3 years ago

@jradxl you could take a trip to my fork and watch. I've not tried with flutter snap support,t but it's in alpha stage. I think flutter web is a "better" solution cause is beta and have a little more official support by the flutter team. Also, @AweiLoveAndroid flutter beta is now available, some moths ago update the pubspec dependencies

miyoyo commented 3 years ago

@redfox-mx that comment about web beta was 8 months ago.

Whatever the case, web currently is still in a worse state than desktop, from the user's point of view, not because it's ignored by the flutter team, but because it's a much more complex technical challenge (desktop is literally just reimplementing flutter's front end APIs using glfw, gtk, cocoa, etc, while web requires a brand new engine, has completely different render semantics, has completely different memory and low level access models, etc).

redfox-mx commented 3 years ago

@miyoyo Not really, flutter web nowadays isn't a solution for any product that's the truth. I think flutter web has had much better growth than desktop. PWA and focus on canvasKit are some examples while desktop develop is slowly. For me, It could be a solution in future (or maybe not). I see something about PWA. Since I read it, I'm confused.

Note: I'm trying to find some integration with node js, but the best way is through a server with "GET" and "POST" methods. What do you think is the best way to make a "desktop app" at this moment?

hayderux / electron-flutter

Provide a justification for using this over the desktop embedder #1

Option A

Option B