I'm the author of the post and I should also say that I don't love Electron. It's a practical choice for getting an app of the ground, but I want something more lightweight eventually.
I see it as a stop-gap until I can invest more resources into something more lean. But I'm focused on the product right now, not rewriting the world and wasting time because of engineering ideals.
I agree with your statement but just have never really seen it work that way in real life.
Slack is the best example. An app that just 'works' in Electron and the stop-gap became the permanent solution for eternity et voila -> still huge valuation and IPO.
I am afraid once you go Electron, most will stay Electron.
Whatever it ends up being it has to be web-based. I'm definitely not going to rewrite the app.
However, if something were to come along that uses the user's local webview instead and provided a way to bundle a node server with it, I could absolutely switch to it.
In fact, I've played with the idea of providing an app that only sits in your menubar and runs the server, and opening the app just opens a tab in your browser. But most users don't care as much about all this as we think and would find that odd.
You're right though - if something is working well enough it probably will end up sticking. Slack just goes to show that it's probably Good Enough despite what we feel about it.
Someone tried that with Electrino, but there hasn't been any activity in 2 years.
That only deals with memory and disk use though.
CPU and battery use under 'load' will still be through the roof compared to native apps. I put load in quotes because even entering text or scrolling creates massive energy consumption spikes on Electron.
Oh and your UI will still be sluggish too.
To be clear: I'm not hating on your app or choice of Electron, just be aware most of the drawbacks are here to stay.
Even Microsoft with all their engineering prowess can't seem to fix them (see VScode vs Sublime), and they are already using a heavily customized and optimized Electron.
You can ship the node binary, then have the "app" open up in "chrome-less" mode (no browser bars, like with electron). It's supported in IE, and Chrome. Firefox also supports "chrome-less" but only for URL's that start with file:// meanwhile some browser features require https:// and http://localhost/ is not good enough. While it is possible to build a local web app, browsers could make it easier to do so. Also take a look at feature phones that run forked versions of FirefoxOS, it's a growing market. Where apps are basically packaged local web apps. There's also Chrome apps, but they have been deprecated (never build something on top of Google tech :P)
There have been multiple webview-using equivalents through the years.
A big part of why Electron-likes have succeeded so widely where those did not is because they suffered from absolutely massive fragmentation, both in features and in performance/bugs. Electron (comparatively) does not, because it bundles its own full stack. You have to deal with upgrades to it when you choose to do so, but not "everyone simultaneously has a different version of their webview, many of which you have never seen and cannot reproduce, and you always have to deal with them all".
I used a similar api-based approach to have Electron host C# and Python backends[0][1]. The main difference I think is that I went with GraphQL for the api layer instead of Electron's ipc mechanism, including random port selection and a simple bit of security handshaking to prevent malicious sites from just hitting an exposed port (the goal being to strike a balance between showing that security matters and not over-complicating what is intended to be a simple boilerplate example).
Given their BUILD talk, with comparisons against Electron hungry resource usage, it wouldn't surprise me if VSCode eventually migrates to React Native.
Yeah here's the problem. Eventually the thought of rewriting the electron app native becomes too daunting. It's grown to large. Then you're shipping bloatware for life.
That’s the right mentality. I'd say don't change it if it works (and is nowhere near as bad as Slack). If the difference in practice is marginal it‘d provide no real value.
Thanks for sharing. What is the advantage of using socket based IPC to communicate between client and server, instead of enabling nodeIntegration on the client process and using the remote library?
As long as you don't block in the main process and take advantage of Promises and even WebWorkers, why is another dedicated process needed?
It'd be nice if there was a better abstraction of Qt for cross platform usage. Something like how React components work, have a library of common layouts, could even specialize in Material to make a more narrow scope. Basically pick your frame layouts and can tie in logic to those possible interactions.
Yes and no, it's the right level of abstract, but it's still Qt. I think the issue here is that it's the unfamiliar. If it had a layer on top of that where you could use json config files, style with sass files, and ad logic in JS, it'd make all the javascript boys come to the yard.
> If it had a layer on top of that where you could use json config files, style with sass files, and ad logic in JS, it'd make all the javascript boys come to the yard.
QML is already JS (ES7) so you can code your logic in it (though 95% of people opt for doing it in C++ both for the speed and the static typing). Sure, there's no SASS but I would argue that the QML offering is much clearer than CSS - http://qmlbook.github.io/ch04-qmlstart/qmlstart.html.
It's 100% unfamiliarity with C++. Because you always end up doing logic in C++. JS is there in small bits to tie things together - the original purpose of JS in the old Web.
Not relevant, but I'm really glad you started blogging again.
I would often point other people to your blog as a good resource for learning javascript.
I don't actively use typescript, the example is focused solely on the architecture for adding a background process. Typescript seems like a separate concern?
I see it as a stop-gap until I can invest more resources into something more lean. But I'm focused on the product right now, not rewriting the world and wasting time because of engineering ideals.