Desktop - Moving From Electron to Native to Future-Proof All Platforms

avndp · 2020-04-10T03:31:21.160Z

I’m not sure if this is relevant here: https://ev.kde.org/2020/04/06/changes-in-qt-and-the-kde-free-qt-foundation/

Considering the fact that Joplin is FOSS, is Qt a good choice?

vabean · 2020-04-11T11:53:37.567Z

avndp:

Considering the fact that Joplin is FOSS, is Qt a good choice?

Why should that be a problem?

Qt is great but the mobile support is questionable.

Why? I've written several apps for Android.

C++ is concise but memory management has to be done very systematically for avoiding performance lags or bugs

Smart Pointers handles this pretty easily.

In general I think Qt is great. It's cross platform and with QML the UI is easily customizable...

bedwardly-down · 2020-04-11T15:39:52.388Z

@vabean, QT just got in a bit of a conflict with much of its user base over the license changes being made and some mishap with the KDE developers and community. The Open Source community (including me) can become ravenous beasts at the drop of a hat when companies do things like this that could affect how developers use libraries in their apps. The license change here isn’t that bad of a move but can affect how proprietary software uses QT from here on out. That’s what the problem here is

RedDocMD · 2020-04-11T16:40:57.235Z

vabean:

Smart Pointers handles this pretty easily.

@vabean, I was referring to this only, However the thing with smart pointers is that if used in the incorrect way it can have serious performance tolls. Used the right way however, it is great and gets rid of performance and memory problems (Yes, smart pointers and pointers used the right way with proper move semantics have a performance boost).
I think you will have to admit that of all the languages I mentioned, C++ needs the maximum sophistication to get that maximum performance.

vabean · 2020-04-12T16:39:55.001Z

bedwardly-down Yes, making LTS only available for commercial customers and now requiring an account for all users is bad. In general I would summarize Qt: Great technology and BS (company) management. Nevertheless, the technology is great

I think you will have to admit that of all the languages I mentioned, C++ needs the maximum sophistication to get that maximum performance.

Maybe if you aim for Scott Meyers-like optimizations. But in most cases I would argue that getting out the maximum performance of C++ isn't necessary since basic solutions are performant enough when compared to other technologies...

chgraham · 2020-04-12T23:01:13.805Z

Are you aware of / have you considered Gluon ? All-Java, with native (mobile) implementations (including look & feel) of JavaFX, if I understand correctly.

iOS, Android, cross-platform desktop (apparently).

Gluon

Rapid Enterprise Mobile Apps: Build, Connect, Manage with Gluon

An end-to-end enterprise mobile solution for developing cross-platform mobile apps. Easily connect to enterprise backends and cloud services.

Gluon

Gluon Desktop - Gluon

Small, Powerful API.Convention over Configuration.Kickstart your desktop apps. Buy Now (Try for free) Small, Powerful API Frameworks tend to grow, and grow, and grow! Gluon Desktop has been designed with a minimal API footprint in mind...

I don’t think the company’s website provides sufficient information, i.e., you’d really have to chat with its sales reps and developers to evaluate either or both products. I get the impression that Gluon Desktop may have been orphaned. Again, a question or two would be required.

Gluon CloudLink - Gluon

Mobile Management & Cloud Integration

Gluon

Scene Builder - Gluon

Drag & Drop,Rapid Application Development. Download Now Integrated Scene Builder works with the JavaFX ecosystem – official controls, community projects, and Gluon offerings including Gluon Mobile, Gluon Desktop, and Gluon CloudLink....

werth · 2020-04-13T08:00:57.693Z

Or maybe Kotlin/Kotlin Native?

metalspork · 2020-04-14T05:48:43.431Z

My initial feeling is that I’m wary of trying to use a single unified codebase to build a graphical application that works on everything. There are very few tools that do that properly. That said, I don’t really have a dog in this fight, but I’m on board to help with any development efforts.

guy-rouillier · 2020-05-08T01:53:18.620Z

I did extensive work with Java (and a small amount of JavaFX) as a professional developer in a corporate environment. Java was tolerated there since it’s a captive audience. But in general, Java GUI apps are not well loved. Most people prefer native UIs, and JavaFX doesn’t come close to that.

I don’t know Gluon at all, but looks like development options can get costly. Especially in the open source world, developers typically avoid costly platforms.

rlogwood · 2020-07-16T13:40:01.247Z

Have you considered Flutter? It's free and open source and backed by Google and uses Dart. Yes it's a new kid on the block at about 3 years old, but looks good and is targeted to run everywhere. Could be fun to explore as an option

