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

A PWA (progressiver web app) is not a valid alternative for this problem? Check this one https://wavemaker.cards/

How is that different than Electron? And it also looks like that's a Google project tied to Chrome. Maybe I’m misreading that, but what would that do for privacy and security? I’m very curious about this.

Welcome to the forums, btw. <3

PWA’s are not google/chrome only. It’s basically a webapp using a bunch of modern js/browser APIs to get functionality like offline, better caching, etc. As well as looking/acting more like a native app (i.e. I run Outlook as a PWA in my Mac and while it is running through the browser, it is it’s own window and has its own icon in the taskbar).

The problem with a PWA is you have to have webhosting behind it (so Joplin would need to be a webapp first), and interacting with the native filesystem (as I think one would have to do to handle all the notes and syncing and encrypting) isn’t really viable as there are no support APIs to do that (so many security issues).

1 Like

I must say that I still haven’t used a good PWA app. I tried a few of them, but they were always pretty slow and was struggling badly with offline modes.

1 Like

I was a Java software developer for 15+ years (now retired.) Java is great for backend work, but pretty unloved for graphical applications. As RedDocMD accurately points out, Swing doesn’t use native components (i.e., components provided by the platform). Turns out, most people strongly prefer native components, and immensely dislike non-native ones like those employed by Swing. Java does have the Standard Widget Toolkit (SWT), which uses platform native components. But because SWT uses native components, it requires a platform-specific SWT library, which is a maintenance headache. So it hasn’t gotten widespread use.

3 Likes

Can you relate some reasons why people prefer native components? I mean it makes no difference to the end user whether the component is native or just looks like it? (The Swing library can take up the native look and feel, apart from the standard Metal or Nimbus)

This seems to be an issue in particular among Mac users. PC users, through the DOS and Windows eras, always had a mishmash of inconsistent user interfaces, so inconsistent became normal. The Mac world had very stringent user interface guidelines from the very start, so consistency was very important there. And Swing apps on any platform are quite obviously not built with native components. Most Java developers don’t bother worrying about supplying a particular look and feel, so the default is what most end users get.

I regularly use a desktop app from TD Ameritrade, the brokerage company, called ThinkOrSwim, which is a Swing app. And anyone can tell immediately this is not a native app. No titlebar, no menu, and buttons don’t look like buttons. Most of us will probably just say, meh, it gets the job done. But some will find the entire experience annoying.

2 Likes

So the Mac Look and Feel that comes with the Mac JRE is not upto the mark? Or is it that many Java developers are just lazy and don’t bother to set the LAF at the start of the application?

For the end user it doesn’t matter much whether the application uses native components or components that just look like it, provided the components really do a good job on the look and feel. And, as usual, it is easy to get 80% right, but the remaining 80% is hard, very hard.

That is why a platformneutral abstraction layer using native components (i.e. WxWidgets) is better than components that mimic look and feel.

@laurent Yes, WxWidgets is a bit though to get used to. Tools like wxGlade are helpful.

With Java the troubles are not only for the developer. Whenever I see a useful application but I see it’s in Java I will likely skip it. Some require Java 8, some 9, and installation of multiple Java’s and setting up JAVA_PATH is left to the user more often than not. I recognize all the problems listed here with Electron, but from my perspective, for the desktop end-user, it’s much more likely to “just work” than a Java-written app.

1 Like

That happens I believe because for a developer those settings are trivial to get up and running, so it’s often hard to realise the difficulties that an end user has to do these things that are routine for the developer. If you notice, a plethora of Java apps are written by single developers since Java allows that to be done quite easily. If course well written ones like Geogebra for an instance have install scripts and other measures so that the user doesn’t have all that much to do. Its the same reason why I believe that @guy-rouillier says that Java apps are disliked for not having a native look and feel. Developers just forget to activate the correct options.

1 Like

How about using Qt with QtQuick aka QML?

Then I will start contributing, too :wink:

1 Like

Non windows platforms is where many of these web apps struggle. That’s where Joplin seems to be flopping around a bit due to kernel maintainers changing how things work upstream and breaking quite a few frameworks and apps when they did such.

I don’t hate Windows. I just have different needs that require substantially more work to obtain with Windows. This whole post came about because of concerns with the Linux and Mac apps.

@RedDocMD, I don’t think Java developers (or really, developers on the whole) are lazy. My opinion, having worked in the field, is that the organization does not put enough importance on getting an acceptable user interface. Aside from companies that make the bulk of their money from software like Microsoft, for most organizations software applications are not a significant source of income or profit. The one I mentioned from TD Ameritrade is useful only on that platform, and TD provides it to their customers free of charge. In that situation, carefully tailoring an application for separate operating systems is an unjustifiable expense. So, they look for an alternative that is “good enough” for their customers, and that will be of acceptable cost to develop. Since Java is write-once-run-anywhere, that nicely meets that requirement. Customers use it because they have no other choice, and it gets the job done, but they don’t actually enjoy the experience.

2 Likes

@guy-rouillier, that sounds like the old adage:

If you’re not paying for it, you become the product.

2 Likes

I’m not good at JS (not even “Hello, World!” capable) but has anyone researched QT Quick?

The first version of Joplin was done with Qt and QML (the code is still there in the repo in old commits, before it was replaced by React), but as mentioned it’s not great for mobile. Also when I’ve started QML was recommended over QtWidget, yet the library of components at that time was very limited.

For desktop I would have preferred using Qt actually as I’ve developed before a relatively large cross platform app with QtWidget and it’s a very good framework with excellent doc.

2 Likes

Honestly, would separating mobile and desktop be feasible? I mean QT is constantly getting better and more extensions are being released to make developing various types of apps easier.

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.

4 Likes

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.

1 Like