In essentially every discussion about desktop applications there are a lot of comments about how not to build desktop apps, but very little sharing of resources showing how to do it right.
I’ve seen people defend electron, talk about core logic in a cross platform language and native gui code and any number of other options.
As a middle of the road developer I think it’s difficult to find any consensus (besides electron being both simple and hated).
What resources are there for building quality, functional cross platform desktop application?
1) Buy a basic HTML template online for your app's dashboard.
2) Don't use Electon. Your users WILL notice and complain about performance. Instead, use the native WebBrowser control in .NET for Windows and WebView using macOS to display your UI. Disable right clicking and highlighting using HTML/JS. To the user, it'll feel like any other native app. Add this meta tag to the HTML file to ensure the WebBrowser control knows to use new versions of IE to render the UI: <meta http-equiv="x-ua-compatible" content="ie=edge"> (and/or look up how to add the FEATURE_BROWSER_EMULATION registry key)
3) Use the built in script calling functions to transfer settings back and forth between the UI and main app in JSON. Do the back end stuff in native code.
4) You can then re-use most of the UI code you wrote to easily port over to macOS. Use the same functions and logic you wrote on Windows to make your Swift functions.
* I've been making a living from building/maintaining my desktop application for about 5 years and had no regrets setting it up this way. I've also seen a number of other expensive, high-end, "professional" software using the FEATURE_BROWSER_EMULATION registry key trick.
Good luck!
Going to heavily disagree here. Whether or not your user's will notice is debatable in itself, but you shouldn't really factor that into your decision making.
Instead you should ask if your users would care that it uses Electron, and more whether they would be sufficiently put off to look for alternatives. And in a vast majority of cases the response to that question is going to be 'No'.
But the second part of this comment, I disagree with even further. DO NOT USE A NATIVE WEBBROWSER CONTROL FOR YOUR DESKTOP APP's UI.
Sorry for yelling, but that really is that terrible an idea. Most native webview components lag behind the embedded chromium instance Electron uses by a lot. Basic things that would work in IE10 are known to break on desktop webviews. Primary reason for this is that these webviews are only updated with OS updates.
End result is you will have to bend over backwards to get your UI working as expected on all these native webviews. This is just too much work and will end up diverting attention from developing core features of your app to fixing rendering bugs instead.
This is probably sound business advice, but it's also a bit sad to shift the goal from trying to create "great software" to "not horrible enough to make all potential users run away".
Webviews are okay on mobile though.
Do you have examples of that? I believe the majority of users will be running a quite recent version of Safari and Edge in these circumstances.
How will people notice if you are using Electon, but not if you are doing this? Is Electron doing something that makes it unnecessarily slow or are you saying that people are just conditioned to think Electron apps are slower?
A public example: Dwyrin is a YouTube streamer playing Go/Baduk. After most streams he reviews the game and likes an app called Sabaki. About 8:10 minutes in, he remarks on the performance of the app (https://youtu.be/vrX4qlbpQfU?t=492). Sabaki is an electron based app.
I do however disagree with removing right click / highlighting. That makes copy paste difficult or impossible for the typical user. I spent years working on Silverlight and UWP and one of the things I recall the team looking back on particularly with Silverlight and regretting was that TextBlocks by default didn't have highlightable text. Its too useful for users sharing error messages with you as the developer or data with each other to get their jobs done.
Electron likely helped Sabaki focus on other features with good enough performance, while being the best looking and most skinnable Go app by a country mile (I created a How to train your Dragon skin to temp my partner into learning Go :D)
Only so many hours to dedicate to a project, you have to pick what you value most. This comme T is partially because I'd hate for the people involved with Sabaki to not hear that at least some of their users "get it" and love it.
If you are making an application that you expect users to run as a background process, perhaps Electron isn't the best option.
If Electron is for an application users will open, use, and close, Electron is an excellent tool for the job.
My two electron applications as examples:
Video Hub App: https://github.com/whyboris/Video-Hub-App & https://videohubapp.com/
Simplest File Renamer: https://github.com/whyboris/Simplest-File-Renamer & https://yboris.dev/renamer/
I've never had good experiences with templates. They usually have too many dependencies or too many custom tweaks. There's one I'm using on a project at work (was chosen before I joined) and it's a huge mishmash of Bootstrap/Material Design and other stuff. Proper mess.
Much easier to just choose a style framework like Bootstrap and build it yourself.
2> Instead, use the native WebBrowser control in .NET for Windows
Use WebView2 instead. It uses the new Edge/Chromium rendering engine - https://docs.microsoft.com/en-us/microsoft-edge/webview2/
> The WebView2 Preview is intended for early prototyping and to gather feedback to help shape the API. You should not use the preview in your production apps because there may be breaking changes.
There's not much more to it than you can see, there's the BIM360 tab on the left that allows browsing through a cloud directory structure, and Civil3D also has a learning content tab.
Qt-based Software uses Qt WebEngine instead of the .NET stuff. The reason we're using HTML + JS is that we wanted to share the start page between different applications and HTML + JS is the lowest common denominator so to say, something that every team could integrate.
I suspect that the needed complexity of the UI factors in heavily as to how well this approach will work.
1. Sciter
- Languages: C++/Python/Go/Rust/Pascal (optional: HTML/CSS/tiscript)
- Development time: fast
- Resource usage: light (space and performance)
- Visual customization: easy, doesn't use native widgets.
2. Qt
- Languages: C++/Python (optional: CSS/JS/QML)
- Development time: slow
- Resource usage: quite heavy (space), but well performant
- Visual customization: QtWidgets: hard, QML: easy, doesn't use native widgets.
3. WxWidgets
- Languages: C++/Python
- Development time: slow
- Resource usage: light (space and performance)
- Visual customization: hard, uses native widgets.
4. Lazarus
- Languages: Pascal
- Development time: slow
- Resource usage: light (space and performance)
- Visual customization: hard, uses native widgets.
[1]: https://sciter.com/ - https://quark.sciter.com/
[2]: https://www.qt.io/
[3]: https://www.wxwidgets.org/
[4]: https://www.lazarus-ide.org/
The application uses exactly same code on all platforms: https://github.com/c-smile/sciter-sdk/tree/master/notes
It even runs on Windows 2000: https://sciter.com/necromancing-sciter-on-windows-2000/
I couldn't tell, just from glancing at the website/github.
UI, application logic and data storage.
QML is far not enough for this I think.
It took me 3.5 months ( https://notes.sciter.com/2017/09/11/motivation-and-a-bit-of-... ). But I shall admit that this does not include architecture time as I knew internal architecture of EverNote upfront.
I do think Dart itself is a fine language, though.
I would actually say that it is perhaps the fastest in the list.
1.1k https://github.com/topics/pascal
27k https://github.com/topics/cpp
161k https://github.com/topics/python
[1] http://scid.sourceforge.net/
Qt is good but it requires you to go fully into the Qt ecosystem (build tools, etc) not sure about QML though.
For wxWidgets, there is wxUniversal, which draws custom controls, thus easier to customize - not sure how well it is maintained though.
I'd argue that dev time is quite fast for all - Qt, wxWidgets, Lazarus.
What people initially miss about UI libraries is composition features. Which are over the top for QML and not so to put is softly for Sciter.
Even if you're not legally required to implement it now, and even if you don't think this is a basic human right (which you should), there are legal changes coming, and you never know when you will be forced to implement it.
If you choose a library with great accessibility support, even though your app might not be accessible initially, fixing this won't be that hard. If you choose a library without one, though, when the time comes, you will either need to completely rewrite your app using a different library, or dig deep into native OS code and figure out how to interface with accessibility APIs, which is not an easy task.
This is a risk/reward scenario. The downside of choosing a library that supports accessibility usually isn't that bad, putting personal feelings about Electron aside. However, if you need accessibility someday, however unlikely that might now seem, you really don't want to be forced to drop everything and focus on rewriting that GUI layer fast, before the regulators catch you.
It seemed very unlikely that game developers would ever need accessibility, so no one cared. Then, the US government mandated that all chat systems must be accessible, and a lot of games include chat systems. That was not a pleasant experience for anyone. You never know what is coming, and you don't want to shoot yourself in the foot.
Now for some pointers. Electron is fine. No, really, Electron, is, fine. There's nothing wrong with it. QT is fine too. GTK works, as long as all your users are on Linux, as accessibility for other platforms is nonexistent. Java works on Windows, not sure about Linux and Mac. Anything that uses native widgets, so WX and native OS frameworks are the best, but not everyone can afford the luxury of choosing those. Game frameworks and small, minimal libraries are a no go.
That said, what happened to the last couple of generations? When did freedom stop meaning "free" and start meaning "fair" or "the right thing"? How did our culture get things so tangled up that our urge to "not potentially offend anyone" started eroding the very principals we think we are upholding? You must be young. /rant
Suggesting accessible software is a human right? You have to know how silly that looks compared to the list of other things that qualify as human rights.
I'd argue that what's truly silly is refusing to recognise that software/the web is becoming (if not has already become) as much core global infrastructure as physical equivalents are. We can't push for and actively build an increasingly online world and then plug our ears and pretend that the accessibility of online spaces isn't as important as the accessibility of physical ones.
0) All advice depends a lot on the product. Most general advice is just useless.
1) Preparing for potential changes in legislation is most of the time not a good idea. As you said you never know what is coming and so you should not try to prepare for everything. Also said games you mention could probably disable the chat if implementing accessibility features was to costly. Also these changes don't come over night.
2) I really dislike what people try to cramp into basic human rights.. Do you also expect this from open source software? Do you really think if people spend their free time they are obligated to implement accessibility or whatever else? In my opinion the user of open source is entitled too nothing.
3) Electron, is, not, fine, just, like, that. There are tons of Electron apps out there which have no right to carry hundreds of megabyte with them and consume that many resources. I am pro choosing whatever you want. But please don't advert Electron as "is-always-fine".. If you even want to force accessibility.. what about energy consumption?
You might miss or be unaware of accessibility concerns when developing, but it's easier to go back and fix what you missed than it is to build an entire ui and go back and add accessibility to begin with.
As to electron, if you want to leverage web skills to build a mobile app, it's a cromulent solution. I don't think big companies with resources should use it (slack), but for JS devs who want to build things, it's a great tool. Most people I work with don't realize slack and vscode are both electron apps.
In my opinion, this depends whether the software in question improves the lives of its users or makes the lives of non-users worse.
If it's just another media player we don't have to use, accessibility would be cool, but it's not really that important. If it's a chat solution for companies, accessibility is absolutely crucial, open-source or not. Not implementing accessibility means people could lose their jobs if their companies switch to it. Society would be better off if this software never existed in the first place.
For the record, the default choices for text size here on Hacker News are an example of ignoring basic accessibility.
Java on Linux/Mac is fine.
Never have to comply with the law if you never have any users to begin with
GTK user tapping head
Why?
1. Cross platform - Mac OS, Linux and Window and Raspberry Pi https://www.lazarus-ide.org/
2. VERY fast development and compile-run cycles. You are talking about WYSIWYG designer and compilation in seconds.
3. Fully native binaries which are very small and very fast.
4. It is a full fledged RAD environment with full support for GUI development using a very powerful designer.
5. There are GUI as well as non-GUI components - example: Database components, Database-aware grids, database aware-listboxes, search filters etc.
6. Very diverse set of components. And very easy to develop new components from scratch or customise and existing component.
7. The object structure is very powerful - with support for read & write properties, composite components, property setting pages, internationalisation etc.
8. It is possible to interface with C/C++ libraries as well and that isn't complicated
9. Lazarus has a built-in debugger which is quite powerful and the development environment has full integration with it.
To see a demo of the Lazarus IDE including the debugger functionality, please see the video in the page below: https://www.getlazarus.org/new/
10. Lazarus is 100% open source and is under active development with the last release in July 22, 2020.
Lazarus is not a new fad language. It has been in existence for decades and there are existing apps which are developed in it - example, the Transmission GUI client.
Other projects done in Lazarus: https://www.getlazarus.org/community/showcase/
Projects by category. This is not a full list: https://wiki.freepascal.org/Projects_using_Lazarus
A file manager has to plug into multiple native features, e.g. the list of app associations—and DC does that sorta half-assedly.
I ask because I'm a big fan of PowerArchiver as my go-to archive manager on Windows over the usual 7-Zip/WinZip/WinRAR/etc, it's a Delphi app, and it has a nice GUI: https://www.powerarchiver.com/
So it is best to see Free Pascal & Lazarus as the free and open source alternative to Object Pascal & Delphi respectively.
Of course, now the term Object Pascal is not used at all. Delphi is used to refer to both the language and the IDE now.
About Free Pascal, it is largely compatible with Delphi/Object Pascal but there are minor differences. https://wiki.freepascal.org/Lazarus_For_Delphi_Users
Here is a write up on the advantages of Free Pascal: https://www.freepascal.org/advantage.var
A few months ago I developed a Kanban tool to organize my personal tasks. I use the tool under Windows and Linux, it works fine.
For me the big advantage of Lazarus/FreePascal is that you have to write the business logic only once and you compile the code for different environments to get native binary files (no interpreter used). In case of operating system specific code you can use conditional compilation (e.g. {$ifdef MSWINDOWS}) but in my case that wasn't really necessary.
Freepascal Runtime Library documentation: https://lazarus-ccr.sourceforge.io/docs/rtl/
Lazarus Component Library: https://lazarus-ccr.sourceforge.io/docs/lcl/
Freepascal Component Library: https://lazarus-ccr.sourceforge.io/docs/fcl/
Freepascal Wiki: https://wiki.freepascal.org/Lazarus_Documentation
Something else I should have added in my original comment: Lazarus has a very capable built-in debugger.
That is invaluable if you want to step through and understand how things work.
EDIT: Other sites:
Some demo projects here: https://www.getlazarus.org/
Lazarus project showcase: https://www.getlazarus.org/community/showcase/
The Transmission Bittorrent GUI client was done in Lazarus: https://sourceforge.net/projects/transgui/
Other apps done in Lazarus from the Lazarus website shown by category: https://wiki.freepascal.org/Projects_using_Lazarus
However packages (which includes your own widgets) are nothing more than native libraries that become part of the IDE, so any bugs in a package will cause the entire IDE to crash. This is a double edged sword since on one hand you can get a less stable IDE from your own bugs, but on the other hand when you work with a component or widget in the visual editors, you are really working with a "live" instance of that widget that is then serialized as part of the form or data module instead of a mock stand-in object that some other GUI-only designers will give you. Also this allows you to use any TComponent-derived object through a visual editor, not only visual/GUI objects.
I wrote a little framework for this: https://github.com/jdarpinian/web-ui-skeleton
Running inside a real browser also limits the keyboard shortcuts you can use, because you don't want to clash with the browser's own shortcuts.
See https://www.w3.org/TR/secure-contexts/#is-origin-trustworthy
Exposing a HTTP port with application state is a million times worse for security
Sounds like you already know the big players so I won't repeat them. Instead, here are some off-kilter ideas:
1. Casual use, general interest, notification-requiring, simple single-file data requirements, tolerant of desktop / mobile split sessions? Try making a chat bot for Telegram, FB, Discord, Slack..
2. Dynamic, visualization-focused UI with simple options that need to be tweaked interactively? Try Imgui[0] or Godot[1]
3. Scientific or data-centric stuff pulling in data from here and there, but meant for interactive exploration? Try Wolfram / Mathematica or an IPython notebook / GoogleColab
[0] https://github.com/ocornut/imgui/wiki/Software-using-dear-im...
[1] https://medium.com/swlh/what-makes-godot-engine-great-for-ad...
Cool recommendations, thanks!
1. design things using an MVVM pattern and share all your business logic
2. write all your native gui code manually as you tease out the patterns
3. over time, you can start moving the UI generation into the shared code by writing a custom DSL
The problem with platforms like React.Native and Elecron is that they are based on having a JS runtime, which is a de-facto performance hit and forces an async communication flow to the "native" side (flutter also has this issue). Xamarin does not have that same restriction, and is my preferred framework for this. Xamarin.Native (aka Xamarin.iOS/Xamarin.Android aka Xamarin.Traditional aka Xamarin) has a very minimal performance overhead for what it gives you in terms of native bindings and a shared codebase. Xamarin.Forms is a higher level abstraction that sits on top of Xamarin.Native and lets you theoretically write 100% shared code (by essentially being a community developed UI DSL like I outline in step 3 above), but it is buggy and has much worse performance.
The hardest problems you will have to solve using this approach are navigation and lifecycle. For the most part these are well understood issues and you will find lots of postings with different strategies on how to approach them.
https://github.com/styluslabs/ugui