https://flutter.dev/
FAQ - Flutter

RedDocMD · 2020-07-16T16:44:00.911Z

Yes Flutter is a rather excellent choice. But it works only for mobile devices, making it unsuitable for Joplin, which must share the same codebase for all its versions.

roman_r_m · 2020-07-16T17:04:03.736Z

It’s not that the current code base is exactly the same for mobile and desktop so maybe that’s not that big of deal.
But the fact the Windows support is still in development might be.

On a somewhat related note, I am experimenting with rewriting markdown renderer (for desktop) in rust.
But that’s just for my own use as it lacks lots of features like mermaid or katex (which I do not use anyway).

Undrwater · 2020-07-18T00:40:53.972Z

I’m not savvy enough to be able to differentiate the tools in discussion here, but I’m aware of a Qt project (that initially started as a GTK project) called Subsurface. It is a SCUBA dive log and planner and was initially developed by Linus Torvalds (who happens to be a diver). He handed maintenance over to Dirk Hohndel.

It is written in Qt, has both desktop and mobile software, and runs on Linux, Mac, and Windows. It is, of course, open source, so perhaps taking a look at their code might be helpuful?

github
main website

elsiehupp · 2020-10-17T01:22:35.033Z

Speaking as a Mac user, I could see the obvious desire to build a Joplin GUI from the ground up in SwiftUI or whatever Apple is pushing these days. The main issue (other than this being an mindbogglingly time-intensive undertaking, lol) is that the codebase would need strict architectural separations so that shared components could remain stable while the platform-specific ones are able to evolve independent from each other. I've only poked around a little bit, and I'm still quite confused.

rxliuli · 2020-10-17T05:45:41.134Z

No silver bullet

elsiehupp · 2020-10-18T22:05:06.921Z

Something that seems like a potential way of simplifying the codebase while building on what's already there is porting the Linux, macOS, Windows builds over to using ReactNative instead of React HTML with Electron. I don't fully understand why Joplin uses Electron on desktop when ReactNative (which Joplin already uses on Android and iOS) does, in fact, support building directly to macOS and Windows, as well as Linux (though ReactGTK seems a lot less developed). Yes, this would eliminate the ability to apply CSS theming to the user interface, but it would make Joplin dependent on one fewer framework in the long run, which should help improve the stability and maintainability of the project.

That said, should the maintainers decide to expand Joplin's use of ReactNative, it would indubitably be a substantial long-term undertaking, one which would probably be easier to begin if the immediate priority remains improving the documentation and organization of the existing code. Does that make sense?

laurent · 2020-10-19T00:34:00.197Z

Hmm, yes obviously that's a very abstract discussion because we aren't going to change the framework like that. We don't have teams of developers that can work over several months to do that for us. Not to mention that it wouldn't make sense to switch to a different framework. Electron is future proof. It's actively developed and supported by Microsoft and other major companies, and is used for many commercial applications.

I still think Electron is the best solution at the moment. If I was developing a new desktop app that's probably what I'd pick (I'd check Qt again to see where they're at though).

On paper React Native might seem more "native" but when you start really using a technology and going into the details you quickly start hitting all kind of edge cases and bugs, even more so with RN (at least on mobile). RN for Windows is an unproven technology and too young, not to mention macOS and you can forget about Linux.

Maybe 4-5 years from now we'll have a clearer view about what framework could replace Electron, but for now it's still a reliable way to get a cross-platform desktop app done.

trymeout · 2022-06-12T02:03:04.012Z

I think Tauri would be the best solution for this app since Tauri is a lightweight alternative to Electron which plans to allow for compiling to Android and iOS in the future. And Tauri apps are written with web languages which is what Joplin is written in, the transformation would not be a complete rewrite.

Another good solution is Flutter which allows for apps to be compile for desktop and mobile but will require a complete rewrite of Joplin since Fultter uses Dart as its programming language.

trymeout · 2024-10-06T20:13:00.652Z

Tauri 2.0 is now out which supports making Windows, MacOS, Linux, Android and iOS apps using HTML, JS and CSS.

c0dev0id · 2024-11-01T16:02:46.320Z

The problem with electron is that it's really limited to the platforms it supports and it's almost impossible with reasonable effort to port it to anything else.

Porting electron is an immense effort, and it requires serious computing power to compile. Well - like chrome. But chrome is for all users of the OS, while Electron is usually bundled with the application because every application needs another version. This multiplies the effort.

Therefore more niche OS like OpenBSD are locked out by electron.