> 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)
Why should a desktop app even care about host headers?