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

laurent · 2020-04-09T22:41:39.854Z

Everything’s possible but I don’t think it would make sense. If let’s say we get stuck and Electron or React Native get discontinued then we could look at porting the code to another framework, but it’s not the case. No framework is perfect anyway, I’m sure if we use something else we’ll hit other different issues.

Also, people like to dislike Electron and React Native but it’s actually impressive how well they work on a wide range of devices, operating systems and configurations. It’s difficult to find frameworks that work as well as that.

bedwardly-down · 2020-04-09T23:10:06.891Z

I can see that. A common issue in the Linux community and outside of it: if an app or framework doesn’t work, move to Windows because it has the most support. Almost all frameworks have Linux related issues at some point.

It’s an infuriating notion that doesn’t actually solve any problems.

RedDocMD · 2020-04-10T03:13:31.898Z

I agree that almost every framework has some issue or the other. wxWidgets is cross platform but has a weird signal handling mechanism and user customisation is difficult. Qt is great but the mobile support is questionable. Electron and React Native combined makes it almost cross platform and cross device and is easier to code, but they are slower and have a tendency to break now and then. As a language JavaScript evolves too fast, Java seems bloated and stagnant (at least some people think, I don’t), C++ is concise but memory management has to be done very systematically for avoiding performance lags or bugs, Python GUIs tend to be laggy. Rust and Go seem to be the new big thing in the language world, but I don’t know how much actual developmment has been done with them.

There seems to be no Paradise in the software development world it seems…

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.