This is the first I've heard of it. So I can't say much about the project itself. However, by the look of it DeskGap is at least taking the right approach, where as most these other projects (there seems to be a new one every week) miss the mark.
Electron Pros:
1. Consistent JS runtime/API
Electron Cons:
2. Huge distributions (bundling a full browser)
3. No re-use of components (every app is huge)
Electron Pro?/Con?:
4. Consistent rendering / WebKit monoculture
By the look of it DeskGap keeps Electron's biggest pro and solves its two biggest cons. The only "issue" is that there may be rendering inconsistencies. However, given we want to avoid a WebKit monoculture, I see this as a pro more-so than a con.
With that being said Microsoft have themselves migrated to WebKit; so the WebKit monoculture looks likely regardless. For consistency I guess that's even another tick in DeskGap's corner, although it'd be nice if on Linux (for example) it could use Firefox when present.
Carlo is interesting for a similar reason, but perpetuates the WebKit monoculture.
I'm glad to see that you are considering the Qt component. Qt looks good on Gnome, KDE, and other desktops. It is also relatively lightweight for what it offers.
> Nobody wants to be testing against multiple browser/rendering engines in 2019.
That's why DeskGap uses EdgeHTML on Windows. With toolchains such as webpack and babel, building an app that runs on WebKit and EdgeHTML (which is going to be replaced by Chromium[0]) can't be that hard.
> Nobody wants to wait for a vendor to update their implementation when Chrome has the feature available almost immediately.
DeskGap doesn't mean to be a complete replacement for Electron. But after a glance of Electron Apps[1], I suppose many simple apps do not require start-of-art features.
Strangely, that would likely make it most conformant on Windows. I can't imagine that KHTML is up to date in terms of specifications (but I could easily be completely wrong about that) and Apple/Safari is taking tips from Microsoft during their IE days.
It would seem that the platform differences would be quite large, but at least the JS engine would be consistent.
DeskGap is another try to build an lightweight alternative to Electron. Compared to the existing attempts [0, 1], I choose not to go that far and bundle a real Node.js with it[2].
And to battle test the framework, I wrapped squoosh[3] into a desktop app[4] with DeskGap, and successfully submitted it to the app stores.
Howdy, can you compare the system-side webview with https://github.com/zserge/webview? Specifically, what control do you use on windows, MSHTML or have you incorporated the recently-freed-from-UWP (I think) Edge API?
EDIT: Appears the latter [0]. Great work. I wonder how this affects bundling...does this make it a UWP app?
What happens if you run an EdgeHTML-using application on Windows 7 or 8? I noticed that the EdgeHTML control in WinForms and WPF is not a drop-in replacement for the old WebBrowser control (i.e. it isn’t a subclass, so you must use one or the other, but Microsoft didn’t document the best way to switch between controls based on feature-detection).
When you try to call the API, it will fail as it’s not there. The precise failure mode will depend on the application. One possibility would be to crash outright. Another would be to try the EdgeHTML control, then fall back to MSHTML. Yet another would be to try EdgeHTML, then complain in an alert, notifying the user of the requirement for the new version of Windows.
The webpage mentions the app size, but no mention of RAM usage, which is a bigger concern with Electron apps to me. Can you comment on how it compares?
Based on my experiences of using Safari, Edge and Chrome, the RAM overhead is lower. However as the app gets more complex the overhead becomes irrelevant.
So for now I consider DeskGap a good place for simple apps. But if you start to build something like VS Code, the RAM usage can’t be good, either.
I have been watching these types of tools (desktop js frameworks) and I'm glad the DeskGap docs[0] explain the difference between existing tools like Electrino and Quark although the most notable difference is that those two projects are no longer maintained.
I just added DeskGap to my list of Awesome Desktop JS frameworks[1].
It has barely started and still pre-alpha, but I would add revery[0]. I know the team working on it and they have a good history of finishing what they start.
Because if it uses the same browser binary as your other web apps (tabs or other DeskGap apps), the OS can share memory between them. Not possible with electron since every app bundles its own Chromium binary.
Of course they can. This is what OS engineers have spent decades thinking about and optimizing. And then stuff like Electron appears and circumvents all those optimizations. Which is the main reason I dislike it.
Sure, but with sandboxing and technologies such as Firefox Containers, containers in general (such as Docker), and VMs (together with a secure enclave such as utilized in Qubes) it can all be thrown in the trash bin. Its just a matter of time until that's the norm. iOS is already on top of doing sandboxing well.
Both code memory and data memory will be shared by any modern OS. The code memory will of course be shared since it's the same, and the data memory will be shared until modified. Then that memory page will be copied for the process that changed it (check out copy-on-write).
And then there's disk memory, which isn't as important IMO but still it will of course be smaller since you don't ship the whole browser stack for each application.
Shared memory is "a method of conserving memory space by directing accesses to what would ordinarily be copies of a piece of data to a single instance instead, by using virtual memory mappings or with explicit support of the program in question. This is most often used for shared libraries and for Execute in place (XIP)" according to Wikipedia.
