Desktop app

[Zackaryia]

GrayJay not being on desktop is a bit frustrating and limits its usability. I propose that for a future desktop app be built. The best way to do this will most likely be some HTML based desktop app platform to enable easy porting to Mac, Linux, and Windows as well as web if wanted and Android + iOS. The most popular web framework is Electron however many people don't like its sluggishness and usage of JavaScript however it is still a great platform. Another excellent option is Tauri a rust based web application platform that uses the devices rendering engine rather than shipping its own improving speed and size. However this has the cost of requiring you to rewrite GrayJay in another platform, but this cost must be paid at some point if GrayJay is to be published on other devices, and might as well pay this before GrayJay gets too complex to do so. Considering HTML's ubiquity and Rust's religious community as well as GrayJay's love, PRs will be more frequent on this kind of platform thereby lightening the development load on FUTO devs.

Thanks for the consideration, hope to see GrayJay on my Desktop soon!

[spikespaz]

If you must cave to the trends and use HTML+CSS, then Tauri would be acceptable. I just don't want to see it turn into a bitrot mess from excess use of JavaScript, and unpackageable because of NPM.

I would prefer to see this app migrated to Flutter, so that you have a common codebase (backend Java, frontend Dart).

That would be a better option than GTK as that is barely cross platform. Qt would also work, but the devs probably don't want to do that.

I support the use of Android native UI for the mobile app, I think FUTO did a really good job with that. But it might bite them in the behind, because it isn't cross platform.

I just don't want to see any embedded browser problems or weird React Native stuff.

[Zackaryia]

Flutter is also a great platform, my only minor gripes are that its website exports are rough due to their usage of canvas rather than DOM. Also Dart isn't as widely known or ubiquitous as HTML + CSS is so there is a greater barrier to entry. This is not to detract from flutter its still an excellent tool.

As for large JS and NPM modules in Tauri you can choose how much or little JS you want to use so it doesn't require huge usage of NPM. Although it does require using Rust which has its own set of pros and cons.

All in all both are great tools I just want to see GrayJay on more platforms and more devices than just Android phones.

[martin-braun]

My biggest concern with NewPipe, and now with GrayJay, is the fact that my subscriptions will not carry over. I love the attempt, but the lack of synchronization between desktop and mobile is a deal breaker for me.

[Bluscream]

My biggest concern with NewPipe, and now with GrayJay, is the fact that my subscriptions will not carry over. I love the attempt, but the lack of synchronization between desktop and mobile is a deal breaker for me.

Just use any cloud storage provider or set up your own and regularly export your subscriptions

[martin-braun]

@Bluscream But how to import on the Desktop, what client to use? I use Syncthing so syncing itself is not the problem, it's the data format is not compatible with each other.

[spikespaz]

"Just export all the time"

Oh man

That's why I don't use NewPipe.

[Bluscream]

@Bluscream But how to import on the Desktop, what client to use? I use Syncthing so syncing itself is not the problem, it's the data format is not compatible with each other.

Well, from what i know, piped and invidious support uploading subscriptions and playlists as json https://yt.minopia.de/subscriptions

[Bluscream]

My biggest concern with NewPipe, and now with GrayJay, is the fact that my subscriptions will not carry over. I love the attempt, but the lack of synchronization between desktop and mobile is a deal breaker for me.

with the way grayjay has integrated auth services like harbor, etc. it would be easy to provide cloud syncing and have other services like invidious get the synced data through OAuth

[RealBeepMcJeep]

+1 on this, also requiring some sort of sync (preferably decentralized/locally hosted, client-side encrypted) to be useful to me personally. Am tempted to put a bounty on it.

Thoughts based from previous experience:

1. Really would want it to share a significant portion of code with the Android app. Wouldn't really be worth it otherwise because it's going to be 10-20% of your paying users probably. Effort needs to match 80-20 rule (80% of effort/time/expense for 20% of user demand is common and a big pitfall to be avoided).

2. Tauri is a fine choice. Purposely limiting libraries (npm) would be a good policy; maybe "statically" link any packages (non-minified) in the project rather than depend on a package manager, keep them small and auditable.

3. Flutter might also be a decent choice but would require a possible rewrite on the Android side, which would more than likely be an unacceptable undertaking.

4. Tried running GrayJay's apk in WSL with no luck. Crashed immediately. Although I might be doing something wrong. That seemed like a potentially "easiest" path.

5. The sync (at least cross-platform) might be something held behind the license to use any "GrayJay hosted" solutions (with an option to self-host). Just a thought; might put the project down a path that it shouldn't go down though. Client-side encryption is an absolute must to avoid any possible pull towards the dark-side (selling user information/activity), think ProtonMail.

