16 ms·

In response to “Electron is flash for the desktop”

80 points by nbrempel 10y ago

ogezi 10y ago
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.
- harrygeez 10y ago
  I would much rather see React Native succeed than Electron.
  - munchor 10y ago
    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.
  - pier25 10y ago
    I would much rather see a native to JS bridge completely decoupled from React.
- IncRnd 10y ago
  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.
  - moogly 10y ago
    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.
    - floatboth 10y ago
      > 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?
      - moogly 10y ago
        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.
    - bluejekyll 10y ago
      > 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.
endergen 10y ago
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 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.
- butz 10y ago
  Are you planing to add Linux and Windows builds?
  - endergen 10y ago
    Definitely makes sense to. Wanted to make more progress and play with APIs before going wider on platform support.
  - crieff 10y ago
    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.
- hiphipjorge 10y ago
  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!
  - kitsunesoba 10y ago
    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.
BuuQu9hu 10y ago
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.
- seishun 10y ago
  >As participation increases, quality declines [citation needed]
  - BuuQu9hu 10y ago
    https://slatestarcodex.com/2014/07/30/meditations-on-moloch/ https://slatestarcodex.com/2014/07/30/meditations-on-moloch/ If it fails to terrify you, reread.
  - RandomInteger4 10y ago
    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.
- tree_of_item 10y ago
  > 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?
  - BuuQu9hu 10y ago
    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.
awinder 10y ago
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.
- diek 10y ago
  So, like IntelliJ? We should port IntelliJ to Electron?
  - rlabrecque 10y ago
    I mean we already have VSCode and Atom both running on Electron.
    - awinder 10y ago
      I had tons of memory problems on webstorm, basically romping through 4GB+, it was taxing my 16GB laptop at times. Switching to vscode has been a huge resource saver.
      - tommica 10y ago
        I have the opposite issue - PHPStorm works fine, but VS Code and Atom are completely sluggish even on simple PHP files
sanbor 10y ago
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.)
- floatboth 10y ago
  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.
jorvi 10y ago
'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.
Avshalom 10y ago
Wait, where is this explosion of new desktop applications? Also isn't it only a lower barrier if you already know html/css/js
- jacquesc 10y ago
  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).
  - x0x0 10y ago
    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.
    - pitaj 10y ago
      I have 4 slack chats open and it's using about 550 MB of RAM and 0% CPU in total.
      - bitexploder 10y ago
        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.
      - pikzen 10y ago
        Five hundred and fifty megabytes of memory. To display a chat. Or four.
    - Tijdreiziger 10y ago
      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/
Animats 10y ago
Flash was much better than Electron. The Macromedia Flash run-time was modest in size. Originally it was under 1MB. It wasn't intended as a container system for video; it just had the ability to use video as an animation object. It had a good approach for displaying animations, and could start playing well before the entire file was loaded. Electron is bloatware by comparison, and it's mostly a kluge on top of the DOM. 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 http://vitenka.com/users/ChanCats/penelope_pitstop_gt.swf
- icebraining 10y ago
  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?
  - StavrosK 10y ago
    The GP's point was that the tooling for animating was top-notch in Flash, whereas it's nonexistent in Electron.
    - icebraining 10y ago
      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?
      - Animats 10y ago
        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/index.html http://www.adobe.com/devnet-docs/edgeanimate/api/current/ind...
lobster_johnson 10y ago
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.
- blub 10y ago
  Balsamiq Mockups is built with Flex/AIR. It's quite decent, but a bit sluggish.
- derefr 10y ago
  Even before then, you could just ship standalone Flash projectors.
revelation 10y ago
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.
- pinneycolton 10y ago
  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 ;)
- pitaj 10y ago
  It's easier, at least for many. It's a relative statement. Nothing is easy.
saosebastiao 10y ago
Why isn't it possible to dynamically link to the browser engine and js runtime? Isn't that the whole point of dynamic linking?
- floatboth 10y ago
  They are dynamically linked. But every app ships with its own version because the js app was only tested with that version :D
- Const-me 10y ago
  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.
DonFizachi 10y ago
"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?
makkesk8 10y ago
Funny how people are bashing electron when games have embedded chromium for years.
- TillE 10y ago
  As a web browser, yes. It's not even suitable as a game UI, basically just for displaying websites.
coldtea 10y ago
If only the main browser devs could sit and design something that mixes the best of Flash and HTML: - 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. and no legacy DOM stuff, no SVG crap, no CSS, etc. 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.
mnm1 10y ago
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.
- pikzen 10y ago
  >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
  - mnm1 10y ago
    Sadly, these apps do contain their own JREs. The memory footprint is hundreds of megs and they take half a minute to start. Just like Electron apps. I don't deny the tech under the hood (JVM) is wonderful, but the comparison to Electron apps is apt.
  - mnm1 10y ago
    Sadly, these apps do contain their own JREs. The memory footprint is hundreds of megs and they take half a minute to start. Just like Electron apps. I don't deny the tech under the hood (JVM) is wonderful, but the comparison to Electron apps is apt.
