> This is somewhat similar to what Electron accomplishes, but your backend is in Rust rather than JavaScript, and the user navigates to the app from their browser.
An option in the middle is webview[0] which will "appify" it by using OS-native browser lib so you don't have to carry Chromium, V8, or all the multi-process ugliness but you still get the web stack.
Also everybody, don't forget to check your Host headers when building apps running HTTP daemons locally or you'll be open to DNS rebinding attack. And if your use case can support it, a random port is nice too.
> This is somewhat similar to what Electron accomplishes,
What? This is nothing like Electron. What it's like is shipping the `node` executable to the end-user along with a .js script. The whole point of Electron is that it bundles a browser.
The parent already covered your whole objection in their comment "but your backend is in Rust rather than JavaScript, and the user navigates to the app from their browser." -- and went to provide even more context and info that shows they perfectly know the distinction.
The parent's point is not that it's like Electron in that it bundles a browser, but that it's like Electron in that it allows you to bundle a web application into an executable.
The difference is that it doesn't include the rendering engine along.
Was OP's quote, but "somewhat similar" still applies. For some, the whole point of Electron is they can see web pages...meaning maybe there isn't only one "whole point" of it and therefore to some "nothing like Electron" is incorrect.
Well, Chrome doesn't really allow chrome.dll to be easily used. Electron has deep requirements on Chromium for V8, IPC, webview, customer protocol handlers, etc IIRC so it can't just easily switch browser engines. I'd say if you want this, the Chromium project would have to prioritize a stable Chrome ABI from their shared lib which I doubt they would do. And it still doesn't solve the extremely mem-bloated approach they take to serving the web stack. So for that, the Chromium project would have to prioritize better runtime feature gating for mem reduction and maybe revive first-class support for single-process mode, which I doubt they'd do. And even then, you're carrying node.
To sum up my rant, I'm afraid the fast moving web stack, coupled with the fact only a few companies can keep up, coupled with the fact that those companies are laser focused on their own browser use case and not embeddability combine to make this incredibly common desktop use case still suck. In the meantime, just hope these OS engines stay minimal and don't fall too far behind the standards you want.
This is what makes me want to see something like Electron developed over Firefox internals.
Packaging my own browser with my code so that I am now developing toward ONE client instead of any random thing that can speak http, and at the same time, being able to take the core of my app, tweak it a little, and plop it out on the web without a complete rewrite ... that is completely amazing. It's what I've wanted since forever.
Even better would be the ability to optionally include features in my build. Like if I don't NEED WebGL, the MIDI and Audio APIs, etc, etc ... it'd be pretty nice to be able to optionally exclude those from the bundled browser to minimize size.
However, I don't want to be welded to google. Mozilla's codebase seems ripe for such a development.
> This is what makes me want to see something like Electron developed over Firefox internals.
Tried, but abandoned presumably based on prioritization: https://github.com/mozilla/positron. I was hoping Servo would help here, but from the outside looking in, the pieces are being moved into FF proper and the Servo browser's priorities have been reshifted to being a part of the VR team. Sure they're still making a general use browser (and that's quite a feat), but the embeddability game may suffer (I believe conforming to the CEF iface that was there original goal has become stale).
Having a browser installed isn't the problem. The problem is having a specific version of a specific browser installed because that's the only thing you've tested against.
(I'm not condoning this, and haven't worked with Electron myself, but that's my understanding of the motivation.)
But what happens if your js stack requires a feature that is only in chrome 65+ and someone elses stack relies on a feature that was depricated/removed in Chrome 60? Furthermore, does that mean if a user goes to task manager and ends the task of chrome, that your app would be killed too?
Which browser? Why do I want to spend my time making my desktop app run in Chrome and Firefox and Internet Explorer and Edge... and all the old versions of these. Plus the fun of saying to my customer "oh you have to upgrade your OS before you can run our app, sorry".
> ... DNS rebinding attack. And if your use case can support it, a random port is nice too.
Ah, that's a good explanation as to why zserge/webview recommends serving using ephemeral ports.
Also, wanted to pull in from the readme: webview supports interacting with the javascript environment directly, so a web server isn't strictly required.
> With all that work why not just link to gtk and build on that?
Because the packaging and distribution experience sucks. Seriously, that's all it is. Make it so that I can run one command and turn my GTK app (written in a language that has a decent package manager and library ecosystem i.e. not C or Vala) into single-file executables for all major platforms, and you'll take the marketshare back from Electron.
I'll agree that packaging desktop apps is still annoying, but traditionally the packaging experience is handled elsewhere in your stack. I'm not sure that expecting a widget API to provide lifecycle management is the wisest choice...
Electron is a full stack, yes, but GTK slots into any number of stacks. Not my area but putting together a build script that outputs different formats (for an app that just requires some file copying for install) can't be that bad. Python in particular has lots of options for cross-platform packaging and distribution. (py2exe, etc)
> I'm not sure that expecting a widget API to provide lifecycle management is the wisest choice...
From a developer's point of view, Electron solves that problem. It's not about what the underlying library is, it's about what the whole package does.
> Not my area but putting together a build script that outputs different formats (for an app that just requires some file copying for install) can't be that bad. Python in particular has lots of options for cross-platform packaging and distribution. (py2exe, etc)
All the pieces are there, but no-one's put them together in a nice, well-supported way. Packaging a python application like that is a bunch of tedious manual gruntwork that's easy for a beginner to get wrong.
> With all that work why not just link to gtk and build on that?
If you're asking "why not link to gtk webkit?": because I don't want to statically compile or ship with the entire browser (not to mention Windows compat). If you're asking "why not build your app on gtk instead of web tech?": there are a million reasons and this question happens frequently, so not really sure it's worth rehashing here.
> Why should a desktop app even care about host headers?
It's one way to prevent DNS rebinding attacks. You can employ other methods to ensure the client is "authenticated" to use the server. OP's app listens on port 5000. I can have a page on example.com:5000 and set the DNS zone to a really low TTL change its A record to think it's 127.0.0.1 after first load thereby letting the browser think I'm same origin w/ just an IP change, then I can ajax call to example.com:5000 to access the local daemon. That's how DNS rebinding attacks work and host header checking is one way to for the local web server to prevent other pages from accessing it. Project Zero is finding lots of local HTTP servers that are reachable from web pages.
well I wouldn't recommend webkit-gtk either, but there's a whole lot of other controls and stuff in gtk that were designed for desktop apps. Just seems silly to have to go through all those lengths just to preserve a JS/HTML/CSS workflow when you can get the same thing, with less work (edit: and fewer potential vulns) with gtk and rcstyles.
........ huh? GTK uses native controls on Windows and Linux (and I think Mac?)
The fact that you have to care about DNS rebinding attacks on a desktop app, where presumably that app does not do anything special with the network or DNS, is all kinds of smelly to me.
I wish I could show off some of my work in this area but we took an old JS/HTML/CSS 1.0 stack and did our 2.0 in GTK (with all the fancy graphics and everything), and we are much happier now -- a ten-year-old single-core Celeron system with little RAM runs our stuff great (whereas before we had issues)
Just the size of the tiny bit of C code you'd compile with. It uses shared libs already on the system (though not familiar w/ how many distros have gtk-webkit2 on Linux).
An option in the middle is webview[0] which will "appify" it by using OS-native browser lib so you don't have to carry Chromium, V8, or all the multi-process ugliness but you still get the web stack.
Also everybody, don't forget to check your Host headers when building apps running HTTP daemons locally or you'll be open to DNS rebinding attack. And if your use case can support it, a random port is nice too.
0 - https://github.com/zserge/webview 1 - https://en.wikipedia.org/wiki/DNS_rebinding