In response to “Electron is flash for the desktop”(rempel.world)
rempel.world
In response to “Electron is flash for the desktop”
https://rempel.world/posts/electron.html
102 comments
> Flash had excellent authoring tools aimed at animators.
Electron has excellent authoring tools aimed at web developers. Namely, the ones they are already using.
That's kinda the whole point. :)
I don't disagree with you. The Flash authoring tools WERE amazing.
When I'm feeling in a trolling mood, I tell people that Flash is still ahead of JS and HTML5. Not only was the IDE incredible, but AS3 was literally a typed version of JavaScript with XML liberals. That's right, it had the best from JavaScript, TypeScript and JSX, 10 years before any of that existed in the front end web development toolkit.
And you guys hate on Flash! :)
Electron has excellent authoring tools aimed at web developers. Namely, the ones they are already using.
That's kinda the whole point. :)
I don't disagree with you. The Flash authoring tools WERE amazing.
When I'm feeling in a trolling mood, I tell people that Flash is still ahead of JS and HTML5. Not only was the IDE incredible, but AS3 was literally a typed version of JavaScript with XML liberals. That's right, it had the best from JavaScript, TypeScript and JSX, 10 years before any of that existed in the front end web development toolkit.
And you guys hate on Flash! :)
> XML liberals
I assume you meant "literals"? If not, they have my vote. ;)
I assume you meant "literals"? If not, they have my vote. ;)
>Electron has excellent authoring tools aimed at web developers. Namely, the ones they are already using.
You must have a very different definition of excellence if you believe that the current web authoring tools (whatever IDE or editor + plugins people use) are in any way close to "excellent".
You must have a very different definition of excellence if you believe that the current web authoring tools (whatever IDE or editor + plugins people use) are in any way close to "excellent".
What would you expect web development to be like? I mean, holding static the requirements that the resultant DOM has to:
1. reflow when resized (unlike a PDF);
2. work with screen-readers (unlike naive custom rendering engines in games et al);
3. work with accessibility-enabling UA stylesheets (unlike native UI toolkits);
4. be printable without a separately-authored for-print version;
5. if stateful, uses idiomatic HTTP request/response cycles that enable network-level HTTP caching;
5. if a web-app, talks to a simple mostly-stateless HTTP API that can also be consumed unchanged by API client libraries.
There is a reason that Dreamweaver and Publisher are separate apps; and there is a reason Rails/Phoenix/etc. don't support server-side stateful controls like Seaside or the IBM 3270 terminal protocol do. The web is its own thing, and as long as the web is the thing we're targeting, the authoring tools we have are likely about as good as we're gonna get.
(Unless, that is, you can teach your devs to think in terms of distributed actor systems, where all your Javascript code assumes any actor could be remote like in an Erlang system. Then we could have our UI builders and transparently server-ize them too. But would anyone put up with it?)
1. reflow when resized (unlike a PDF);
2. work with screen-readers (unlike naive custom rendering engines in games et al);
3. work with accessibility-enabling UA stylesheets (unlike native UI toolkits);
4. be printable without a separately-authored for-print version;
5. if stateful, uses idiomatic HTTP request/response cycles that enable network-level HTTP caching;
5. if a web-app, talks to a simple mostly-stateless HTTP API that can also be consumed unchanged by API client libraries.
There is a reason that Dreamweaver and Publisher are separate apps; and there is a reason Rails/Phoenix/etc. don't support server-side stateful controls like Seaside or the IBM 3270 terminal protocol do. The web is its own thing, and as long as the web is the thing we're targeting, the authoring tools we have are likely about as good as we're gonna get.
(Unless, that is, you can teach your devs to think in terms of distributed actor systems, where all your Javascript code assumes any actor could be remote like in an Erlang system. Then we could have our UI builders and transparently server-ize them too. But would anyone put up with it?)
How about the paradigm that was in use for, oh, 3-4 decades, before the web ?
The general idea:
It still sucks in many ways though. More could be achieved with just directly exposing OnPaint, 2d and 3d versions. Plus various basic things, like copy-paste, don't work.
It doesn't satisfy half your demands, I realize that (though windows accessibility can be quite good too, and the web's accessibility sucks badly). But I would argue that having actual complex apps was worth more (compare MS Office to Office 360 or Google Docs, or worse, compare things like Corel Draw or Lucidchart to the Lucidchart web app, or any other HTML5 drawing/charting app).
And let's just not talk about Desktop Games versus either web games or even phone games. It's depressing.
The general idea:
void OnPaint(PaintCommands p, Rect limitToRect)
It still sucks in many ways though. More could be achieved with just directly exposing OnPaint, 2d and 3d versions. Plus various basic things, like copy-paste, don't work.
It doesn't satisfy half your demands, I realize that (though windows accessibility can be quite good too, and the web's accessibility sucks badly). But I would argue that having actual complex apps was worth more (compare MS Office to Office 360 or Google Docs, or worse, compare things like Corel Draw or Lucidchart to the Lucidchart web app, or any other HTML5 drawing/charting app).
And let's just not talk about Desktop Games versus either web games or even phone games. It's depressing.
Have fun fulfilling any sort of accessibility requirements with this.
In terms of "easy to begin using", there really is no comparison.
I know there are other metrics, but you have to admit that's a big one.
I know there are other metrics, but you have to admit that's a big one.
Back in 2005 I was tasked to write a web-based CAD viewer. Flash with AS2 was an obvious no-brainer. It could do complex cross-browser high-performance graphics, and AS2 was a mature typed programming language that could be used to program in the large (using an event- and component-based API). It was fast and really easy to program for. I never even used the animation tools, and I still thought it was amazing.
By contrast, javascript was still that weird language almost no one took seriously, before jquery, before "the good parts". It had abysmal performance (way worse than flash), and couldn't do cross-browser graphics (firefox released some basic SVG support towards the end of that year, IE6 had that weird VML thing, and adobe had a slow bloated SVG browser plugin which crashed every 5 minutes).
So, yeah, back in its prime, flash was unbeatable for client-side apps and games. But, things change.
By contrast, javascript was still that weird language almost no one took seriously, before jquery, before "the good parts". It had abysmal performance (way worse than flash), and couldn't do cross-browser graphics (firefox released some basic SVG support towards the end of that year, IE6 had that weird VML thing, and adobe had a slow bloated SVG browser plugin which crashed every 5 minutes).
So, yeah, back in its prime, flash was unbeatable for client-side apps and games. But, things change.
Flash was pretty nice, but it suffered from a few big issues:
* it was closed source, and the tools were not at all cheap.
* their VM was a security nightmare.
* it allowed wanna-be developers to unleash all sorts of abominations on unsuspecting web users. e.g: ads, animations, 10 MB web sites, auto-playing videos, etc.
Luckily for us, JS has solved all thr... I mean tw... I mean the first problem.
* it was closed source, and the tools were not at all cheap.
* their VM was a security nightmare.
* it allowed wanna-be developers to unleash all sorts of abominations on unsuspecting web users. e.g: ads, animations, 10 MB web sites, auto-playing videos, etc.
Luckily for us, JS has solved all thr... I mean tw... I mean the first problem.
Flex SDK was free.
Flash had excellent authoring tools aimed at animators. Try doing that in Electron. Electron is from people who are still stuck at the command line and try to do graphics by writing code.
Flash is now called Animate and can export to HTML5. Why couldn't one use that in Electron?
Flash is now called Animate and can export to HTML5. Why couldn't one use that in Electron?
The GP's point was that the tooling for animating was top-notch in Flash, whereas it's nonexistent in Electron.
I understood that point. Did you understand mine? The very same tool that made Flash animations is now Electron compatible. How can it be nonexistent?
Adobe Animate doesn't use Electron. It generates code which uses its own Javascript runtime. Here's the runtime.[1] Adobe documents the format, and you can write to it directly.
[1] http://www.adobe.com/devnet-docs/edgeanimate/api/current/ind...
[1] http://www.adobe.com/devnet-docs/edgeanimate/api/current/ind...
I'm not saying Animate uses Electron, I'm saying it's Electron-compatible, in that you can take an animation generated by Animate and include it directly into an Electron project.
You can put anything that will run in a browser inside other HTML. WebGL, Animate, and older formats such as Flash, Silverlight, Shockwave, QuickTime, and Java applets are often framed like that. That doesn't mean it's compatible. There's a long history of these boxed formats.
The parent's point was that, if you think the Flash authoring experience was better than the Electron app authoring experience, then why not use Animate to author (most of) your Electron app code?
If you're using Animate, why do you need Electron?
goal posts fly overhead
The original post was comparing Flash's authoring experience to Electron's authoring experience. The fact that you can use the former in the latter wasn't relevant. It was about what would happen to animation if Flash were to go away versus it Electron were to go away.
I'm confused—what, precisely, is the "Electron authoring experience", when used in this sense? If you program an Electron app using HTML5, then isn't anything that outputs HTML5 part of the "Electron authoring experience"?
We actually already had "Flash for the desktop". It was called Adobe Flex (originally Macromedia Flex, and today Apache Flex), and it was... not half bad, actually.
It was based on Adobe AIR, a cross-platform VM that used ActionScript as the language, which at the time looked a lot like what ES2015 is today -- Adobe basically tried to make ActionScript the same as "ES 4.0", an effort to add classes, properties and private/public visibility to JavaScript that was eventually abandoned in favour of smaller improvements in what became ES5, then ES2015. Flex/AIR had a pretty rich UI framework with semi-native widgets and access to the OS.
It was unfortunately heavily based on declaring your UI with XML, and apps tended to look like "AIR apps", much like Swing apps look a bit off and non-native.
It was based on Adobe AIR, a cross-platform VM that used ActionScript as the language, which at the time looked a lot like what ES2015 is today -- Adobe basically tried to make ActionScript the same as "ES 4.0", an effort to add classes, properties and private/public visibility to JavaScript that was eventually abandoned in favour of smaller improvements in what became ES5, then ES2015. Flex/AIR had a pretty rich UI framework with semi-native widgets and access to the OS.
It was unfortunately heavily based on declaring your UI with XML, and apps tended to look like "AIR apps", much like Swing apps look a bit off and non-native.
Can we talk about the other red headed stepchild of desktop dev which is java cross platform apps? It'll take a lot to get me off my high horse that if all that was ported to electron, it'd be a great upgrade for users.
It's also a bridge for Linux desktop to get critical, same-in-class app support. Not a final destination but a possible breakpoint infusion.
It's also a bridge for Linux desktop to get critical, same-in-class app support. Not a final destination but a possible breakpoint infusion.
So, like IntelliJ? We should port IntelliJ to Electron?
I mean we already have VSCode and Atom both running on Electron.
"With Electron, we’re seeing a similar explosion of new desktop software. The lower barrier to entry into creating cross platform desktop software far outweighs the detriment of computer resource usage. A good friend of mine is able to launch and grow a business solo in part because of this low barrier."
Until something better comes along I’d have to agree that Electron is the only way to assure that a developer’s audience are first class citizens regardless of the platform on which the developer’s application is deployed.
In my case, my app ran on an embedded web server and the UI was rendered by Electron. When ever I make changes the app code, I simply run scripts to create installation files for Windows, Mac and Linux (deb). This is done in minutes. What other platform would allow achieve something similar?
Until something better comes along I’d have to agree that Electron is the only way to assure that a developer’s audience are first class citizens regardless of the platform on which the developer’s application is deployed.
In my case, my app ran on an embedded web server and the UI was rendered by Electron. When ever I make changes the app code, I simply run scripts to create installation files for Windows, Mac and Linux (deb). This is done in minutes. What other platform would allow achieve something similar?
Where did this "drops the barrier to entry" myth even come from?
There is nothing easy about having to make your desktop UI in HTML+CSS and dealing with the cumbersome "browser JS" and "nodejs in background" divide.
There is nothing easy about having to make your desktop UI in HTML+CSS and dealing with the cumbersome "browser JS" and "nodejs in background" divide.
It's a great question. I think it drops the barrier for individuals who don't want to spend time learning other languages or concepts. What's a Dispatcher and why is it important for the UI? Some of these developers may never need to answer that question -- and that may not be a terrible thing.
Things that allow people to do more with their existing skill set, even if it's not the most efficient, are generally good. They support organic growth of platforms, creativity, and exploration of things that were previously out of reach for some individuals. They can certainly become unmaintainable and problematic, but if the app's usage grows to a point where those are important problems to solve, they will get solved. Or they won't and they'll become a limiting factor in the usefulness of the application.
Evolution is a fantastic thing ;)
Things that allow people to do more with their existing skill set, even if it's not the most efficient, are generally good. They support organic growth of platforms, creativity, and exploration of things that were previously out of reach for some individuals. They can certainly become unmaintainable and problematic, but if the app's usage grows to a point where those are important problems to solve, they will get solved. Or they won't and they'll become a limiting factor in the usefulness of the application.
Evolution is a fantastic thing ;)
It's easier, at least for many. It's a relative statement. Nothing is easy.
I think Electron apps are much more similar to desktop JVM apps than Flash (not in tech but in pros and cons). Both Electron and JVM apps are absolutely huge distributions and resource drains, the main criticism of both. They have the same goals and serve the same function. You might conclude that this is just another criticism of Electron, but it's not. I run multiple desktop JVM apps still (Jetbrains stuff). Far from ideal on resources or startup time, they generally do the job and are cross platform. I'll take that over the alternative: these apps not existing or not being cross platform.
>JVM apps are a huge resource drain
Aside from the fact that you don't redistribute the entire JRE with every Java app.
Or the fact that their UI toolkits are not horribly hacked together messes, and actually manage to hit 60fps.
Electron apps are a regression from Java apps. And HotSpot is a little wonder of performance, unlike V8
Aside from the fact that you don't redistribute the entire JRE with every Java app.
Or the fact that their UI toolkits are not horribly hacked together messes, and actually manage to hit 60fps.
Electron apps are a regression from Java apps. And HotSpot is a little wonder of performance, unlike V8
I've worked with companies making apps with electron/nw.js, what strike me most was not the performance or the product itself, but the reason they decided to use electron. The argument is always about development efficiency, while ignoring the user experience sacrificed. I find it lack of craftsmanship, just kind of sad.
Though, it is true that nontechnical users are unlikely to realise the difference, they probably don't know an app with not many functionality costs hundred megabytes. Maybe I am just getting old and grumpy, maybe that's how assembly programmers see C programmers.
Though, it is true that nontechnical users are unlikely to realise the difference, they probably don't know an app with not many functionality costs hundred megabytes. Maybe I am just getting old and grumpy, maybe that's how assembly programmers see C programmers.
Wait, where is this explosion of new desktop applications?
Also isn't it only a lower barrier if you already know html/css/js
Also isn't it only a lower barrier if you already know html/css/js
I'm currently using these Electron Apps every day:
Slack, Nylas, VSCode, Insomonia, Freeter, Mongobooster
On a 2015 macbook pro with 16GB of RAM.
The buggiest and most resource intensive apps I use tend to be the native ones (iTunes, Dropbox, BusyCal, Evernote).
On a 2015 macbook pro with 16GB of RAM.
The buggiest and most resource intensive apps I use tend to be the native ones (iTunes, Dropbox, BusyCal, Evernote).
iTunes is a mess. It's an ancient code base (dates back to SoundJam MP in the late 90s) and is a bizarre amalgamation of cross-platform pseudo-Cocoa, Cocoa, and webviews. It's a great example of how to not do a native app.
Also, I haven't used Evernote in years but last I checked, their app isn't true native but instead some kind of web wrapper trying to look native.
Also, I haven't used Evernote in years but last I checked, their app isn't true native but instead some kind of web wrapper trying to look native.
Slack on the desktop is a hunk of garbage. Sign in to even 3 slacks and it will eat almost a gig of ram and 5% CPU to... display v2014 irc chat. They really should be ashamed of themselves. I have to remember to kill it whenever I'm on battery.
I've been quite happy with Rambox, an app that aims to unify all your messaging services into one desktop app. Ironically, it's also built with Electron, but right now, it's sitting at 30MB RAM and 0,1% CPU with 3 Slacks, WhatsApp, (FB) Messenger and Discord loaded.
http://rambox.pro/
http://rambox.pro/
Have you ever used Franz? If so, is Rambox better, in your opinion? Franz doesn't seem to be much better in RAM than a browser, but I can't imagine what Rambox does to improve that.
I haven't used Franz, because it's not open-source. I actually found Rambox after hearing about Franz and searching for an open-source alternative.
Both Rambox and (as I understand it) Franz just load the web interfaces of the services you configure, so performance wouldn't be better than Chromium, since that's what Electron uses. The added value is in the wrapper, which helps to keep everything organized, lets you open and close all services at once (by opening/closing Rambox), and provides a global 'do not disturb' mode for notifications.
Both Rambox and (as I understand it) Franz just load the web interfaces of the services you configure, so performance wouldn't be better than Chromium, since that's what Electron uses. The added value is in the wrapper, which helps to keep everything organized, lets you open and close all services at once (by opening/closing Rambox), and provides a global 'do not disturb' mode for notifications.
I can hardly imagine this working well, but I'm driven to install it and give it a try. Thanks for the link; maybe it will be magical!
I have 4 slack chats open and it's using about 550 MB of RAM and 0% CPU in total.
When I launch Slack in a cgroup with 512 MB of RAM it crashed, OOM, before loading. 1 team. It takes about 1024 to make it stable and prevent swap thrashing.
Five hundred and fifty megabytes of memory.
To display a chat. Or four.
To display a chat. Or four.
There's a page for that! https://electron.atom.io/apps/
Is 300 programs in three years an explosion? Does it even rise above rounding error in existing rate new of desktop apps? Because thats what all talk about lowering barriers and democratizing the desktop implies: that Significantly More desktop apps are being written because of Electron.
Wunderlist, Slack, Spotify, Adobe CC, Atom, VSCode, and a very long etc.
(Technically Spotify and Adobe CC use CEF instead of electron but it's the same idea)
(Technically Spotify and Adobe CC use CEF instead of electron but it's the same idea)
Wunderlist is native, afaik.
Um you are right. It used to be HTML5 and in 2012 they switched to native. My bad.
https://techcrunch.com/2012/12/18/wunderlist-2-goes-native-o...
https://techcrunch.com/2012/12/18/wunderlist-2-goes-native-o...
If anything, the problem with Electron is that it takes the wrong approach to lowering the entry barrier to application development. Rather than forcing developers to come up with more user-friendly programming languages and UI toolkits, Electron takes the easy way out and bends HTML and JavaScript into a hugely overweight kludge to accomplish things it was never really designed for.
The result? Fat applications that take up lots of resources, poor user experience that doesn't match the native look-and-feel of the OS, and a huge surface for problems or security vulnerabilities. (Just the other day I was tweeting to the developer of an Electron app when I discovered that their simple chat app was linking to CoreMIDI on macOS - what exactly for?!)
I still recoil a little bit when I look at the DOM of the average Electron application, because it's horrendous and scary and HTML still is not the correct tool for the job, no matter how much people try.
I'm glad that it is inspiring people to create, but in doing so we're teaching new developers bad practice.
The result? Fat applications that take up lots of resources, poor user experience that doesn't match the native look-and-feel of the OS, and a huge surface for problems or security vulnerabilities. (Just the other day I was tweeting to the developer of an Electron app when I discovered that their simple chat app was linking to CoreMIDI on macOS - what exactly for?!)
I still recoil a little bit when I look at the DOM of the average Electron application, because it's horrendous and scary and HTML still is not the correct tool for the job, no matter how much people try.
I'm glad that it is inspiring people to create, but in doing so we're teaching new developers bad practice.
>(Just the other day I was tweeting to the developer of an Electron app when I discovered that their simple chat app was linking to CoreMIDI on macOS - what exactly for?!)
Probable because Chrome does it and the developer has no control over this.
Probable because Chrome does it and the developer has no control over this.
Yes, that's exactly what it is, and that's exactly the problem. This model teaches people to just "trust" that Chrome is right and it teaches people not to optimise.
'Some' bloat.
Not to ham on the guy personally but someone posted his new cross-platform app on HN that put an icon in the systray/menubar and built it on Electron. The end result was something that should take up a few mb of memory at most consuming over 300Mb(!) of memory. That's simply ludicrous.
Not to ham on the guy personally but someone posted his new cross-platform app on HN that put an icon in the systray/menubar and built it on Electron. The end result was something that should take up a few mb of memory at most consuming over 300Mb(!) of memory. That's simply ludicrous.
If only the main browser devs could sit and design something that mixes the best of Flash and HTML:
Instead of all the BS work in asm.js, Dart, the nth W3C standard, etc and kludges on top of kludges, they could have something up and running in a couple of years, and push it to their evergreen browser new releases.
Have Google and Bing penalize websites stuck in legacy HTML and most of the web give way to this new hotness in 10 years or so -- and the rest run in legacy-mode in stricter sandboxes.
- text/document presentation (with advanced typography -- css3 is still crap)
- embedded hw accelerated bitmap canvases (for when you need total control)
- vector based main drawing (hw accelerated)
- styling language (that doesn't cascade by default)
- embeddable/loadable fonts
- richer set of form controls (e.g. at least sliders, date/time pickers, etc)
- compact, compressed delivery
- ability to pry content open (no opaque blobs)
- video/audio playing
- a JS-without-the-BS (like an "enhanced strict-mode")
- a high level control (widget) description language (XAML, JSX style)
- self-contained custom widgets
- overridable built-in widgets (form controls)
- a sensible layout system (grid style), that doesn't assume everything starts as a text-based document.
Instead of all the BS work in asm.js, Dart, the nth W3C standard, etc and kludges on top of kludges, they could have something up and running in a couple of years, and push it to their evergreen browser new releases.
Have Google and Bing penalize websites stuck in legacy HTML and most of the web give way to this new hotness in 10 years or so -- and the rest run in legacy-mode in stricter sandboxes.
Why isn't it possible to dynamically link to the browser engine and js runtime? Isn't that the whole point of dynamic linking?
Technically possible.
The main problem, people developing apps on top of that framework will have to deal with compatibility issues across various browsers and their versions.
On Windows (including mobiles), the only embeddable browser is Internet Explorer.
On OSX, iOS and Androids since 4.4, it’s different versions of Blink.
Electron solves this problem by redistributing a specific version of the browser, this way the app no longer depends on the OS and its updates.
The main problem, people developing apps on top of that framework will have to deal with compatibility issues across various browsers and their versions.
On Windows (including mobiles), the only embeddable browser is Internet Explorer.
On OSX, iOS and Androids since 4.4, it’s different versions of Blink.
Electron solves this problem by redistributing a specific version of the browser, this way the app no longer depends on the OS and its updates.
They are dynamically linked. But every app ships with its own version because the js app was only tested with that version :D
Maybe some day desktop OSs will adopt the save model that iOS and have a webkit component. That may allow different browsers and electron app to reuse/share components (i.e. Webrtc, etc.)
macOS had a WebView for ages. Same on Windows, though unless it's the latest version of Windows you get a crappy old IE engine. On X11, you can use QtWebKit/WebKitGTK.
But web developers wanted to have a super recent engine and the same one across operating systems so we have what we have.
But web developers wanted to have a super recent engine and the same one across operating systems so we have what we have.
These qualities aren't Flash's achievement. The plugin model allowed people to experiment and try out a lot of different approaches.
I completely agree with this. Electron drops the entry barrier for desktop development much like flash did for web development.
As computers get faster I think that the difference in performance of apps using electron versus platform native apps will be imperceptible.
As computers get faster I think that the difference in performance of apps using electron versus platform native apps will be imperceptible.
I would much rather see React Native succeed than Electron.
I would much rather see a native to JS bridge completely decoupled from React.
What we would rather see succeed really has nothing to do with what will ultimately succeed. In the end, every developer will choose what they want based on ease of use, their preferences, features, etc. The most elegant technology is not always the one that "wins" - it's the one that most people choose to use (for whatever reason) and contribute to.
The issue for me isn't performance as in speed but performance as in battery life. Chrome, and hence any electron app, by far uses the most energy on my laptop.
Maybe one part of the problem is conflating laptops with "desktop". Maybe I'm misguided since I don't use laptops for serious screen time and thus don't really care about power consumption at all, but it seems to me that perhaps laptops shouldn't be lumped in with desktops in this way as is now popular. Maybe we still have 3 major form-factor platforms[1], or perhaps even laptops should rather be lumped in with mobile, especially since we have 2-in-1 tablet/laptop hybrid devices.
[1]: Contrary to what Intel has been pushing with their lamentable "mobile-first" strategy.
[1]: Contrary to what Intel has been pushing with their lamentable "mobile-first" strategy.
> I don't use laptops for serious screen time
You're going to be more and more in the minority on this. Even though I prefer Chrome, on my MacBook I use Safari because I find it's battery usage to be significantly less.
I don't notice anything similar with VSCode, so its not Chrome/electron implicitly.
You're going to be more and more in the minority on this. Even though I prefer Chrome, on my MacBook I use Safari because I find it's battery usage to be significantly less.
I don't notice anything similar with VSCode, so its not Chrome/electron implicitly.
> laptops shouldn't be lumped in with desktops
They are x86 systems that run the same operating systems as big desktop towers. Many people use laptops as their one and only x86 machine. Why would you not lump them in with desktops?
They are x86 systems that run the same operating systems as big desktop towers. Many people use laptops as their one and only x86 machine. Why would you not lump them in with desktops?
I thought that was rather clear. Because they (partially) run on batteries. After all, that seems to be the main problem people have with Electron in these HN threads.
I'v been experimenting with trying to make a smaller Electron like Javascript application wrapper. It's called Shrinkray, and only adds 60K of overhead to the size of the app. See:
https://github.com/francoislaberge/shrinkray
It is macOS only (for now). I haven't measured if it is more performant when in the background, but I will. It'seems certainly way smaller in disk size, but comes with tradeoffs in API/functionality.
It is macOS only (for now). I haven't measured if it is more performant when in the background, but I will. It'seems certainly way smaller in disk size, but comes with tradeoffs in API/functionality.
I really liked the concept for this[0] project last year. I now do a similar thing and all of my need-browser-abilities-on-the-desktop projects just require you also have Chrome installed and I just use "chrome --app". I also get security updates for free! I think it's much more reasonable to run a localhost-only web server and use a browser on the desktop than requiring the browser embed native capabilities directly from JS source (and if you really needed that, you could build some fast IPC). You just need to make sure you sign/auth all of your localhost calls w/ a rotating key to (admittedly only somewhat) prevent other process accessing your webserver. Or someone could just make a chrome plugin that does direct IPC to your backend and no web server needed.
I think the problem is everyone is trying to match the Electron API and the multi-process/IPC hoops. If they would just build it like a localhost-only webapp, they'd get so many benefits including the small app size.
0 - https://github.com/utamaro/neje-ui
I think the problem is everyone is trying to match the Electron API and the multi-process/IPC hoops. If they would just build it like a localhost-only webapp, they'd get so many benefits including the small app size.
0 - https://github.com/utamaro/neje-ui
Shrinkwrap is basically a local server that hosts a folder of static html/css/js content that is served through an app that is just a full window WebView element.
You could use a similar trick of wrapping go code, but instead of assuming Chrome is installed, just host your front end using the native webview. Requires no other installation than your app that way.
You could use a similar trick of wrapping go code, but instead of assuming Chrome is installed, just host your front end using the native webview. Requires no other installation than your app that way.
Oh and regarding your signing requests to ensure other processes can't peak at the server content. I haven't gotten to this, was definitely on the plate, more proving out the approach still. Wrapping various apps and thinking through the issues.
Another cross platform alternative: https://nodekit.io/
Great idea. Are you using WebKit's WebView?
I'm guessing no Node or any other API to interact with the OS (file system, etc), right?
I'm guessing no Node or any other API to interact with the OS (file system, etc), right?
This is exactly it. This is the trade off for smaller size. You could do this approach with node.js as the backend.
There are no APIs like file APIs, those would be the first APIs to add for sure.
There are no APIs like file APIs, those would be the first APIs to add for sure.
I've wanted to play around with something like a golang "main" process and using the systems built-in web view. The final app would be much smaller in size and probably better on the end user's hardware.
But, like you said, it comes with its own set of downsides
But, like you said, it comes with its own set of downsides
Is there any difference in memory/battery footprint? I imagine that "problem" would still exists, because it's using Chrome underneath. Decreasing build sizes is a great improvement though!
Seeing that it's macOS only for now, it's probably using WKWebView underneath (same as Safari) which is considerably easier on resources than Chromium is.
A web wrapper that uses the system's resident web renderer would be a wonderful alternative to electron. A Linux build could also use WebKit, and perhaps the Windows version could be based on Edge.
A web wrapper that uses the system's resident web renderer would be a wonderful alternative to electron. A Linux build could also use WebKit, and perhaps the Windows version could be based on Edge.
There is already an OSS project that attempts to do this - a wrapper around the system native browser for all platforms. See https://nodekit.io/.
This is exactly what it does, wraps WebView. I don't do much Windows desktop programming these days, never have for Linux. I assume there are similar built in webviews that can be used for them too.
Are you planing to add Linux and Windows builds?
WRT to windows 8 and 10 (that is no windows 7 or earlier) this is essentially a windows store app when written using html, css, js instead of c#. It does have a more limited api than a conventional desktop app since it is sandboxed, but using portable class libraries and the provided api you can get file access and even sqlite with a bit of wrangling.
Definitely makes sense to. Wanted to make more progress and play with APIs before going wider on platform support.
Why is the Mini Paint icon the icon of the minigun from San Andreas?
I'm not sure, I just wrapped the project:
https://github.com/viliusle/miniPaint
As participation increases, quality declines, unless there are structural safeguards built into the system. I see nothing in Electron which suggests structural quality. I wonder whether rose-colored glasses are overly tinting the viewpoints of folks in the JS community.
> As participation increases, quality declines, unless there are structural safeguards built into the system.
Well, yeah, but that's a refutation of the entire web. Maybe we should go back to the days when only a chosen elite was able to distribute writing or software to a wide audience?
Well, yeah, but that's a refutation of the entire web. Maybe we should go back to the days when only a chosen elite was able to distribute writing or software to a wide audience?
What a strawman. Noone wants to go back to days of "chosen elite", but JS/Electron really really REALLY isn't the only simple way of building cross-platform apps. Don't make false comparisons.
Cross platform desktop toolkits are usually SIMPLER to build apps in because they don't have the document-centric baggage of HTML/CSS/JS stack.
People have been building cross-platform software since forever - heck, in 1980s you had to port your game/software on several different architectures and bedroom programmers (far from "chosen elite") regularly supported Ataris, Amigas, Commodores, PCs and other platforms.
Cross platform desktop toolkits are usually SIMPLER to build apps in because they don't have the document-centric baggage of HTML/CSS/JS stack.
People have been building cross-platform software since forever - heck, in 1980s you had to port your game/software on several different architectures and bedroom programmers (far from "chosen elite") regularly supported Ataris, Amigas, Commodores, PCs and other platforms.
> Cross platform desktop toolkits are usually SIMPLER to build apps in because they don't have the document-centric baggage of HTML/CSS/JS stack.
Which one is simpler than Electron, in your opinion? Because it seems like a lot of people would like that sort of thing.
Which one is simpler than Electron, in your opinion? Because it seems like a lot of people would like that sort of thing.
Let's be honest, Gopher was not that bad, and the Web is quite bad. That said, I'm not sure whether the Web can be replaced with something more desirable; a lot of folks like the Web's inability to protect folks from each other.
>As participation increases, quality declines
[citation needed]
[citation needed]
This is something so obvious that it doesn't need a citation, but I think it's misunderstood.
It doesn't mean that the quality of the product decreases, but that the average quality of whatever is made with the product decreases from a user's perspective.
Just take a look at WordPress; I'm going to assume that over time the product itself has gotten more secure and usable due to more eyes being on it and it's adoption rate increasing, but being secure in itself doesn't mean that it can't be used insecurely.
It doesn't mean that the quality of the product decreases, but that the average quality of whatever is made with the product decreases from a user's perspective.
Just take a look at WordPress; I'm going to assume that over time the product itself has gotten more secure and usable due to more eyes being on it and it's adoption rate increasing, but being secure in itself doesn't mean that it can't be used insecurely.
https://slatestarcodex.com/2014/07/30/meditations-on-moloch/
If it fails to terrify you, reread.
If it fails to terrify you, reread.
Here's a good Flash animation. Fits in 1.9MB.[1] Enjoy. Flash had excellent authoring tools aimed at animators. Try doing that in Electron. Electron is from people who are still stuck at the command line and try to do graphics by writing code.
[1] http://vitenka.com/users/ChanCats/penelope_pitstop_gt.swf