Overview - NW.js vs Neutralino vs Tauri vs Wails
A brief overview of some distros that allow the creation of OS Desktop Applications using frontend web technologies (HTML/JS/CSS) via browser interfaces.
NW.js :: Fusion of Chromium browser and Node - applications include modified Chromium binary
Neutralino :: Uses modified OS dependent webview - applications do not include browser binary
Tauri :: Uses modified OS dependent webview - applications do not include browser binary
Wails :: Uses modified OS dependent webview - applications do not include browser binary
Note: Electron is similar to NW.js only vastly more popular but I have never used it so not included here.
My personal starting point -
Non-professional hobbyist building personal desktop apps using vanilla JS/jQuery/Node (maybe look at Bun.js at some stage)
Need ability to access OS level features (window management/native menus/dialogs/file handling etc) without having to get involved in low level language and complex toolchains.
Distro aims (by the folk themselves) -
:: NW.js :: (Electron is similar)
QUOTE from website -
NW.js lets you call all Node.js modules directly from DOM and enables a new way of writing applications with all Web technologies.
:: Neutralino ::
QUOTE from website -
Neutralinojs is a lightweight and portable desktop application development framework. It lets you develop lightweight cross-platform desktop applications using JavaScript, HTML and CSS. You can extend Neutralinojs with any programming language (via extensions IPC) and use Neutralinojs as a part of any source file (via child processes IPC).
In Electron and NWjs, you have to install Node.js and hundreds of dependency libraries. Embedded Chromium and Node.js make simple apps bloaty — in most scenarios, framework weights more than your app source. Neutralinojs offers a lightweight and portable SDK which is an alternative for Electron and NW.js. Neutralinojs doesn't bundle Chromium and uses the existing web browser library in the operating system (Eg: gtk-webkit2 on Linux). Neutralinojs implements a secure WebSocket connection for native operations and embeds a static web server to serve the web content. Also, it offers a built-in JavaScript client library for developers.
If you can build a website, you can build cross-platform desktop apps too because Neutralinojs is a framework for creating native desktop applications with web technologies like JavaScript, HTML, and CSS. You can indeed use your favorite frontend framework (Angular, React, Svelte, Vue, etc.) for building your next Neutralinojs app.
:: Tauri ::
QUOTE from website -
Tauri is a toolkit that helps developers make applications for the major desktop platforms - using virtually any frontend framework in existence. The core is built with Rust, and the CLI leverages Node.js making Tauri a genuinely polyglot approach to creating and maintaining great apps.
:: Wails ::
QUOTE from website FAQ -
Is this an alternative to Electron?
Depends on your requirements. It's designed to make it easy for Go programmers to make lightweight desktop applications or add a frontend to their existing applications. Wails does offer native elements such as menus and dialogs, so it could be considered a lightweight electron alternative.
Who is this project aimed at?
Go programmers who want to bundle an HTML/JS/CSS frontend with their applications, without resorting to creating a server and opening a browser to view it.
The above quotes give an idea on the direction of focus of the different distros so I guess it is a choice between the color of the pill - blue or red?
So - my take on it -
I personally started with NW.js
It allows good desktop integration with web frontend and can use the excellent file management features of Node. For me it was far easier than Electron to use. Big plus is no compilation required if standard release binaries used and simple dev environment with discrete Resources folder for app assets supported. No need to get involved in low level binary code (C++) if comfortable dealing with Node ecosystem. Native menus/dialogs/etc are available to frontend JS.
Downsides are basically single maintainer and large app sizes due to the binary (Chromium) being included in the distribution.
Moved to Neutralino
Big plus is very small app sizes due to use of OS native webview (so no inclusion of browser required). No compilation required if standard release binaries used and discrete Resources folder for app assets supported.
Downsides are very small dev/maintainer team, lack of native menus and poor support of Node.
Looking at Tauri
Big plus is very small app sizes due to use of OS native webview (so no inclusion of browser required) also native menus and dev team seems more active. Node is supported so may not be necessary to get involved in Rust backend as OS specific features (Menus/Dialogs/etc) are ported to frontend via API. Possible future plus is mobile support.
Downsides are compilation to single binary is only option so no support for discrete Resources folder for app assets. Any shortcomings in frontend (JS) functionality may have to be addressed in the backend which is Rust so the bar goes up.
Tauri and Wails are very close in concept but when I tried a simple web app using classic JS linking in a production build Wails choked as it only supports JS modules whereas Tauri just worked (in fact right through to a packaged DMG) so I have focussed on Tauri so far. Wails would probably support classic JS linking but would require changes in the GO backend which at the moment is out of my league. Dev on both distros is rather active and it may not be too long before the frontend JS feature set for both is pretty similar so it may be a toss of the coin on which to use (Rust or Go) if compilation is acceptable.
Update: Wails will support classic JS linking if advantage is taken of the default Vite setup within the build process. Basically the linked files need to be in a 'public' folder within the dev root and Vite will then automatically use the files - this functionality is not enabled unless the public folder exists.
I'm still comfortable using NW.js for larger apps as it is quite solid and easy to use but for smaller apps I definitely want a smaller binary size preferably without requiring compilation. At this stage Neutralino wins out as no compilation required but issues with native OS desktop functionality exist (menus/dialogs/webview integration) so the field for a distro with small app sizes has widened to include Tauri and Wails (all three N, T and W have small binary sizes).
Both Tauri and Wails have very active dev teams albeit not large and are beginning to overhaul Neutralino in areas such as webview integration/native menus/dialogs/etc but both come from the position of backend devs (Rust and Go) wanting to use frontend JS for UI purposes whereas Neutralino is maybe more focussed on frontend JS devs who don't necessarily want too much involvement with backend stuff. The price to be paid for Tauri/Wails is compilation in a single binary.
Wails.js
A lightweight client/server desktop application environment (using html/javascript/css) leveraging the native platform browser.
Wails section HERE Wails stuff
Tauri.js
A lightweight client/server desktop application environment (using html/javascript/css) leveraging the native platform browser.
Tauri section HERE Tauri stuff
Neutralino.js
A lightweight client/server desktop application environment (using html/javascript/css) leveraging the native platform browser.
Neutralino.js section HERE Neutralino.js stuff
NW.js
A fusion of Chromium browser technology with Node.js which provides a full client/server programming environment using javascript.
NW.js section HERE all sorts of NW.js stuff
Yahoo Widget Engine (ex-Konfabulator) (Legacy)
Recently I've found the Yahoo Widget Engine quite useful for odd widgets.
Below are some widgets that I have made for personal use and you may find useful.
Please note that there is no guarantee that they'll work perfectly ...
Widgets are usually developed for XP however some are suitable for OSX as well.
Widget downloads are HERE
UPDATE:
YWE is now a legacy coding app since Yahoo abandoned it years ago however for the hobbyist it is still a very effective
tool for making desktop widgets and mini applications. The manual for the latest version (4.5.2) is excellent and because it essentially used web
technologies it will still function on newer OSes.
For current status see - Here
VB 2005 stuff (Very legacy)
Odd stuff encountered whilst using VB 2005 Express.
Simple solution for drag and dropping a single item within the same listbox.
This was found at
http://vbforums.com/showthread.php?t=492618 posted by a chap called
Rykler. MSDN and elsewhere have more complex variations but this works
fine for the simple requirement within a listbox. Initially it didn't
work for me - the item would drag with the appropriate mouse effect but
the DragDrop wasn't occurring when the DragOver was ended. Of course it
turned out to be a silly error by myself - the old DragDrop Sub was
renamed but I didn't rename the handle so the DragOver was ending and
using the old DragDrop handle to go into hyperspace!
eg:
Private Sub listbox1Renamed_DragDrop(ByVal sender As Object, ByVal e As System.Windows.Forms.DragEventArgs) Handles listbox1.DragDrop
Should have been - Handles listbox1Renamed.DragDrop
Good Code -
Click mouse to select item -
Private Sub listbox1_MouseDown(ByVal sender As Object, ByVal e As
System.Windows.Forms.MouseEventArgs) Handles listbox1.MouseDown
listbox1.DoDragDrop(listbox1.Text, DragDropEffects.All)
End Sub
Drag item holding mouse down -
Private Sub listbox1_DragOver(ByVal sender As Object, ByVal e As
System.Windows.Forms.DragEventArgs) Handles listbox1.DragOver
e.Effect = DragDropEffects.Move
End Sub
Release mouse button to drop -
Private Sub listbox1_DragDrop(ByVal sender As Object, ByVal e As
System.Windows.Forms.DragEventArgs) Handles listbox1.DragDrop
' Drops before item that pointer is over
listbox1.Items.Insert(listbox1.IndexFromPoint(listbox1.PointToClient(New
Point(e.X, e.Y))), e.Data.GetData(DataFormats.Text))
listbox1.Items.RemoveAt(listbox1.SelectedIndex)
listbox1.Refresh() ' not strictly required
End Sub