[Zackaryia]

For syncing Syncthing is a great project that already exists and is wonderful for syncing from / to Android, and any PCs. It just lets your devices discover each other and lets them send files to each other so the server does not get any files or data. The only possible problem is that Syncthing syncs folders and if there are 2 conflicting updates at the same time there could be issues, but other than that it would work great. A paid option that maybe has an encrypted cloud stored copy of the data can be interesting but I think supporting Syncthing as the primary syncing tool would be a great idea as it is already a great tool that has tons of features and investment into it. Don't reinvent the wheel.

Also even though only 20% of the current user base may use the desktop client, there are tons of people that aren't using GrayJay because it has no desktop client. iOS users could also be a large market to spread GrayJay to but that seems like a less important market than desktop. Nonetheless Tauri or Flutter would make an iOS port 1000x easier.

[KristijanZic]

This app should really port to Flutter or at least go with Flutter for a Desktop/iOS client. It would be one codebase and it would be very performant. What I'm scared of the most is that they'll go with Electron/React and basically kill the project. With React/Electron Linux support would be very difficult so there probably wouldn't be any :/ Tauri also looks promising but for right now and forceable future I'm of the opinion (for what it's worth) that Flutter would be the best option as they can easily integrate the existing Kotlin and Java code and bring it to all platforms.

[martin-braun]

@KristijanZic Who decides that it has to be Flutter? Although Flutter has great performance and offers a coherent experience it also comes with a lot of trouble. Flutter causes a dependency hell, it's constant work to keep those updated, you can't sleep. Flutter also doesn't render a true DOM, which is annoying if you want to offer a website eventually as well.

Although I'm not a fan of React either, React Native would be worth considering. Its desktop targets don't suffer from a WebView and you still render a true DOM when you target the web. On top of that, you can target all platforms natively from one codebase.

[KristijanZic]

@martin-braun I would hope the developers that are going to work on it would decide. and if it's Flutter I'd definitely want to get involved (simply because that's where I'm better at) :)

Flutter causes a dependency hell, it's constant work to keep those updated, you can't sleep. That's just false, I've moved from ReactNative to Flutter mostly because of the dependency hell that I couldn't sleep over. The amount of transformations that your TypeScript or JSX code goes trough just to become javascript again alone is a dependency hell in React.

It doesn't need to, if you are going to build a cross platform app which is required by this project because the whole idea is to store your own data on your device then a website is out of question. You also seem to be confusing React and React Native. They are very different tools and you can't share the codebase that easily. One simple example is react having the horizontal flexbox orientation while React Native has the vertical by default. ReactNative also doesn't support Linux.

With ReactNative you'd depend on platform apis while Flutter gives you the flexibility to create whatever you want oob meaning you don't need to use any dependency as it's very easy to build your own stuff and draw on the canvas.

One amazing thing would be to have the whole business logic of the app be in Rust for speed and performance and use Flutter just as a GUI layer. That is very straight forward to do with Flutter. Then you'd have your business logic basically running forever as Rust doesn't change that fast and you could build any kind of GUI you want on top of it with any framework you want (Just an idea).

Also, React and Electron have terrible performance, it's amazing what for example Microsoft has managed to do with Visual Studio Code but it's still terrible compared to what you can achieve with Flutter, GTK or any other natively compiled technology.

Flutter also doesn't render a true DOM, which is annoying if you want to offer a website eventually as well.

When I'm proposing Flutter I don't think about it being used for the web even tho it would be a good choice as it can be compiled to webassembly and you can have native performance on the web. If you don't trust me go check out Audacity, a c++ program compiled to wasm and check out the app size and the performance: https://wavacity.com/ That said, we all know webassembly is not good for SEO. But if you're gonna make an app, not a website, then Flutter gives you the ability to target Android, iOS, macOS, Windows, Linux, All those VR headsets like Vision Pro, different architectures like ARM for Raspberry Pi and TV boxes, you can target Android TV, those Amazon thingies etc. WITH ONE CODEBASE!

And for website feel free to use whatever you want then. But if the idea is to own your data and follow creators then a local app is what you want but you want it to run everywhere, not a website.

React Native would be worth considering. Its desktop targets don't suffer from a WebView and you still render a true DOM when you target the web. On top of that, you can target all platforms natively from one codebase.

