Essential Electron
jlord.us
jlord.us
We provide a B2B service that relies on communication with a locally installed service running on the users machine. This kind of approach is one that has been heavily bombarded with new features and deprecations leaning towards a more secure web by most browser vendors, which is actually very justifiable.
The most recent one was Chrome targeting to restrict app cache usage, which we rely on currently, only to documents served through HTTPS. Given that we have an app that uses a local service that needs to work offline, we cannot use HTTPS for that without messing with stuff that needs Administrator privileges, which we really want to avoid because headaches.
So we figured we need a more flexible approach that is not so restricted as a web app living on the browser, but we already have a product. Here comes Electron, and in a couple weeks work, mostly testing things, we have it. We now deploy both to the web (just in case) and are rolling customers to the desktop.
Other features that added a lot of value where:
- No localStorage limit, was starting to become an issue, now we have breathing room to migrate to other storage
- Auto Update, actually took care a long time complaint for the necessity to keep downloading new versions of the local running server, which we now package alongside the app
- node process running directly on the client opens up a lot of new possibilities
After all, the dominant OS before mobile was Windows. Remember Winamp skins? Skins for every possible app on the face of the Earth? Opening up Skype, which had its own theming, Yahoo Messenger, which had its own theming, Office 2003, which had its own theming, etc., etc., etc.
Except for Mac OS fans, most of the world didn't really care.
Let's not even mention Unix.
But yeah, Mac OS users were particularly obnoxious there, as usual.
Except that they don't. If that were true then we would see a lot more consistency in desktop app styles.
The typical desktop computer experience hasn't been visually consistent since the mid 90's. Most young people have never used a computer where most of the apps had the same style.
Just because it was used does not mean people didn't care. They had no say or choice in the matter.
One interface to rule them all.
What does that even mean?
GUIs have quite obviously commanded a vast lead in popularity over terminals ever since they were invented. So, they don't "rule" in that sense.
Do you mean to say that you somehow "rule over the GUI using peoples of the world" because you use a terminal and maybe you write code or do sysadmin work that all the GUI users have to report to? I doubt that's actually the case because your boss is probably a GUI user who tells you what to do.
I don't think the terminal is ruling anything. I think some people are just fond of trite sayings that seem to enhance their own stature.
You mean the nightmare that is typing an address into a input (or just searching on Google) and being able to near-instantly use an app, even really bad applications that we all complain about?
That nightmare? I'll take it over per-platform applications that have different UI paradigms and that I must install/support manually myself.
And of course, things can be done to cut the friction of installation down to a minimum, e.g. using fully self contained binaries, distributing zipped executables instead of installers, and including robust self update capabilities (on platforms without package management).
Yes, it's called Freepascal using the Lazarus IDE. Native, cross-platform self-contained binaries that run fast and don't using oodles of memory or require massively-sized binaries.
Why is it not more widely used? Because of that word Pascal. That's enough to dismiss it in the minds of many developers. Modern Pascal has many of the features we associate with modern languages e.g OOP and generics. But Pascal's syntax, age and verbosity mean many developers will never give it a second look.
Better yet, why not make the architecture into a single shared "Electron windowing server" process that all Electron apps run "on", such that I don't end up running 7 different copies of Chrome?
(Honestly, Chrome itself could have become said runtime with its packaged apps, plus the (only ever experimental) standalone App Launcher install mode. I guess that's not the path they wanted to go down.)
And traditionally, management of such shared runtimes on anything but Linux sucks a lot. Remember all those Windows apps that tell you "Java Runtime Environment 1.5 required" and then they kind of leave you to figure out how to install that? Not exactly user-friendly.
And at the end of the day, regardless of your OS, you end up with 4-5 different JRE versions installed because compatibility is not perfect, so each app locks down to a specific version instead of accepting a newer JRE.
.NET isn't any better. I have 5-6 different .NET runtime versions installed and I can't remove any of them because each app requires a different version.
The method of vendoring all your dependencies may not be the most efficient, but it's certainly the most convenient one. It seems users these days care more about how much hassle it is to install than how long the download takes or how much RAM it uses.
Static linking the runtime also has significant downsides. One of the worst is how it puts the burden of pushing runtime security updates on the app. Frequent JRE downloads because of security patches is annoying, but downloading N copies of chrome every for all of your apps is insane.
Of course, this also requires that each app update itself to be compatible with the new versions every time there is a security patch. The entire point of including a specific version of chrome is to avoid these updates, so the very idea of Electron implies the app is not designed for security.
Not to mention the additional headache of having to install dependencies which can be an annoyance on some platforms.
At this point in 2016 the number of people that are negatively affected by an electron app's size on disk is significantly less than would be negatively affected by having to muck with installing "Electron Runtime version 52" for app A but need to lock it to "Electron Runtime version 50" for app B.
Also, I'm not so much concerned with size-on-disk as I am with
1. redundant versioning leading to redundant network bandwidth costs (e.g. I don't want to find out that I have 20 different apps that want to download a 100MB update—99MB of which is the same Electron binary—every time Electron itself updates.)
2. memory usage (30 versions of the Electron runtime means 30 copies of Electron taking physical memory. 30 apps using the same Electron runtime means 30 copies of Electron in virtual memory sharing the same physical pages.)
Also, some electron apps will modify the "browser" part.
As for download sizes, aside from the first download all updates can use Delta update packages and I believe this is built in.
Re memory usage, with sandboxing the way it is today I'm not convinced you would save all that much memory unless you were running over 10 different electron apps, and even then compared to the total memory usage I feel it would be insignificant enough to not warrant the "JRE architecture". I don't really have anything to back this up, its just a hunch.
You throwing everyone that uses node.js into a big bin labeled "only knows javascript cult" is childish at best.
There are obviously trade offs going with a "globally installed runtime" vs "including the runtime with each application". JRE takes the former, electron the latter. Each with their own set of problems, each providing different solutions, each with their own reasons, applications, and "target audience".
The thing that's big about Electron is it allows web developers to use their existing skills to create desktop apps.
A lot of web developers would like to make desktop apps, but aren't willing to learn a new systems language to do that, especially when there's a solution that lets them use the JS + HTML + CSS they already know.
Also it lets you reuse parts of your web app (or build part of your web app while building your desktop app). For something like Slack, or if Google were to make a desktop version of Docs, it makes a lot of sense to use Electron because you already have your web app and you want your desktop app to be consistent with it.
I've used Ionic with a very small team to make a web app and mobile app from the same codebase. The client asked if we could also make a desktop version for them, and instead of taking months to build one and make it consistent with the web/mobile apps, it was just a few days of learning to wrap it up with Electron. That was really neat!
And the beauty of Electron is that you can still write all your actual logic in C/C++ and use Node's FFI to bind it to your UI.
(Qt is transitioning to the same model with its HTML+JS based Qt Quick orchestrated from native code; but it's far less production ready than Electron right now.)
A developer that only knows js is unlikely to be competent (beginners aside).
Oh, don't get me started…
Yes, that's a problem. But Electron can hardly be blamed for it. They'd use XULRunner if it didn't.
It's really hard to beat HTML in terms of flexibility.
Generally, I find the way these apps look very attractive, much more so than any other cross-platform apps I've seen before (Swing, AWT, QT etc).
While I agree the download size is less than ideal, I can't argue against it being a good compromise at the moment.
Try opening a 20MB SQL Dump. Fortunately, Atom will show a warning. If you click past that, everything will freeze while Atom eats up more than a Gigabyte of memory. Don't turn on syntax highlighting, or Atom will lock up and eat all your CPU.
When you are done listening to your computer's fan, quit Atom. Then kill the "Atom Helper" process, which for some reason keeps on eating CPU even after you quit Atom.
Now open the same file in BBEdit, or any other native Text Editor... and the file will open instantly, the app will be responsive, and syntax highlighting will work, because 20MB really isn't a file size that should be an issue for a text editor.
Note that Google will stop supporting Chrome Apps in 1 year or so.
http://blog.chromium.org/2016/08/from-chrome-apps-to-web.htm...
Performance is sluggish on both the high end machines I use regularly (Dual xeon workstation, and an i7 6700k with 32GB/16GB ram respectively). The search functionality brings the UI to a halt, and scrolling through the message history isn't remotely close to smooth. Startup times are also quite long. I closed the app, and re-ran it. it was 5 seconds before the window appeared, and another 5 before my chat window was populated.
But there are just some fundamental differences between desktop apps and web apps.
Just like a website, the Slack desktop app is slow. Open Apple Messages, and you'll see all your messages instantly. Open Slack, and you'll be greeted by a loading screen, followed by a loading screen with an insightful quip. Click on a different channel, and you'll see another loading screen, followed by another loading screen with a different funny message.
And then there are all these inonsistencies... Holding down the mouse on a popup menu doesn't work; you need to click to open, then click again to select. Resizing the sidebar is not possible.
The content view with the bubbles is a web view. All the other views (sidebar, input field, etc.) are native controls.
I guess this is a sort of "best of both worlds" approach. You have all the flexibility of HTML & CSS for complex content layout, and you get performance and usability of native sidebars and text fields.
I have had very little problems with the actual coding part, but installing, especially on Windows, and updating for new versions is voodoo. Every time I think I have it all figured out it breaks.
That said, the problem right now is still if you ever need any node native dependencies because electron because building those seems to be complicated on every platform. Right now my quest is to avoid native dependencies that aren't in the prebuilt electron.
It's interesting because Cordova is a tiny bit better at handling native plugins. Unicorn dream is that I'd really love so see some sort of convergence in Cordova and Electron plugin approaches, especially when it comes to native dependencies. (For various reasons several major projects I'm working on need to target both Cordova and Electron; it would be nice if it were a more seamless experience.)
But running it took six hours and it crashed. Found online somewhere that it can't handle the size of electron, too many nested directories I guess.
Tried just updating and it appears to have worked, but now everything crashes and the error message isn't very helpful.
Assuming you're using the prebuilt version (which you should be unless you're hacking on Electron itself) there shouldn't be any issues upgrading - it just downloads the latest prebuilt binary, there really aren't many files.
Installing a new browser wasn't allowed, but installing these wrappers that prevented the use of any other website and most other browser features, was okay.
With Electron this is even easier.
Also the "Web-Platform" can now do most of the things others can do too.
90% of all things people want to do with apps (mobile or desktop) is already possible with a web-app. If you need more, you can do a browser extension or an Electron app.
$ ps -p $(pgrep keepassx) -o rss=
22844Times are a-changing and memory is cheap these days.
As a dev I'm biased of course and this might not matter to most people. One thing though, you don't have to write the full app three times. For example all the business logic can be in C++ and write a native UI on top of it.
I stopped reading there. If you have total ignorance of how native applications work, maybe fill that hole before trying to evangelize that everything should be written in JS...
Spotify, steam , brackets use these kind of tech, and I personally like them. somehow I find them fast, more stable( probably due to chromes multiprocess architecture).
https://developer.valvesoftware.com/wiki/Chromium_Embedded_F...
Maybe eventually the web hipsters discover what stable releases are and give us an electron branch that doesn't break everything every week, then it'd be more feasible.
Really awesome to make a quick app for someone who is already good in making webapps and needs the power/access/network rights of a desktop app.
¹https://github.com/S2-/http-client
²https://github.com/electron/electron/blob/master/docs/api/au...
The app author controls the update channel. At their own pace, they'll bump up their Electron dependency to a newer version and make sure their app is still compatible with the latest Electron. When they're ready to release that new combination of app and Electron, they can push out the new version to everyone as an auto-update.
Where does Chrome come into it? Who will be ignoring security updates?
Is every app author going to push out an update that includes the latest Chrome with the relevant security fixes? Or are they going to irresponsibly leave the vulnerability unpatched until their app is updated to support the new version of Chrome?
The very idea of using old versions of Chrome (via Electron) - which is the stated reason for bundling Chrome with each app - tautologically means at least some apps will be using vulnerable versions of Chrome.
> At their own pace
That's the point; browser bugs don't happen at the app author's pace.