b123400 10y ago
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.
tinus_hn 10y ago
These qualities aren't Flash's achievement. The plugin model allowed people to experiment and try out a lot of different approaches.
neilalexander 10y ago
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.
- zer0tonin 10y ago
  >(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.
  - neilalexander 10y ago
    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.

80 points by nbrempel 10y ago

ogezi 10y ago

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.

harrygeez 10y ago
I would much rather see React Native succeed than Electron.
- munchor 10y ago
  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.
- pier25 10y ago
  I would much rather see a native to JS bridge completely decoupled from React.
IncRnd 10y ago
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.
- moogly 10y ago
  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.
  - floatboth 10y ago
    > 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?
    - moogly 10y ago
      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.
  - bluejekyll 10y ago
    > 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.

endergen 10y ago

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 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.

butz 10y ago
Are you planing to add Linux and Windows builds?
- endergen 10y ago
  Definitely makes sense to. Wanted to make more progress and play with APIs before going wider on platform support.
- crieff 10y ago
  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.
hiphipjorge 10y ago
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!
- kitsunesoba 10y ago
  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.

BuuQu9hu 10y ago

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.

seishun 10y ago
>As participation increases, quality declines [citation needed]
- BuuQu9hu 10y ago
  https://slatestarcodex.com/2014/07/30/meditations-on-moloch/ https://slatestarcodex.com/2014/07/30/meditations-on-moloch/ If it fails to terrify you, reread.
- RandomInteger4 10y ago
  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.
tree_of_item 10y ago
> 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?
- BuuQu9hu 10y ago
  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.

awinder 10y ago

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.

diek 10y ago
So, like IntelliJ? We should port IntelliJ to Electron?
- rlabrecque 10y ago
  I mean we already have VSCode and Atom both running on Electron.
  - awinder 10y ago
    I had tons of memory problems on webstorm, basically romping through 4GB+, it was taxing my 16GB laptop at times. Switching to vscode has been a huge resource saver.
    - tommica 10y ago
      I have the opposite issue - PHPStorm works fine, but VS Code and Atom are completely sluggish even on simple PHP files

sanbor 10y ago

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.)

floatboth 10y ago
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.

jorvi 10y ago

'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.

Avshalom 10y ago

Wait, where is this explosion of new desktop applications? Also isn't it only a lower barrier if you already know html/css/js

jacquesc 10y ago
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).
- x0x0 10y ago
  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.
  - pitaj 10y ago
    I have 4 slack chats open and it's using about 550 MB of RAM and 0% CPU in total.
    - bitexploder 10y ago
      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.
    - pikzen 10y ago
      Five hundred and fifty megabytes of memory. To display a chat. Or four.
  - Tijdreiziger 10y ago
    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/

Animats 10y ago

Flash was much better than Electron. The Macromedia Flash run-time was modest in size. Originally it was under 1MB. It wasn't intended as a container system for video; it just had the ability to use video as an animation object. It had a good approach for displaying animations, and could start playing well before the entire file was loaded. Electron is bloatware by comparison, and it's mostly a kluge on top of the DOM. 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 http://vitenka.com/users/ChanCats/penelope_pitstop_gt.swf

icebraining 10y ago
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?
- StavrosK 10y ago
  The GP's point was that the tooling for animating was top-notch in Flash, whereas it's nonexistent in Electron.
  - icebraining 10y ago
    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?
    - Animats 10y ago
      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/index.html http://www.adobe.com/devnet-docs/edgeanimate/api/current/ind...

lobster_johnson 10y ago

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.

blub 10y ago
Balsamiq Mockups is built with Flex/AIR. It's quite decent, but a bit sluggish.
derefr 10y ago
Even before then, you could just ship standalone Flash projectors.

revelation 10y ago

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.

pinneycolton 10y ago
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 ;)
pitaj 10y ago
It's easier, at least for many. It's a relative statement. Nothing is easy.

saosebastiao 10y ago

Why isn't it possible to dynamically link to the browser engine and js runtime? Isn't that the whole point of dynamic linking?

floatboth 10y ago
They are dynamically linked. But every app ships with its own version because the js app was only tested with that version :D
Const-me 10y ago
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.

DonFizachi 10y ago

"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?

makkesk8 10y ago

Funny how people are bashing electron when games have embedded chromium for years.

TillE 10y ago
As a web browser, yes. It's not even suitable as a game UI, basically just for displaying websites.

coldtea 10y ago

If only the main browser devs could sit and design something that mixes the best of Flash and HTML: - 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. and no legacy DOM stuff, no SVG crap, no CSS, etc. 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.

mnm1 10y ago

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.

pikzen 10y ago
>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
- mnm1 10y ago
  Sadly, these apps do contain their own JREs. The memory footprint is hundreds of megs and they take half a minute to start. Just like Electron apps. I don't deny the tech under the hood (JVM) is wonderful, but the comparison to Electron apps is apt.
- mnm1 10y ago
  Sadly, these apps do contain their own JREs. The memory footprint is hundreds of megs and they take half a minute to start. Just like Electron apps. I don't deny the tech under the hood (JVM) is wonderful, but the comparison to Electron apps is apt.

b123400 10y ago

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.

tinus_hn 10y ago

These qualities aren't Flash's achievement. The plugin model allowed people to experiment and try out a lot of different approaches.

neilalexander 10y ago

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.

zer0tonin 10y ago
>(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.
- neilalexander 10y ago
  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.