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…
@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
@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.
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...
Are you aware of / have you considered Gluon ? All-Java, with native (mobile) implementations (including look & feel) of JavaFX, if I understand correctly.
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.
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.
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.
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
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.
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).
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?
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.
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?
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.
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.