You can consider it, that's fine but you can't rely on targeting all those platforms. for example for macOS and Linux ReactNative has adapted the Skia renderer from Flutter to work for React Native. Guess what? Skia renderer is being replaced in Flutter by the new Vulkan accelerated Impeller renderer that doesn't suffer from janky animations etc. Flutter offers you wide platform support out of the box while react native requires hacks.

Don't get me wrong, both are amazing frameworks but Flutter is considerably better suited for a project like this if nothing else then for its rendering flexibility and foreign function interface. Not to mention that they already have a lot of java code that you can easily all integrate with flutter because it was meant to do that.

Sorry all for this ranty text, fell free to hide it if it's too much. Otherwise feel free to ask any questions about Flutter.

[martin-braun]

I'm definitely not confusing React with ReactNative. Your fear was to have a slow Electron App with React. ReactNative outputs native UI and not a WebView. ReactNative also has a shared code-base, although the native parts (which are often already provided with many plugins) need to be implemented for each platform, obviously. Most, if not all, work is already done when it comes to the native parts.

Btw, Flutter also relies on platform APIs, but not as many, since Flutter has its own render pipeline and doesn't require native UI API to render native controls, it simply always renders on a canvas.

And if you ever consider Flutter for web: Unless you have built a professional app that you want to bring to the web, Flutter gives just a terrible UI/UX in the web browser. Native browser controls don't work. You end up re-implementing basic stuff like marking text, right click menu, copy/paste text, etc. The result is an experience that doesn't feel like a website. You wouldn't have this problem with ReactNative, that was my point.

If you don't trust me go check out Audacity

Good stuff. I never said Flutter has bad performance. Your sample illustrates and supports my stance: This doesn't look and feel like a website.

I need to emphasize that I'm still not a supporter of React (no confusion here, I mean the way of programming with hooks, etc.), so I wouldn't fully support ReactNative either for personal reasons. I just think it is worth exploring the options and weighing the benefits with each other. ReactNative can shall be ditched from the picks if the polycentric account model doesn't support a web platform anyways.

It's funny that you mention Rust, I think even if people choose an Electron-like experience, picking Tauri (i.e. for instance via Dioxus) would be a more performant choice.

A similar concept to Flutter is offered by JetBrains via Compose Multiplatform and its biggest advantage against Flutter is that it builds on top of Kotlin and leverages Android Jetpack Compose for Android, which is truly native on Android, incl. the UI.

The Multiplatform render pipeline runs for iOS, Desktop and Web, which behaves similar to Flutter in that it renders onto a canvas, but as mentioned Android is fully native.

My point is: Flutter might not be the best pick here. There are many other options out there worth to explore.

[KristijanZic]

@martin-braun All those other technologies that you've mentioned require you write platform code for example for kotlin multiplatform it's just the UI in kotlin, the business logic is in Kotlin for Android, Swift for iOS etc. React Native renders native platform components which will make your app consistent with the target platform but not a consistent UI across platforms and it requires basically separate UI code for each platform as not all components are available everywhere etc. Also What about platforms they don't support like Linux or Web (react native has only community support for that and it lags behind a lot)? You can integrate Rust with Flutter, GTK, Avalonia, all kinds of UI frameworks, it doesn't have to be web based Tauri, it can be native Iced for desktop. But whatever, it's a pointless discussion since we agree it shouldn't be electron and hacks like that.

Anyway agree to disagree. But you say that I'm worried about Electron like that's not something to be worried about hehe? You think they'd never go that route? Look at this my brother and tell me this is a good decision with a straight face:

It's a video app, that does an enormous amount of parsing of other websites in javascript in an Electron container. The project is over before it has even started as it will literally eat RAM and it will eat the battery. Just look how it eats the battery on android and now imagine it being in javascript. Disaster. If it was in Dart it would be better, Rust logic even more so. But JavaScript... oh man.

[martin-braun]

@KristijanZic Fair enough. We might not fully agree on every nuance. I don't really wish to claim the truth on what should be done, but we absolutely agree on what should not be done, picking Electron.

I missed their hiring forefront, and it's concerning to say the least. I don't have to say something else with "a straight face" as you say. I've seen Electron in many projects and it has been proven to be possible for things like chat apps, but it feels to clunky and will hog to much for a rich media application such as a YouTube alternative.

They seem to love Kotlin though, so I wouldn't put the Compose Multiplatform aside to fast. As far as I can tell, you can also share Kotlin business logic across all platforms, not just the UI. You can also bring other native languages into the mix, be it Rust, C++ or whatever.

I used to challenge them about why to use it over Flutter: https://github.com/JetBrains/compose-multiplatform/discussions/3342

I've yet to dig deeper into their technology, though.