Hacker news unofficial desktop app(github.com)
github.com
Hacker news unofficial desktop app
https://github.com/bjarneo/HNU
4 comments
Note: This "desktop app" is a web app built on Electron, which is a JS library that runs chrome for you. So this app will clock in at roughly 200+ mb ram, in addition to what your system is already running.
Yeah, it's not a desktop app but web app running in a separate browser that has no chrome. HN integration in Emacs is a desktop app because it actually provides a different way to interact with HN and this is the same web page, just rendered in a silo'd window.
Since this is an Electron-based app, I figure this is as good a place as any to ask something that I don't understand about Electron...
How well can an Electron-based app fit in with the underlying operating system?
If running on a Mac, can an Electron-based app expose itself via AppleScript so that other applications can interact with them? If running on Windows, can it expose itself via COM? On Linux can it register itself with DBus (I'm not sure if this even makes sense - what's the Linux equivalent of COM/AppleScript)?
On the Mac, does the stuff in the Services menu work? Do text fields get automatic spell-check? Can I double-tap 'fn' to start dictation? Can it expose itself to the Accessibility stuff in a meaningful manner?
These things don't make sense for all applications. I can't think of why I'd want to interact with an HN application via AppleScript (or COM), for example, but there are other types of applications where being able to do this would be great (Excel and Word base their entire macro facility on COM, for example).
I can see wanting to use Dictation in an HN app as it might make commenting easier for some people. Same goes for the text field spell-checking.
I guess the big question is, where can an Electron app fit in the spectrum between 'web site rendered in a dedicated application' and 'full-blown Windows/Mac/Linux desktop application'?
How well can an Electron-based app fit in with the underlying operating system?
If running on a Mac, can an Electron-based app expose itself via AppleScript so that other applications can interact with them? If running on Windows, can it expose itself via COM? On Linux can it register itself with DBus (I'm not sure if this even makes sense - what's the Linux equivalent of COM/AppleScript)?
On the Mac, does the stuff in the Services menu work? Do text fields get automatic spell-check? Can I double-tap 'fn' to start dictation? Can it expose itself to the Accessibility stuff in a meaningful manner?
These things don't make sense for all applications. I can't think of why I'd want to interact with an HN application via AppleScript (or COM), for example, but there are other types of applications where being able to do this would be great (Excel and Word base their entire macro facility on COM, for example).
I can see wanting to use Dictation in an HN app as it might make commenting easier for some people. Same goes for the text field spell-checking.
I guess the big question is, where can an Electron app fit in the spectrum between 'web site rendered in a dedicated application' and 'full-blown Windows/Mac/Linux desktop application'?
Not an electron, or node developer, but based on my experience: As long as there's a library to do this available for node, it can do all those things, since the node part of the software can talk to the browser part, and the browser part can talk back. So for anything you'd need to have the browser talk to the OS to, if node can do the talking, then the web page running in electron can do it too, via node.
So then the question becomes, how many developers take the extra effort to make their Electron application a first-class citizen on each platform?
My guess is that almost none of them bother. I looked at the documentation for Atom, which seems to be the flagship Electron application, and there's no mention of its API being exposed to the system (AppleScript on MacOS and COM on Windows), even though it does have a very rich API.
A quick search seems to confirm that there is no useful AppleScript support:
https://discuss.atom.io/t/applescript-support/1439
https://discuss.atom.io/t/accessing-the-contents-of-a-window...
The second discussion mentions that there is a dictionary, my guess would be that it comes from the underlying Chrome browser. Interestingly enough, looking at the dictionary for Google Chrome, it appears that they have made an effort to expose things that make sense for a browser to expose to AppleScript.
My guess is that almost none of them bother. I looked at the documentation for Atom, which seems to be the flagship Electron application, and there's no mention of its API being exposed to the system (AppleScript on MacOS and COM on Windows), even though it does have a very rich API.
A quick search seems to confirm that there is no useful AppleScript support:
https://discuss.atom.io/t/applescript-support/1439
https://discuss.atom.io/t/accessing-the-contents-of-a-window...
The second discussion mentions that there is a dictionary, my guess would be that it comes from the underlying Chrome browser. Interestingly enough, looking at the dictionary for Google Chrome, it appears that they have made an effort to expose things that make sense for a browser to expose to AppleScript.
If you select "Add to desktop..." under "More tools" in Chrome and check the "Open as window" option it will look the same as this :)
What is the benefit of this over using a browser?
None, given that it essentially runs in a browser anyway (Electron). I suppose it's very useful if you have ~200MB of RAM and ~80MB disk space that you really want to get rid of.
I hate Electron. :-|
I hate Electron. :-|
None, given that it essentially runs in a browser anyway (Electron).
Oh, there goes that dream.
Oh, there goes that dream.
Qt/GTK/WinForms or GTFO!
WPF/UWP instead of WinForms and I agree. I don't even get why so many people like writing web apps, I feel a hell of a lot more comfortable working with a proper widget toolkit (my preference being GTK or WPF) without the constraints enforced on me by a browser and JavaScript.
I think that web app benefits vastly outweigh the constraints. Distribution is easy (give people the URL), the app is always up to date, and it's cross platform. Unless you absolutely need the features and/or speed of a device, you should seriously consider a web app vs. a not web app.
It's because there are a lot of people here obsessed with reaching the largest possible audience they possibly can. And since every brother and their mother are on mobile, or, at least, a web browser...
The way I see it, mainstream masses are finally (FINALLY!) leaving the world of desktop computing behind, so now it can return to the nerds and people who just wanna do shit
The way I see it, mainstream masses are finally (FINALLY!) leaving the world of desktop computing behind, so now it can return to the nerds and people who just wanna do shit
With the recent popularity of Electron, I wonder why less attention has been given to Qt Quick. The JSON-like syntax of QML as well as JavaScript should be very familiar to web developers and you get software that looks much more "native" than what is achievable in the DOM (well, without reasonable effort).
Right?! Qt Quick is faster for prototyping, at least as flexible, _much_ faster to run, still very cross-platform....
(I like Qt)
(I like Qt)
I can write my react component and use it in mobile native version, desktop electron, mobile web, web desktop. Can you do the same with Qt?
I don't get why people have so strong emotion for Electron.
I don't get why people have so strong emotion for Electron.
I guess at the very least it'd be recognized as a separate window/app by the OS window manager, which might be convenient if you like to keep it open all the time and alt-tab to/from it.
However, at least on OS X, you can just use something like Fluid if that's all you want (http://fluidapp.com/).
However, at least on OS X, you can just use something like Fluid if that's all you want (http://fluidapp.com/).
Exactly what I needed. Thank you very much.
A browser is like a buggy mini-operating system that hogs resources, tries to replace native applications like PDF readers, word processors, and email clients, and uses JavaScript as its system language. Client applications circumvent the hell of modern web browsers. The benefit is not needing to use a web browser.
Wish there was some kind of a "Electron kitchen" where you could easily make your own app stating which website you want to use in this isolated way, without having to learn about Electron.
As mentioned earlier, there's Chrome's "Add To Desktop" option
Why not just run Chrome in app (or kiosk) mode?
I use this for reading my gmail. I use the --user-data-dir flag to prevent the "app" from interfering with my other browsers.
I use this for reading my gmail. I use the --user-data-dir flag to prevent the "app" from interfering with my other browsers.