Electron is not a terrible option for getting web apps to work on Windows, Mac and Linux. It’s just not the most ideal route, and if it were to drop support for any one of those, Joplin would be in trouble. It also is bloated and every so often, a platform breaks. Take the Linux 5.5 and 5.6 kernel issues that users have been having or the OSX Catalina rendering issues. The dev team there does eventually fix those but I’d like to find out what you all think about as alternatives.
I’m looking at the Haxe framework due to its ability to compile to native executables for all platforms while also being able to take javascript code as an input and having quite a few ports already made of some of the libraries used for this project.
10 Likes
I am an old fashioned software developer. Experience has taught me that complex frameworks sooner or later tend to become a burden and break up applications.
When using frameworks (and other tools) I must be able to understand them to a sufficiently decent level. I must be able to find and fix problems (so it must be open source). If I can’t then this framework is too complex for me.
When I checkout and build Joplin I end up with 105280 files. This is, by my definition, unmaintainable. You can argue that a lot of these files are from Electron and other 3rd party packages, but each of these packages can stop functioning any time and don’t tell me that they won’t because there are big companies/user groups backing them. Electron broke Joplin several times and Laurent cs. did a great job overcoming incompatible changes far as possible. Some problems were never fixed so we just have to get used to it. That’s a nice, custom-friendly attitude from big companies/user groups, isn’t it?
Also, many of these are pulled in from 3rd party sites during the build/install. I can never be sure it will be the same collection of files that I’m testing.
So, as you may guess, I’m very sceptical about those modern quick start-up frameworks, be it Electron or Haxe or whatever. In the beginning you make good progress because they make things easier for you, but you may regret it later when you are 80% done and unable to complete the final 20% since the framework won’t let you.
So it is better to minimize framework dependency than to swap one framework for yet another.
6 Likes
One main argument i can make is that Haxe is over 15 years old, so it’s not new at all. It’s just not as well known as Electron. It also has its own fair share of problems such as third party libraries not being updated to work with the latest releases as often as I’d like. I also see your point. If this were a thing, it’d mainly be a separate project altogether built from Joplin’s base framework.
Speaking from a very technical perspective, nothing is really cross platform. Interpreted languages get closest, but the trouble is really with the fact that UI mechanisms vary vastly between Mac, Windows and Linux. If you have are familiar with the history of the Abstract Window Toolkit(AWT) of Java, you know what I am referring to.
Anything built in Javascript is susceptible to being obsoleted or broken due to dependency inconsistency. Because, it was really never made to work outside the browser, and any fancier addition on top of it like ES6 or Typescript is likely to break in future.
Maybe we should not really think about this problem until it completely breaks, and then consider rewriting with something else. like C++ or Java.
2 Likes
Funny you say that. My proficiency is Java and that’s a pure nightmare what you were referring to. The best option at the moment would be to stick with what’s working now. Doesn’t mean that experimentation as a side project would be a waste of time for guys like me.
I don’t know if 105, 280 is all that big. I mean I had a look at the Linux kernel code as well as the code of Blender (an open source animation suite, like Maya), and it was pretty big as well. And a lot more messier as well, because it is written in C. However, development and maintenance is both very efficiently done in both.
O no, even I have done most my software devel projects in Java. But that’s why the Swing library was written over the AWT library. It doesn’t use native components at all. Just the ability to paint on a canvas from the native library is all that is required
1 Like
The kernel is also one of the oldest open source projects still actively developed on.
1 Like
Speaking of Swing. Haxe released hlsdl an official sdl2 extension for the same reason. It’s also a bit buggy to use and requires hashlink, an experimental vm for haxe. I wanna test it out
1 Like
I’ve worked quite a lot with wxWidgets. Abstract platform agnostic API and native look and feel.
2 Likes
You can look at nim as well. It gives great performance, generates native binaries for platform, has compatibility with C/C++/Javascript and best part it is easy to pick up.
I’m still starting out so I can ask one of core guys to reach out if you are interested or you can join chat group -
Nim
Official Nim programming language Telegram group.
Learning resources: https://nim-lang.org/learn.html
Forum: https://forum.nim-lang.org/
Source: https://github.com/nim-lang/Nim/
Telegram: https://t.me/nim_lang
1 Like
I just looked at Nim and it doesn’t look like it supports React. Am I misreading or missing something?
Interesting. I always though wxWidgets was Windows only but glad i was wrong. It looks like it does have native Javascript bindings but they are also almost a decade old, meaning probably unusable for React and more work and trouble than needed. But glad I’m getting responses here. Thanks all
Which more or less implies that we cannot expect javascript programs to last longer than a couple of years.
Or implies that no one is really wanting to support Wxwidgets in JavaScript on an official level or it’s been superseded by other projects.
WxWidget is indeed old and quite awful to work with to be honest.
Qt is much better, though last time I tried it was very tricky to get the same code running in both desktop and mobile, and mobile GUI features were a bit buggy and limited.
2 Likes
Also, QT can and does have its own issues for certain Linux desktop environments, primarily being things related to titlebars and buttons not matching the desktop environment with little way to directly change them.
Will there is this project - https://github.com/andreaferretti/react.nim
But overall things are still being developed due to community being small.
Btw when you say native, due you intend to reuse existing code (since you asked react).
You mentioned Haxe earlier, so I thought you wanted something you build in 1 language/framework then build and deploy for all platforms
1 Like
@nickdex, reusing existing code would be ideal from a maintenance standpoint but realistically, rebuilding in another framework that might have less dependencies needed, be more time tested, and be fairly portable from the original code would most likely be the better option. React, impo, is just too breakage prone from a technical standpoint.
Any information and suggestions are welcomed here since this is still a what if idea at the moment.
1 Like
Anyone here have experience with Proton-native? It looks like it was made as a native alternative to Electron and should take all of the code and libraries Joplin uses but would need testing. It also looks like it uses QT5 as its base on Linux. That would definitely fall in with Laurent’s suggestion.
1 Like