16 ms·

Electron 4.0.0

233 points by gozzoo 8y ago

Djvacto 8y ago
I always read about how Electron is very resource-intensive, but I'm curious as to how the performance improves as time goes on? Does the Electron team have a focus on improving performance? Or is the issue with the developers using electron, should they be optimizing better? I assume it's some of both, but curious if anyone with more experience in electron can provide any insight as to how the performance changes over time.
- accatyyc 8y ago
  The issue itself is that Chromium uses a lot of memory. And electron basically just runs Chromium. Except that since each Electron-based app ships its own very isolated copy of Chromium, the following problems occur: - The operating system cannot share memory between different Electron processes. Normally if you start many processes of the same binary, the memory is shared and only copied on write. Since each Electron app is a different binary (even though they are 99% identical) they each eat memory. - The above applies to disk size as well. Electron apps are usually huge, and 99% of the binary is the same as all your other electron apps. This is mostly why I'm against electron. If electron worked like the JVM and each app shared a runtime, many issues would be solved, including many electron apps running old, and vulnerable versions of Chromium. Now it's only updated if the developers decide to ship a new version.
  - alex_suzuki 8y ago
    The last point is something that in theory could have been achieved (shared runtime) with Java or .NET, but in reality there are real, tangible benefits to shipping self-contained applications, and the disk size argument is just no longer that relevant. This is in no way an endorsement for Electron, just an aspect common to all platforms that rely on an intermediate runtime that could in principle be shared.
    - realusername 8y ago
      > the disk size argument is just no longer that relevant. But the memory one definitely is, I don't want each app to take 1GB of ram.
    - fredley 8y ago
      Disk size argument no but memory yes. Keeping this massive binary duplicated in memory for every trivially small (memory-wise) app, like Slack, is bananas.
    - wodenokoto 8y ago
      Actually disk size argument is still relevant. My brand new MacBook pro has the same disk space as my 10 year old MacBook pro. While hard drive space is cheap on spinning drives, space on consumer devices has stagnated or even decreased with the move to ssd
      - rubber_duck 8y ago
        We are still talking ~100MB (from what I can see my entire VS Code install folder is 170 mb - 100 probably goes off to chromium stuff) - even if you use 10 electron apps 1GB of memory isn't going to kill your drive - really not worth the tradeoff and effort considering the alternatives.
    - PavlovsCat 8y ago
      > there are real, tangible benefits to shipping self-contained applications Here's one that doesn't suck: https://sqlitestudio.pl/ https://sqlitestudio.pl/ Maybe that was very complicated to make, all I know is that it's blazing fast and doesn't hog memory. Or hey, take OggDrop and LameDrop, I'm sure there's programs that do the same, are 100 times as big and have 3 options. I don't know if there are 10x programmers, but I know there are 100000x programs, with not one electron app among them.
      - kimmel 8y ago
        I love SQLiteStudio. On my machine it starts up in < 2s. Version 3.2.1 takes 99MB disk space and is built against QT5. I just ran some queries and the memory usage is only 80MB for a not too large database. Another self-contained application I like is racket/drracket.
  - PaulHoule 8y ago
    Why is it that people seem to think using a cross-platform UI toolkit like tkinter, kivy, WxWindows, etc. is like putting their hand in a toilet? Lately I have been building apps with tkinter/python/asyncio and I can't get over how fast the apps are to load and to use. There is none of this "let's not respond to the mouse for 5 seconds" that is staggeringly common on my mac (particularly for apps like Safari and iTunes that come from Apple) nor the "go for a walk around the block" loading times for Java-based apps on my i7 Windows laptop. True tk apps are ass-ugly but I find it mind-blowing to use GUI apps that are as responsive as Windows 95 apps were back in the day.
    - eddieroger 8y ago
      Do they think that? I think more what thing here is that Electron apps are popular with UI developers who want to make the jump from web apps to native apps without taking the time to learn the platforms, or wish to reuse components they use on their web apps.
    - androidgirl 8y ago
      The aversion is mostly that a lot of devs have learned to use html, css, and js for styling ui's. I love Kivy as well as QT. You can make some decent looking apps with the former and some incredible ones with the later. I have never personally worked with Electron. But yeah, most devs use JS, HTML, and CSS for ui creation because of the Web. I think something like QML could replace the html and css parts, though.
      - giobox 8y ago
        To add to this point, virtually all software companies have devs with web dev experience that can be very easily leveraged with Electron. Native app development skills aren’t nearly as prevalent in most organisations in my experience. The success of electron has never been that much of a surprise to me: write once, ship (almost) everywhere, use the team you already have. Often cheaper than upskilling the team as well.
    - jniedrauer 8y ago
      > Why is it that people seem to think using a cross-platform UI toolkit like tkinter, kivy, WxWindows, etc. is like putting their hand in a toilet? tkinter specifically does not look very pretty without some effort. I would much rather use GTK or QT. The problem is GTK support on windows is limited, and QT has a weird license model.
  - jf- 8y ago
    Is there a reason it’s not done as a runtime, i.e. have a single, electron-modified, backwards compatible install of chromium which all the electron apps run on? Then ship each app with the installer for that electron-chromium which gets installed if it’s not already present. Though I feel like even if that happened people would still complain about it, mostly motivated by web technologies encroaching on the desktop space, threatening other developers “turf”, so to speak.
    - megous 8y ago
      No there isn't. For example on Arch Linux, you can do pacman -S electron and share the same runtime for all your electron apps. Though, I don't use any third party ones.
      - jf- 8y ago
        That’s interesting. Is there something specific to arch that allows this? It would definitely help to alleviate people’s concerns about electron if this could be replicated on other platforms.
        megous 8y ago
        Nothing specific. You can do it with electron executables downloaded from the official website. Just run them, and drag'n'drop directories with the application's source code onto the electron window, or create desktop shortcuts that run "C:\somewhere\electron.exe C:\your\app\dir".
      - simion314 8y ago
        This would work only for packaged apps from the repos right? Better then nothing.
        megous 8y ago
        I didn't find any apps in the repository. This works for apps you write yourself. You just run "electron ." in the directory with the app's source code. You can probably unbundle thirdparty apps, becuase what electron apps are, are basically "electron" + "other code/resources". But I've never even seen someone else's electron app distribution package, so I don't know how hard/easy it would be. And I wouldn't trust it anyway, if the code is transpiled/minified/unreadable. I run all my electron apps using a shared runtime.
  - ancorevard 8y ago
    The root cause of the problem with Electron is that its performance on the Mac is just like the Chrome browser. Compared to Safari, Chrome’s performance is like a fat pig hogging your memory and devouring your battery life.
  - felixfbecker 8y ago
    When I tried out Windows tabbed shell in the Insiders build I found myself using the web versions of Electron apps (e.g. Slack) way more than the apps. They can do everything the app can nowadays (including native notifications), and with tabbed shell, they can appear next in a tab right next to a native app - but with all the benefits of web apps: linkability, hackability through browser extensions, accessibility, no annoying update prompts. And of course only running one browser engine instance. You can even pin them to your task bar like native apps. I feel like on macOS many people install native apps only to have a dock icon. We really overvalue packaged apps
    - drb91 8y ago
      > We really overvalue packaged apps I think splitting out services from the browser makes it easier to focus on notifications and use window management to change contexts. It is confusing and frustrating that Apple has not allowed saving websites to apps yet.
  - SigmundA 8y ago
    Wouldn't memory compression and disk compression resolve those issues to some degree? Sharing libraries is definitely more efficient but at the cost of isolation and versioning issues. Similar to some of the reason vms and containers are used. Over time I have come to appreciate self contained apps and deal with redundant bytes at a lower level.
  - seanalltogether 8y ago
    > This is mostly why I'm against electron. If electron worked like the JVM and each app shared a runtime, many issues would be solved, including many electron apps running old, and vulnerable versions of Chromium. On the other hand, requiring a shared runtime has been one the key reasons that a lot of cross platform apps failed in the past. How many times have others decried the fact that they had to install Java or Adobe AIR or XYZ in order to run an app they needed.
    - sime2009 8y ago
      Well, there was a solution to that last problem. Just bundle the whole runtime with the product each time. And just like that we're back at square one again...
    - Splines 8y ago
      Steam seems to solve this fairly well. If you need a runtime it is installed along with the product.
  - jackpeterfletch 8y ago
    - If electron worked like the JVM and each app shared a runtime You mean like eerr, chrome - and the web :P
  - blinkingled 8y ago
    > - The operating system cannot share memory between different Electron processes [..] That should not be a significant issue in 2018 - all popular operating systems have same page merging support now and at least latest Win10/macOS also have transparent compression of memory pages.
    - ryacko 8y ago
      Woudldn’t that break ASLR?
      - blinkingled 8y ago
        ASLR applies to virtual memory / process address space. Merging or compression is of physical pages - the page is uncompressed on the fly when the process accesses it. It works because the OS is in control of the Virtual->Physical mappings and can, on a page fault do the decompression transparently for e.g.
    - ahartmetz 8y ago
      Compressing working memory is quite expensive in CPU cycles compared to just using it. Identical page merging is also reasonably expensive and only works if pages are, well, identical. Your Electron runtimes are probably not going to be bit for bit identical, not even small sections, due to offsets not divisible by page size. Tuning for better deduplication is possible, but then you're at an awkward mix of caring and not caring about performance.
      - blinkingled 8y ago
        Compression is pretty fast on modern CPUs so I would disagree about that. But yes depending on the compiler/switches/versions the Electron run times are not going to be bit for bit identical but it's a stretch to say there will be nothing in common - all the dependent library code for e.g.
  - scoopdewoop 8y ago
    It is absurd the people that show up out of the woodwork every Electron article to complain about performance. Meanwhile, I have not closed Discord for more than a day or two in years. A quick Ctrl-Shift-Esc shows that it is using 180MB of RAM right now with ~20 rooms open, as well as DMs. Meanwhile, Discord has fantastic uptimes and never impedes performance while competitive online games run alongside it. The idea of trying to replicate the interface in something like tkinter is cringeworthy at best. Discord supports animated gifs, modals, videos, emojis, fonts, code samples, markdown, and game integrations right in the chat! Please, please try and replicate that with Tkinter, an API where you'd need to roll your own drag-and-drop. If i want to run discord as a website, using the same resources as any other website, i CAN! Its the same codebase and interface. I run the full desktop client for the better filesystem, game, and chat integration and it is worth the measley RAM on my modern machine. Discord is an intelligent start up that was able to pivot from a chat client to a games marketplace with a one-click update. Their use of the erlang VM shows that they make considered tech decisions based on tested technology. I think their use of electron, at least from this users perspective, was a great decision. I realize they are just one example of electron apps, and I'd have a harder time defending a file-unzipper or some madness using Electron, but it no doubt has its uses. To suggest otherwise would be premature optimization at best.
    - zozbot123 8y ago
      > animated gifs, modals, videos, emojis, fonts, code samples, markdown, and game integrations Noted, and that's a fine use case for the Browser engine + HTML + CSS + JS/WASM tech stack - but how many native apps need that sort of rich view?
    - seba_dos1 8y ago
      Not commenting on anything else, but Discord app consuming 180MB RAM sounds like a mismeasurement. Here it takes almost 0.5GB right after launching.
      - mbell 8y ago
        They are most likely only looking at the RAM used but the 'Discord' process, which is just the native launcher code and OS hooks (on MacOS here, may be different on other OSes). The electron processes are called 'Discord Helper' and will be using quite a bit more RAM, though I still wouldn't consider it 'heavy'. The same process structure is true of Slack as well (maybe all electron apps, I'm not familiar enough to say). Both Slack / Discord use around 400MB including all processes on my machine, tho it certainly varies with what is on screen. In comparison to the gmail tab I have open in Safari that is using 1GB, 400MB isn't bad.
  - Aaronmacaron 8y ago
    I don't think a JVM like chromium engine would really solve the problem. Most JVM end user applications ship their own JVM. By shipping your own JVM one can avoid compatibility problems and most importantly the user doesn't has to install the JVM which makes for better UX. The same would apply for Electron. The only way I think a common runtime could work is if Electron used the Runtime of the Browser. If every browser exposed an API to run JavaScript and Render HTMl using the browser's Engine that'd be great.
    - vincnetas 8y ago
      Why expose api. One could run web server on localhost and thats it. Open it with any browser and enjoy your crosplatform app. I think https://blockstack.org https://blockstack.org is doing something similar.
    - vincnetas 8y ago
      Adding to my previous comment, you can even run chrome webpage without address bar on macos : /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --app=https://google.com https://google.com
  - manigandham 8y ago
    Why does this matter on any modern operation system and hardware? What is the point of unused RAM capacity given fast mem/disk IO, compression and seamless paging?
    - zozbot123 8y ago
      Disk IO is not always fast. Memory bandwidth is a huge bottleneck on current-day systems, especially on high-frequency, high-core-count processors. And so on and so forth. If you want a snappy and truly usable system you still need to care about performance issues, particularly given the rise in non-reducible system requirements e.g. for browsing the modern web.
  - Sindisil 8y ago
    > If electron worked like the JVM and each app shared a runtime Unfortunately (or fortunately, depending upon your point of view), the JVM world has moved to a model of embedding a JVM with each app, as it can be less problematic for developers (and lets Oracle remove a bunch of subsystems from the JDK, reducing their development and maintenance). On the up side, though, newer releases of Java provide jlink, so that the JRE can be stripped down to exclude subsystems that aren't used by the app. Also, several JVMs still support class data sharing, so if multiple instances of an app are launched, they can share some common class data.
- sergiotapia 8y ago
  Either they start working towards performance/memory issues or this will very likely go the way of Cordova/PhoneGap. Feature rich, but ultimately forgotten and not used for new projects.
  - NatW 8y ago
    I don't think VSCode is going away. It's built on Electron[1] and performs quite adequately for me, personally. [1] https://en.wikipedia.org/wiki/Visual_Studio_Code https://en.wikipedia.org/wiki/Visual_Studio_Code
    - nni 8y ago
      I've only very rarely seen performance issues with VSCode...
    - intertextuality 8y ago
      VSCode seems to be one of the exceptions. It's also not as fast as Sublime Text.
      - 0xCMP 8y ago
        Agree, but because it's JS and well designed plugins also affect the editor experience much less. Where in Sublime the Python based plugins which aren't designed around async and promise-like patterns often can lock up the editor waiting on them. VSCode is pretty much the best Emacs there is right now. Uses JS, has good package management, allows changing settings per "workspace" including enable/disable plugins, has great git support, pioneered LSP, and more. I literally want to hate VSCode, but there isn't much to hate and any weakness it has can/should/likely-will be addressed by a plugin.
      - GuB-42 8y ago
        Performance is the reason why I stayed with Sublime Text. I gave VSCode a try, and it is really great, and transition from Sublime Text is easy. They probably stole most of their good ideas from it, while improving on others, a practice that I definitely support. However, it is not as responsive. By that, I mean sub-second stutters, nothing game breaking, but enough to affect the feel. Note: coding in C++, using the LSP plugin on Sublime, and the standard language support on VSCode. Building and source control done separately on the command line. I use "modific" on sublime to see the differences, and the built-in support for VSCode.
- CyberDildonics 8y ago
  The biggest issue by far with every electron based program I've used is actually not the huge memory foot use or the hundreds of megabytes for a simple program, it is the latency of the interface. Every interaction ends up lagging like molasses, whether it is text input, window resizing, startup time etc. We have video games that run 3D environments with gigabytes of geometry and textures at 144hz yet people are making simple text editors and interfaces with a dozen simple components (like the ethereum wallet) that run xwindows streamed over a 56.6 modem.
  - jeffbax 8y ago
    Nevermind the small but incredibly obvious stuff like keyboard shortcuts, drag and drop behavior and text selection…
  - spiralganglion 8y ago
    I think this is an excellent criticism of Electron that seems to be buried. Sure, it’d be nice if the RAM usage and disk footprint of electron were smaller. Maybe the creation of some sort of shared single instance of chromium will happen, someday. But even if it does, the browser rendering process is really latent unless you’re extraordinarily careful. It’s very challenging to make sure that your app responds to input within one frame — batching updates with requestAnimationFrame creates a visible delay when dragging and typing. It’s possible to do better, but it’s hard and almost nobody does. And it’s easy to do a lot worse — RAIL isn’t aggressive enough. (My angle on this — I do high-performance 2d/3d animation work in the browser and in electron, with extensive testing of latency, energy usage, frame rate stability, etc)
    - ahartmetz 8y ago
      I've heard a similar story about an app implemented in HTML5 and node.js (no good JS UI frameworks existed at the time). The fine-tuning took an extraordinary amount of time. I was on a project that redid it in QML in a fraction of the time with a fraction of the headcount and performance was great right away.
- fabiospampinato 8y ago
  Performance improves as each new version of Electron basically ships with an updated V8 engine, which usually improves performance, but they also work on optimizing Electron itself (for instance: [1]). I think most of the times if an Electron app is not snappy enough then the developers didn't spend enough time optimizing it, take a look at VS Code vs Atom for instance, I haven't used Atom in a while so maybe the situation in different now, but both are Electron apps, VS Code is fast and Atom is (was?) not. [1] https://github.com/electron/electron/pull/14633 https://github.com/electron/electron/pull/14633
  - InGodsName 8y ago
    I think it's because VSCode uses typescript and it had better plugin architecture. VSCode also uses lazy loading so doesn't initate everything at once you click the launcher icon but does it progressively.
    - fabiospampinato 8y ago
      VS Code doesn't provide direct DOM access to extensions authors, that's definitely a deciding factor. But a couple of years ago even simply writing inside Atom without using any extension felt sluggish to me. TypeScript gets downcompiled to JavaScript anyway, so I don't think that's directly a contributing factor, but maybe because of the type system they can spend less time debugging and more time optimizing.
    - bitwize 8y ago
      It's because much of the guts of VSCode is written in C++ and optimized. Because, you know, Microsoft.
      - InGodsName 8y ago
        So eletrons lets you code part of it in C++?
        fabiospampinato 8y ago
- tschellenbach 8y ago
  Lately Atom is running quickly for me, but Goland is very slow and resource intensive. So I guess it varies, but Electron starts at a disadvantage.
- simion314 8y ago
  >Does the Electron team have a focus on improving performance? Or is the issue with the developers using electron, should they be optimizing better? I think the main issue is the developers, some apps don't use so much memory where others seem to use too much for the features they provide, IMO most JS developers do not understand how GC works and how you can by mistake keep objects alive. There is also the issue where you do not have a default UI toolkit and some frameworks like angular are bad for performance(I mean how in angular codes I seen data binding trigger tons of unnecessary updates but maybe some will blame the developers using it wrong)
amelius 8y ago
I'd love to see a version that is based on Firefox / SpiderMonkey.
- nerdponx 8y ago
  Would be interesting to see another FirefoxOS attempt.
- pjmlp 8y ago
  It was called XUL, long before the Electron craziness.
  - maxxxxx 8y ago
    That's an area where Mozilla could have distinguished itself by being very developer friendly. A few years ago I was looking into embedding a browser and XUL would have been a good fit but it was pretty obvious that it wasn't supported well. Same for their Javascript engine. Node could be running on Mozilla code instead of V8 if Mozilla had been more developer friendly.
- crc32 8y ago
  https://github.com/mozilla/qbrt https://github.com/mozilla/qbrt is a continuation from https://github.com/mozilla/positron https://github.com/mozilla/positron - last commit 6mo ago though. Probably what is needed is a killer app - VS Code, Slack, Spotify...
- neonhomer 8y ago
  There was one started called Positron, but it was discontinued in early 2017. https://github.com/mozilla/positron https://github.com/mozilla/positron
- ChrisSD 8y ago
  You'll have to wait until the Quantum/Servo project is much further along.
- wodenokoto 8y ago
  This was actually a thing a decade ago. But Mozilla did not keep engine and browser well enough separated, causing a lot of overhead for app developers basing their programs on the gecko engine.
Artemis2 8y ago
⌘+F “performance” or “memory” does not show anything :-/
- nkozyra 8y ago
  See: https://chromium.googlesource.com/chromium/src https://chromium.googlesource.com/chromium/src
- drb91 8y ago
  At this point, especially after seeing how snappy vscode can be, I’ve written off slack’s performance issues to their codebase.
  - EpicBlackCrayon 8y ago
    Yup, another good example of this is Hyper vs. Terminus. Both Electron apps, but Terminus is way more performant and less memory hungry. I've taken that (along with Slack vs. pretty much every other Electron app) to mean that yes you're going to get some sort of inherent performance hit going Electron over native, but a huge performance hit can arise from a crappy architecture/implementation. For instance, doesn't Slack use a different webview for each channel?
  - beagle3 8y ago
    The MS team worked very hard to make it snappy; e.g. it doesn't dump the entire file into the DOM if it is big (but rather materializes it as needed, and removes sections not viewed). That's the kind of tricks that the DOM (so web and also Electron) were supposed to make irrelevant. Write an app "naturally" with Electron, and it will likely be slow because of the DOM <-> data impedance mismatch. That's what slack is guilty of, but the ability to do so is Electron's claim to fame.
bluetidepro 8y ago
Say what you will about Electron, but congrats to the team on getting 4.0.0 launched!
duarteoc 8y ago
Congrats team, looking great!
moron4hire 8y ago
I like Electron's features, but I don't like how it runs its own Chromium. I'd really like a small, local server launcher that just runs whatever default browser the user has selected, with a borderless window. No attempt at auto-integrations between client-view and server code, just let me do it like a regular SPA. Bonus points for letting me specify my own server executable, so I can do it in whatever language I want. EDIT: seriously, it could run its own local server for privileged OS integrations, giving you an IPC API over REST.
- MrGazzo 8y ago
  So like a PWA?
- smaddock 8y ago
  Have you seen Carlo [1] yet? It's the closest thing available to what you're describing. Main drawback imo is that it's Chrome-only. [1] https://github.com/GoogleChromeLabs/carlo https://github.com/GoogleChromeLabs/carlo
- ravedave5 8y ago
  There was a rumour that with Edge going to chromium MS wants to make the engine available on windows so that electron on windows wouldn't need to ship with a copy of chromium.
  - topspin 8y ago
    Given that Microsoft recently acquired the primary Electron developer, GitHub, that concept seems plausible. And I have a difficult time finding fault with it. You see endless 'concerns' about Electron resource usage. What you don't find are complaints that it's unstable, or that it only works on some desktops, or that it's hard to understand or use. It's solid, it works on all desktops and it's about as easy to use as such a thing can be for contemporary full stack developers. For better or worse I think the whinging about resource usage isn't going to hinder Electron much.
azhenley 8y ago
I really want to use Electron for a project I have coming up since it checks all the boxes, but all I ever see are complaints about the performance :( Is the performance really that bad? Plenty of successful applications are using it. Is there a fix in the horizon?
- msvan 8y ago
  I don't think it is fixable. Embedding Chromium is going to eat computer resources. This is the price of simple development for the desktop.
- ilikehurdles 8y ago
  Try the applications and judge for yourself. There are tons of them. Most people are probably OK with the performance of apps like Spotify, and have never come close to exhausting their memory or disk space. I think being able to use HTML and CSS for layout, but with full access to native APIs, is a huge reason electron keeps winning despite the hn complaints. I’d be happier without it being JavaScript-based, but there are nice languages that compile down to it, like Elm and clojurescript.
  - Royalaid 8y ago
    I would also like to echo this. Yes most of everyone on HN hate Electron and they can point out any number of reasons why it's bad, and they would correct. In spite of the technical problems Electron is still seeing growth and continues to ship in new products. If you think Electron works for what you need I would say use it and just ship, once you have more resources reevaluate if it is or is not working.
- ionised 8y ago
  Consider that each Electron app runs its own instance of Chromium. Chromium itself is a memory hog and apps like Slack routinely take up to a gigabyte of memory. For a fucking chat app. How many Electron apps does the average developer run on his machine now? I'm back-end developer and I still need four or five Electron apps running to do my job. All in all they are taking up between 4-7Gb of memory. That's just absurd to me, and we are all on 2017 MacBook Pros with 16Gb RAM. Combined with Docker, IntelliJ, Robo3T etc, I'm pushing up against my RAM limit frequently, because Electron apps are all a bloated mess. Every single one of them. It's even worse if we start getting multiple end-user apps are written with Electron, because the average consumer machine doesn't have a lot of memory like developer machines tend to have. This kind of development shouldn't be encouraged in my opinion.
hs86 8y ago
For Chrome users that leave the browser open all the time, is there a reason to choose an Electron based chat-app, that usually sits in the background, over just installing its PWA on the desktop? Chrome now supports native notifications on Windows/macOS and even apps without full PWA support seem to work fine by just creating a shortcut and setting it to open as a new window without the browser's UI.
- bn-usd-mistake 8y ago
  I assume this is due to a web limitation: Discord has system-wide push to talk (I.e. system wide shortcut) only in the electron app, not in the PWA.
  - WorldMaker 8y ago
    Yeah, there's lots of little things in the Electron API that would be good to see adopted into PWA standards. Probably also some Node native modules out there that would be good candidates for PWA standards. With so many Electron apps in the wild these days, it seems like a great opportunity for the standards bodies to comb them for good ideas for greater platform-wide adoption. (What are people doing in Node processes in Electron that would be tough to do in {Service, Web} Workers? What APIs for deeper native integration would be of benefit?)
- saint-loup 8y ago
  For me the reason would be first-class status in the taskbar/dock. I like having some apps only a click away and in its own window, not lost among many open tabs. For some time you could do that with any web page in Chrome, with "the create a shortcut" option. But now Chrome opens them in a new tab, not in a dedicated window.
  - hs86 8y ago
    After adding the new shortcut you can go to chrome://apps and right-click on any app to select "Open as window". This should bring back the desired behavior and these app shortcuts now have their own entry in my taskbar/dock.
lousken 8y ago
if only electron vanished from the earth...
- dang 8y ago
  Please don't post unsubstantive comments here.
- exitcode00 8y ago
  Think this is bad? Just wait until everyone adopts asm.js. So we can compile C++ code to "fast web apps" which will run in the asm virtual machine, in the javascript DOM sandbox, in the thin webbrowser client, and finally in the OS. You can laugh, but that day is coming and I fear getting armies of college grad hipster-coders creating unreliable slow layered software until we have nothing but "Material" UI flat buttons and cursor lag when typing simple messages in a simple application. AHHHH
  - jf- 8y ago
    But think of the competitive advantage you can gain from doing your app natively. If they really are so slow then you’re in the money.
    - lousken 8y ago
      Problem is that i'm sysadmin so i have to deal with the results, but i guess i could start business with native apps.
  - AnIdiotOnTheNet 8y ago
    You forgot the new OS wars, which happen on top of this "platform". Remember guys, one more layer of abstraction is all we need, then there will be no more problems forever!
    - exitcode00 8y ago
      ROFL, at some point there will be a javascript CPU (https://twitter.com/steipete/status/1047415826083729408 https://twitter.com/steipete/status/1047415826083729408) - and the entire OS will be asm.js. Then the cycle will begin anew with web browsers being built for the OS. God help us all D:
burtonator 8y ago
I've been heads down into the Electron internals for 2-4 months now and working on a document manager for PDF and web content: https://getpolarized.io/ https://getpolarized.io/ (self plug) The inevitable thing that always gets brought up is memory usage. It's really not insanely bad if the app is important. I wouldn't use it for a calculator but if it's an important app allocating 150MB of RAM seems worth it. The biggest change here seems to be the build system and the upgrade to Chrome. The Chrome updates are what's important here. Since Chrome is evergreen if your behind a few versions the standard libraries in NPM just stop working. I got bit a while back when when they were a bit behind in releases.
- diminoten 8y ago
  Who doesn't have 150MB to spare? This laptop has 16GB, why are people hemming and hawing over 150MB???
  - hyder_m29 8y ago
    A lot of electron apps (like Slack) could well use over 1GB.
    - diminoten 8y ago
      So I guess I can only run ~16 instances of Slack. Damn...
      - arama471 8y ago
        But that implies you _only_ run Slack.
      - leppr 8y ago
        That means a $1k+ computer with Linux can only run 16 Slack instances. If you're on Windows and aren't as wealthy, the count goes down to 5. Soon you have to micromanage your computer resources instead of purely focusing on work.
legostormtroopr 8y ago
I can't wait to hear about all the new features at ElectronConf... oh... nevermind.
- bluetidepro 8y ago
  I don't get the joke? Is/WAS "ElectronConf" a real thing?
  - dx87 8y ago
    It was going to be, but they didn't have enough minorities and woman giving talks, so they cancelled it. Looks like they deleted the announcment, but here is an old reddit post where people are talking about it. https://www.reddit.com/r/javascript/comments/6f8u2s/githubs_electronconf_postponed_because_all_the/ https://www.reddit.com/r/javascript/comments/6f8u2s/githubs_...
    - sifoobar 8y ago
      Surreal. I guess the good news is that this level of dysfunction should take care of the other Electron issues all by itself if we just wait a little while.
    - choochootrain6 8y ago
      GitHub is just scared they're going to have PR problems because of the 2014-2016 lawsuit. Hopefully Microsoft can fix GitHub's broken mentality towards gender inclusiveness.
  - g45y45 8y ago
    yeah, but it was postponed because the speakers were all men. Some reddit commentary: https://www.reddit.com/r/javascript/comments/6f8u2s/githubs_electronconf_postponed_because_all_the/ https://www.reddit.com/r/javascript/comments/6f8u2s/githubs_... the official site just has a logo: http://electronconf.com/ http://electronconf.com/
  - deleted 8y ago
    [deleted]
jeklj 8y ago
Looking forward to the many positive comments here regarding this widely-used piece of open-source software.
sidcool 8y ago
I have heard a lot of complaints about Electron on various aspects, but one thing it has done well is to open the niche of cross platform Desktop apps to an average regular developer like me. It can be also used to quickly test an idea before dedicating platform specific resources. I hope the team adds more features keeps Electron alive.
- criddell 8y ago
  Microsoft adopting Chromium is a big hint that they are going to make some big investments in Electron. I think Electron's future is bright. My big complaint isn't the resource usage, it's how the applications never feel right on any platform.
  - krzyk 8y ago
    Exactly, Electron apps feel always like webpages :(
    - jazoom 8y ago
      I've never once felt VS Code was a webpage.
      - criddell 8y ago
        It feels close to that for me. It definitely feels foreign on every platform.
        y4mi 8y ago
        IntelliJ has the same problem. so does everything adobe creates and ... honestly, almost everything that caters to a niche doesn't really try to be native, as that would often create an inferior product for that specific usecase. though there are very bad examples as well. all these chat apps like discord, slack and rocketchat for example.
  - chr1 8y ago
rewgs 8y ago
One major issue with Electron that I don't see talked about much is backwards compatibility. This release states that because Chrome no longer supports Mac OS 10.9, Electron doesn't either. Resource usage aside, there's far too much control of a given app being given to the Chrome team.
- jlokier 8y ago
  Ouch. Thanks for mentioning the issue. I'm still happily using 10.9 on my main laptop and in no rush to change, and I was hoping to look into using Electron for a project, so that's going to be awkward.
  - sroussey 8y ago
    Does Apple make security updates for 10.9 anymore? Seems like a security risk.
    - godDLL 8y ago
      Having used all of the subsequent iterations of OS X, now I will be reverting to my Time Machine copy of 10.9 because really, the usability of it has gone downhill from that point on. Or even 10.8, I'm not yet sure. Who cares if it's secure but sucks so much that I'm not using it anymore?
- tuananh 8y ago
  that's a known limitation right from when they started this project.
fabiospampinato 8y ago
There are always many negative comments regarding Electron apps, so as a developer who has made a couple Electron apps let me briefly illustrate to you what the advantages are: - I can use the same UI components that I use for making websites and easily share code between all platforms. Maybe this will change in the future with the advent of WebAssembly, but right now no other stack gives you this. - Bundling a cross-platform auto-updating app is wonderful. I just have to configure electron-webpack [1] and everything is taken care of. In the past I've made a password manager with GTK3 + Python, bundling it was a real nightmare and I don't think the situation improved much in the last few years. - Sometimes, like when you're going to need a HTML renderer anyway, using basically a browser for rendering the UI can actually be an advantage, a couple of examples: Example 1. Evernote needs to render their notes, basically arbitrary HTML, and the macOS app uses Safari's engine for this. Now they have to check across all platforms if their notes are always rendered the same, even for rendering a simple note they show you a spinner, and the native UI is arguably ugly anyway. In comparison my soon-to-be-released Electron note-taking app [2] looks more native to me, it's faster, requires less resources, and I get cross-platform support basically for free. Example 2. I was using Ship [3], an app for managing GitHub issues. The native parts of the UI were written in Objective-C, the issue/comments part were written using web technologies, and their server was written in C#. What you get is an app that doesn't work across platforms and sharing code between all the parts of your application is basically impossible. - Lastly I'm by no means an expert on other cross-platform UI toolkits, but some of them try to mimic the native widgets and do an awful job at that, as a result I don't have any Java GUI app installed because they all looked like crap to me, how many do you have installed on your desktop? [1] https://github.com/electron-userland/electron-webpack https://github.com/electron-userland/electron-webpack [2] https://imgur.com/a/ZQd8Vad https://imgur.com/a/ZQd8Vad [3] https://www.realartists.com/blog/ship-20.html https://www.realartists.com/blog/ship-20.html
- LeoPanthera 8y ago
  > I can use the same UI components that I use for making websites and easily share code between all platforms. I propose that using web components for desktop/mobile applications is not a good thing.
ronlobo 8y ago
Nice! Has anyone played around with flutter.io? Is it similar to electron?
- forgot-my-pw 8y ago
  Flutter for desktop is still pretty new, but it sounds promising. https://medium.com/flutter-community/flutter-on-desktop-a-real-competitor-to-electron-4f049ea6b061 https://medium.com/flutter-community/flutter-on-desktop-a-re...
  - choochootrain6 8y ago
    If Fuschia becomes the next big OS do you think Flutter could replace web technologies?
faitswulff 8y ago
Discord seems to buck the trend of both Electron and React Native being bloated and slow. How do they do it?
- Klonoar 8y ago
  The thing about Electron (that is often drowned out in these threads) is that it's a web browser, which means... like any website, there's a litany of weird performance tricks you need to know and be aware of to make a good performant UI that doesn't have performance degrade over time. Like many websites in tabs in a browser, sometimes... it's easier to just kill the tab or window, and re-open it. Usually a sign you've done something wrong in your UI handling code.
rafaelvasco 8y ago
I stay away from Electron and JS desktop apps in general because: - Huge distribution size. Your code is 1% at most. 99% is redundant. I want 10 meg at worst hello world dist size. - This is more a problem in JS ecosystem in general: No good enough standardized or not way to do the frontend part of the app. Angular is not good enough, neither is React or anything else. Though it is gradually getting better.
patagonia 8y ago
So someone should clearly fork it to Firefox. Not me. Not if you want it done right. There has been a lot of talk on HN about Chrome having to big a slice of the pie. Whelp.
PascalW 8y ago
A lot of people express concerns about Electrons resource usage. I wonder if people are aware of projects like zserge/webview [1]? It provides a cross platform API on top of the built in platform browsers and thus is very lightweight. Of course, it means you have to deal with cross-browser issues, but I guess webdevelopers are used to this anyway. I'm also aware that these projects don't provide all the APIs that Electron provides, but many apps that are really just a wrapper around a webapp this is totally fine IMO. [1] https://github.com/zserge/webview https://github.com/zserge/webview
- skymt 8y ago
  That doesn't seem like it would solve anything, unless I'm missing something substantial. Which specific browser engine it uses isn't as important for resource consumption as the fact that it's spinning up an entire browser engine per process.
  - PascalW 8y ago
    At least the binaries are substantially smaller because they don't actually include the browser. I can also imagine there's some potential for sharing the same engine across multiple apps, though I'm not sure if they actually do this.
tommoor 8y ago
I've worked with Electron and previously NW.js for over 6 years. Here's what you need to know – if an apps performance is bad 99.9% of the time it's the developers code, not Electron that's the issue. Sure, the bundle size is large and the memory footprint is ~200Mb but those should not be limiting factors if you have a computer from this decade.
casper345 8y ago
I use Electron as a quick MVP for basic apps. If the apps become more complex, then we will talk about moving to a native platform if we need to focus on native libraries or performance. Pick the tool for the job at hand.
dolguldur 8y ago
One of the less obvious reasons why Electron has become so widely used is that Apple hasn’t invested anything meaningful into improving AppKit in the last 5-10 years. If Cocoa was a joy to use I’m sure there would be more native apps.
dtougas 8y ago
I have high hopes for Electron. In some regards, it feels like the new Java. I remember in the early days, using Eclipse and thinking how bad the performance was, but appreciated all the functionality it brought, despite being written in Java. Now days, I am in love with the JetBrains IDEs, and don't think twice about the fact they are Java. The performance is great, and they look good (IMHO). I suspect that in the future we will feel the same way about Electron apps.
mezzode 8y ago
I still think that the majority of Electron apps can and should just be PWAs. Most like Discord pretty much just wrap their webapp anyway.
solarkraft 8y ago
> Electron v4.0.0 includes Chromium 69.0.3497.106 Isn't this already outdated by months?
johnwyles 8y ago
Isn't it funny the Palm Pre was in some sense what Electron apps have become? Just an anecdote - I understand all the differences between them but I didn't even think at the time the Pre came out that it was "ahead of it's time" but I suppose it was - then again there was also the iPhone that killed it as well.

233 points by gozzoo 8y ago

I always read about how Electron is very resource-intensive, but I'm curious as to how the performance improves as time goes on? Does the Electron team have a focus on improving performance? Or is the issue with the developers using electron, should they be optimizing better? I assume it's some of both, but curious if anyone with more experience in electron can provide any insight as to how the performance changes over time.

accatyyc 8y ago
The issue itself is that Chromium uses a lot of memory. And electron basically just runs Chromium. Except that since each Electron-based app ships its own very isolated copy of Chromium, the following problems occur: - The operating system cannot share memory between different Electron processes. Normally if you start many processes of the same binary, the memory is shared and only copied on write. Since each Electron app is a different binary (even though they are 99% identical) they each eat memory. - The above applies to disk size as well. Electron apps are usually huge, and 99% of the binary is the same as all your other electron apps. This is mostly why I'm against electron. If electron worked like the JVM and each app shared a runtime, many issues would be solved, including many electron apps running old, and vulnerable versions of Chromium. Now it's only updated if the developers decide to ship a new version.
- alex_suzuki 8y ago
  The last point is something that in theory could have been achieved (shared runtime) with Java or .NET, but in reality there are real, tangible benefits to shipping self-contained applications, and the disk size argument is just no longer that relevant. This is in no way an endorsement for Electron, just an aspect common to all platforms that rely on an intermediate runtime that could in principle be shared.
  - realusername 8y ago
    > the disk size argument is just no longer that relevant. But the memory one definitely is, I don't want each app to take 1GB of ram.
  - fredley 8y ago
    Disk size argument no but memory yes. Keeping this massive binary duplicated in memory for every trivially small (memory-wise) app, like Slack, is bananas.
  - wodenokoto 8y ago
    Actually disk size argument is still relevant. My brand new MacBook pro has the same disk space as my 10 year old MacBook pro. While hard drive space is cheap on spinning drives, space on consumer devices has stagnated or even decreased with the move to ssd
    - rubber_duck 8y ago
      We are still talking ~100MB (from what I can see my entire VS Code install folder is 170 mb - 100 probably goes off to chromium stuff) - even if you use 10 electron apps 1GB of memory isn't going to kill your drive - really not worth the tradeoff and effort considering the alternatives.
  - PavlovsCat 8y ago
    > there are real, tangible benefits to shipping self-contained applications Here's one that doesn't suck: https://sqlitestudio.pl/ https://sqlitestudio.pl/ Maybe that was very complicated to make, all I know is that it's blazing fast and doesn't hog memory. Or hey, take OggDrop and LameDrop, I'm sure there's programs that do the same, are 100 times as big and have 3 options. I don't know if there are 10x programmers, but I know there are 100000x programs, with not one electron app among them.
    - kimmel 8y ago
      I love SQLiteStudio. On my machine it starts up in < 2s. Version 3.2.1 takes 99MB disk space and is built against QT5. I just ran some queries and the memory usage is only 80MB for a not too large database. Another self-contained application I like is racket/drracket.
- PaulHoule 8y ago
  Why is it that people seem to think using a cross-platform UI toolkit like tkinter, kivy, WxWindows, etc. is like putting their hand in a toilet? Lately I have been building apps with tkinter/python/asyncio and I can't get over how fast the apps are to load and to use. There is none of this "let's not respond to the mouse for 5 seconds" that is staggeringly common on my mac (particularly for apps like Safari and iTunes that come from Apple) nor the "go for a walk around the block" loading times for Java-based apps on my i7 Windows laptop. True tk apps are ass-ugly but I find it mind-blowing to use GUI apps that are as responsive as Windows 95 apps were back in the day.
  - eddieroger 8y ago
    Do they think that? I think more what thing here is that Electron apps are popular with UI developers who want to make the jump from web apps to native apps without taking the time to learn the platforms, or wish to reuse components they use on their web apps.
  - androidgirl 8y ago
    The aversion is mostly that a lot of devs have learned to use html, css, and js for styling ui's. I love Kivy as well as QT. You can make some decent looking apps with the former and some incredible ones with the later. I have never personally worked with Electron. But yeah, most devs use JS, HTML, and CSS for ui creation because of the Web. I think something like QML could replace the html and css parts, though.
    - giobox 8y ago
      To add to this point, virtually all software companies have devs with web dev experience that can be very easily leveraged with Electron. Native app development skills aren’t nearly as prevalent in most organisations in my experience. The success of electron has never been that much of a surprise to me: write once, ship (almost) everywhere, use the team you already have. Often cheaper than upskilling the team as well.
  - jniedrauer 8y ago
    > Why is it that people seem to think using a cross-platform UI toolkit like tkinter, kivy, WxWindows, etc. is like putting their hand in a toilet? tkinter specifically does not look very pretty without some effort. I would much rather use GTK or QT. The problem is GTK support on windows is limited, and QT has a weird license model.
- jf- 8y ago
  Is there a reason it’s not done as a runtime, i.e. have a single, electron-modified, backwards compatible install of chromium which all the electron apps run on? Then ship each app with the installer for that electron-chromium which gets installed if it’s not already present. Though I feel like even if that happened people would still complain about it, mostly motivated by web technologies encroaching on the desktop space, threatening other developers “turf”, so to speak.
  - megous 8y ago
    No there isn't. For example on Arch Linux, you can do pacman -S electron and share the same runtime for all your electron apps. Though, I don't use any third party ones.
    - jf- 8y ago
      That’s interesting. Is there something specific to arch that allows this? It would definitely help to alleviate people’s concerns about electron if this could be replicated on other platforms.
      - megous 8y ago
        Nothing specific. You can do it with electron executables downloaded from the official website. Just run them, and drag'n'drop directories with the application's source code onto the electron window, or create desktop shortcuts that run "C:\somewhere\electron.exe C:\your\app\dir".
    - simion314 8y ago
      This would work only for packaged apps from the repos right? Better then nothing.
      - megous 8y ago
        I didn't find any apps in the repository. This works for apps you write yourself. You just run "electron ." in the directory with the app's source code. You can probably unbundle thirdparty apps, becuase what electron apps are, are basically "electron" + "other code/resources". But I've never even seen someone else's electron app distribution package, so I don't know how hard/easy it would be. And I wouldn't trust it anyway, if the code is transpiled/minified/unreadable. I run all my electron apps using a shared runtime.
- ancorevard 8y ago
  The root cause of the problem with Electron is that its performance on the Mac is just like the Chrome browser. Compared to Safari, Chrome’s performance is like a fat pig hogging your memory and devouring your battery life.
- felixfbecker 8y ago
  When I tried out Windows tabbed shell in the Insiders build I found myself using the web versions of Electron apps (e.g. Slack) way more than the apps. They can do everything the app can nowadays (including native notifications), and with tabbed shell, they can appear next in a tab right next to a native app - but with all the benefits of web apps: linkability, hackability through browser extensions, accessibility, no annoying update prompts. And of course only running one browser engine instance. You can even pin them to your task bar like native apps. I feel like on macOS many people install native apps only to have a dock icon. We really overvalue packaged apps
  - drb91 8y ago
    > We really overvalue packaged apps I think splitting out services from the browser makes it easier to focus on notifications and use window management to change contexts. It is confusing and frustrating that Apple has not allowed saving websites to apps yet.
- SigmundA 8y ago
  Wouldn't memory compression and disk compression resolve those issues to some degree? Sharing libraries is definitely more efficient but at the cost of isolation and versioning issues. Similar to some of the reason vms and containers are used. Over time I have come to appreciate self contained apps and deal with redundant bytes at a lower level.
- seanalltogether 8y ago
  > This is mostly why I'm against electron. If electron worked like the JVM and each app shared a runtime, many issues would be solved, including many electron apps running old, and vulnerable versions of Chromium. On the other hand, requiring a shared runtime has been one the key reasons that a lot of cross platform apps failed in the past. How many times have others decried the fact that they had to install Java or Adobe AIR or XYZ in order to run an app they needed.
  - sime2009 8y ago
    Well, there was a solution to that last problem. Just bundle the whole runtime with the product each time. And just like that we're back at square one again...
  - Splines 8y ago
    Steam seems to solve this fairly well. If you need a runtime it is installed along with the product.
- jackpeterfletch 8y ago
  - If electron worked like the JVM and each app shared a runtime You mean like eerr, chrome - and the web :P
- blinkingled 8y ago
  > - The operating system cannot share memory between different Electron processes [..] That should not be a significant issue in 2018 - all popular operating systems have same page merging support now and at least latest Win10/macOS also have transparent compression of memory pages.
  - ryacko 8y ago
    Woudldn’t that break ASLR?
    - blinkingled 8y ago
      ASLR applies to virtual memory / process address space. Merging or compression is of physical pages - the page is uncompressed on the fly when the process accesses it. It works because the OS is in control of the Virtual->Physical mappings and can, on a page fault do the decompression transparently for e.g.
  - ahartmetz 8y ago
    Compressing working memory is quite expensive in CPU cycles compared to just using it. Identical page merging is also reasonably expensive and only works if pages are, well, identical. Your Electron runtimes are probably not going to be bit for bit identical, not even small sections, due to offsets not divisible by page size. Tuning for better deduplication is possible, but then you're at an awkward mix of caring and not caring about performance.
    - blinkingled 8y ago
      Compression is pretty fast on modern CPUs so I would disagree about that. But yes depending on the compiler/switches/versions the Electron run times are not going to be bit for bit identical but it's a stretch to say there will be nothing in common - all the dependent library code for e.g.
- scoopdewoop 8y ago
  It is absurd the people that show up out of the woodwork every Electron article to complain about performance. Meanwhile, I have not closed Discord for more than a day or two in years. A quick Ctrl-Shift-Esc shows that it is using 180MB of RAM right now with ~20 rooms open, as well as DMs. Meanwhile, Discord has fantastic uptimes and never impedes performance while competitive online games run alongside it. The idea of trying to replicate the interface in something like tkinter is cringeworthy at best. Discord supports animated gifs, modals, videos, emojis, fonts, code samples, markdown, and game integrations right in the chat! Please, please try and replicate that with Tkinter, an API where you'd need to roll your own drag-and-drop. If i want to run discord as a website, using the same resources as any other website, i CAN! Its the same codebase and interface. I run the full desktop client for the better filesystem, game, and chat integration and it is worth the measley RAM on my modern machine. Discord is an intelligent start up that was able to pivot from a chat client to a games marketplace with a one-click update. Their use of the erlang VM shows that they make considered tech decisions based on tested technology. I think their use of electron, at least from this users perspective, was a great decision. I realize they are just one example of electron apps, and I'd have a harder time defending a file-unzipper or some madness using Electron, but it no doubt has its uses. To suggest otherwise would be premature optimization at best.
  - zozbot123 8y ago
    > animated gifs, modals, videos, emojis, fonts, code samples, markdown, and game integrations Noted, and that's a fine use case for the Browser engine + HTML + CSS + JS/WASM tech stack - but how many native apps need that sort of rich view?
  - seba_dos1 8y ago
    Not commenting on anything else, but Discord app consuming 180MB RAM sounds like a mismeasurement. Here it takes almost 0.5GB right after launching.
    - mbell 8y ago
      They are most likely only looking at the RAM used but the 'Discord' process, which is just the native launcher code and OS hooks (on MacOS here, may be different on other OSes). The electron processes are called 'Discord Helper' and will be using quite a bit more RAM, though I still wouldn't consider it 'heavy'. The same process structure is true of Slack as well (maybe all electron apps, I'm not familiar enough to say). Both Slack / Discord use around 400MB including all processes on my machine, tho it certainly varies with what is on screen. In comparison to the gmail tab I have open in Safari that is using 1GB, 400MB isn't bad.
- Aaronmacaron 8y ago
  I don't think a JVM like chromium engine would really solve the problem. Most JVM end user applications ship their own JVM. By shipping your own JVM one can avoid compatibility problems and most importantly the user doesn't has to install the JVM which makes for better UX. The same would apply for Electron. The only way I think a common runtime could work is if Electron used the Runtime of the Browser. If every browser exposed an API to run JavaScript and Render HTMl using the browser's Engine that'd be great.
  - vincnetas 8y ago
    Why expose api. One could run web server on localhost and thats it. Open it with any browser and enjoy your crosplatform app. I think https://blockstack.org https://blockstack.org is doing something similar.
  - vincnetas 8y ago
    Adding to my previous comment, you can even run chrome webpage without address bar on macos : /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --app=https://google.com https://google.com
- manigandham 8y ago
  Why does this matter on any modern operation system and hardware? What is the point of unused RAM capacity given fast mem/disk IO, compression and seamless paging?
  - zozbot123 8y ago
    Disk IO is not always fast. Memory bandwidth is a huge bottleneck on current-day systems, especially on high-frequency, high-core-count processors. And so on and so forth. If you want a snappy and truly usable system you still need to care about performance issues, particularly given the rise in non-reducible system requirements e.g. for browsing the modern web.
- Sindisil 8y ago
  > If electron worked like the JVM and each app shared a runtime Unfortunately (or fortunately, depending upon your point of view), the JVM world has moved to a model of embedding a JVM with each app, as it can be less problematic for developers (and lets Oracle remove a bunch of subsystems from the JDK, reducing their development and maintenance). On the up side, though, newer releases of Java provide jlink, so that the JRE can be stripped down to exclude subsystems that aren't used by the app. Also, several JVMs still support class data sharing, so if multiple instances of an app are launched, they can share some common class data.
sergiotapia 8y ago
Either they start working towards performance/memory issues or this will very likely go the way of Cordova/PhoneGap. Feature rich, but ultimately forgotten and not used for new projects.
- NatW 8y ago
  I don't think VSCode is going away. It's built on Electron[1] and performs quite adequately for me, personally. [1] https://en.wikipedia.org/wiki/Visual_Studio_Code https://en.wikipedia.org/wiki/Visual_Studio_Code
  - nni 8y ago
    I've only very rarely seen performance issues with VSCode...
  - intertextuality 8y ago
    VSCode seems to be one of the exceptions. It's also not as fast as Sublime Text.
    - 0xCMP 8y ago
      Agree, but because it's JS and well designed plugins also affect the editor experience much less. Where in Sublime the Python based plugins which aren't designed around async and promise-like patterns often can lock up the editor waiting on them. VSCode is pretty much the best Emacs there is right now. Uses JS, has good package management, allows changing settings per "workspace" including enable/disable plugins, has great git support, pioneered LSP, and more. I literally want to hate VSCode, but there isn't much to hate and any weakness it has can/should/likely-will be addressed by a plugin.
    - GuB-42 8y ago
      Performance is the reason why I stayed with Sublime Text. I gave VSCode a try, and it is really great, and transition from Sublime Text is easy. They probably stole most of their good ideas from it, while improving on others, a practice that I definitely support. However, it is not as responsive. By that, I mean sub-second stutters, nothing game breaking, but enough to affect the feel. Note: coding in C++, using the LSP plugin on Sublime, and the standard language support on VSCode. Building and source control done separately on the command line. I use "modific" on sublime to see the differences, and the built-in support for VSCode.
CyberDildonics 8y ago
The biggest issue by far with every electron based program I've used is actually not the huge memory foot use or the hundreds of megabytes for a simple program, it is the latency of the interface. Every interaction ends up lagging like molasses, whether it is text input, window resizing, startup time etc. We have video games that run 3D environments with gigabytes of geometry and textures at 144hz yet people are making simple text editors and interfaces with a dozen simple components (like the ethereum wallet) that run xwindows streamed over a 56.6 modem.
- jeffbax 8y ago
  Nevermind the small but incredibly obvious stuff like keyboard shortcuts, drag and drop behavior and text selection…
- spiralganglion 8y ago
  I think this is an excellent criticism of Electron that seems to be buried. Sure, it’d be nice if the RAM usage and disk footprint of electron were smaller. Maybe the creation of some sort of shared single instance of chromium will happen, someday. But even if it does, the browser rendering process is really latent unless you’re extraordinarily careful. It’s very challenging to make sure that your app responds to input within one frame — batching updates with requestAnimationFrame creates a visible delay when dragging and typing. It’s possible to do better, but it’s hard and almost nobody does. And it’s easy to do a lot worse — RAIL isn’t aggressive enough. (My angle on this — I do high-performance 2d/3d animation work in the browser and in electron, with extensive testing of latency, energy usage, frame rate stability, etc)
  - ahartmetz 8y ago
    I've heard a similar story about an app implemented in HTML5 and node.js (no good JS UI frameworks existed at the time). The fine-tuning took an extraordinary amount of time. I was on a project that redid it in QML in a fraction of the time with a fraction of the headcount and performance was great right away.
fabiospampinato 8y ago
Performance improves as each new version of Electron basically ships with an updated V8 engine, which usually improves performance, but they also work on optimizing Electron itself (for instance: [1]). I think most of the times if an Electron app is not snappy enough then the developers didn't spend enough time optimizing it, take a look at VS Code vs Atom for instance, I haven't used Atom in a while so maybe the situation in different now, but both are Electron apps, VS Code is fast and Atom is (was?) not. [1] https://github.com/electron/electron/pull/14633 https://github.com/electron/electron/pull/14633
- InGodsName 8y ago
  I think it's because VSCode uses typescript and it had better plugin architecture. VSCode also uses lazy loading so doesn't initate everything at once you click the launcher icon but does it progressively.
  - fabiospampinato 8y ago
    VS Code doesn't provide direct DOM access to extensions authors, that's definitely a deciding factor. But a couple of years ago even simply writing inside Atom without using any extension felt sluggish to me. TypeScript gets downcompiled to JavaScript anyway, so I don't think that's directly a contributing factor, but maybe because of the type system they can spend less time debugging and more time optimizing.
  - bitwize 8y ago
    It's because much of the guts of VSCode is written in C++ and optimized. Because, you know, Microsoft.
    - InGodsName 8y ago
      So eletrons lets you code part of it in C++?
      - fabiospampinato 8y ago
tschellenbach 8y ago
Lately Atom is running quickly for me, but Goland is very slow and resource intensive. So I guess it varies, but Electron starts at a disadvantage.
simion314 8y ago
>Does the Electron team have a focus on improving performance? Or is the issue with the developers using electron, should they be optimizing better? I think the main issue is the developers, some apps don't use so much memory where others seem to use too much for the features they provide, IMO most JS developers do not understand how GC works and how you can by mistake keep objects alive. There is also the issue where you do not have a default UI toolkit and some frameworks like angular are bad for performance(I mean how in angular codes I seen data binding trigger tons of unnecessary updates but maybe some will blame the developers using it wrong)

amelius 8y ago

I'd love to see a version that is based on Firefox / SpiderMonkey.

nerdponx 8y ago
Would be interesting to see another FirefoxOS attempt.
pjmlp 8y ago
It was called XUL, long before the Electron craziness.
- maxxxxx 8y ago
  That's an area where Mozilla could have distinguished itself by being very developer friendly. A few years ago I was looking into embedding a browser and XUL would have been a good fit but it was pretty obvious that it wasn't supported well. Same for their Javascript engine. Node could be running on Mozilla code instead of V8 if Mozilla had been more developer friendly.
crc32 8y ago
https://github.com/mozilla/qbrt https://github.com/mozilla/qbrt is a continuation from https://github.com/mozilla/positron https://github.com/mozilla/positron - last commit 6mo ago though. Probably what is needed is a killer app - VS Code, Slack, Spotify...
neonhomer 8y ago
There was one started called Positron, but it was discontinued in early 2017. https://github.com/mozilla/positron https://github.com/mozilla/positron
ChrisSD 8y ago
You'll have to wait until the Quantum/Servo project is much further along.
wodenokoto 8y ago
This was actually a thing a decade ago. But Mozilla did not keep engine and browser well enough separated, causing a lot of overhead for app developers basing their programs on the gecko engine.

Artemis2 8y ago

⌘+F “performance” or “memory” does not show anything :-/

nkozyra 8y ago
See: https://chromium.googlesource.com/chromium/src https://chromium.googlesource.com/chromium/src
drb91 8y ago
At this point, especially after seeing how snappy vscode can be, I’ve written off slack’s performance issues to their codebase.
- EpicBlackCrayon 8y ago
  Yup, another good example of this is Hyper vs. Terminus. Both Electron apps, but Terminus is way more performant and less memory hungry. I've taken that (along with Slack vs. pretty much every other Electron app) to mean that yes you're going to get some sort of inherent performance hit going Electron over native, but a huge performance hit can arise from a crappy architecture/implementation. For instance, doesn't Slack use a different webview for each channel?
- beagle3 8y ago
  The MS team worked very hard to make it snappy; e.g. it doesn't dump the entire file into the DOM if it is big (but rather materializes it as needed, and removes sections not viewed). That's the kind of tricks that the DOM (so web and also Electron) were supposed to make irrelevant. Write an app "naturally" with Electron, and it will likely be slow because of the DOM <-> data impedance mismatch. That's what slack is guilty of, but the ability to do so is Electron's claim to fame.

bluetidepro 8y ago

Say what you will about Electron, but congrats to the team on getting 4.0.0 launched!

duarteoc 8y ago

Congrats team, looking great!

moron4hire 8y ago

I like Electron's features, but I don't like how it runs its own Chromium. I'd really like a small, local server launcher that just runs whatever default browser the user has selected, with a borderless window. No attempt at auto-integrations between client-view and server code, just let me do it like a regular SPA. Bonus points for letting me specify my own server executable, so I can do it in whatever language I want. EDIT: seriously, it could run its own local server for privileged OS integrations, giving you an IPC API over REST.

MrGazzo 8y ago
So like a PWA?
smaddock 8y ago
Have you seen Carlo [1] yet? It's the closest thing available to what you're describing. Main drawback imo is that it's Chrome-only. [1] https://github.com/GoogleChromeLabs/carlo https://github.com/GoogleChromeLabs/carlo
ravedave5 8y ago
There was a rumour that with Edge going to chromium MS wants to make the engine available on windows so that electron on windows wouldn't need to ship with a copy of chromium.
- topspin 8y ago
  Given that Microsoft recently acquired the primary Electron developer, GitHub, that concept seems plausible. And I have a difficult time finding fault with it. You see endless 'concerns' about Electron resource usage. What you don't find are complaints that it's unstable, or that it only works on some desktops, or that it's hard to understand or use. It's solid, it works on all desktops and it's about as easy to use as such a thing can be for contemporary full stack developers. For better or worse I think the whinging about resource usage isn't going to hinder Electron much.

azhenley 8y ago

I really want to use Electron for a project I have coming up since it checks all the boxes, but all I ever see are complaints about the performance :( Is the performance really that bad? Plenty of successful applications are using it. Is there a fix in the horizon?

msvan 8y ago
I don't think it is fixable. Embedding Chromium is going to eat computer resources. This is the price of simple development for the desktop.
ilikehurdles 8y ago
Try the applications and judge for yourself. There are tons of them. Most people are probably OK with the performance of apps like Spotify, and have never come close to exhausting their memory or disk space. I think being able to use HTML and CSS for layout, but with full access to native APIs, is a huge reason electron keeps winning despite the hn complaints. I’d be happier without it being JavaScript-based, but there are nice languages that compile down to it, like Elm and clojurescript.
- Royalaid 8y ago
  I would also like to echo this. Yes most of everyone on HN hate Electron and they can point out any number of reasons why it's bad, and they would correct. In spite of the technical problems Electron is still seeing growth and continues to ship in new products. If you think Electron works for what you need I would say use it and just ship, once you have more resources reevaluate if it is or is not working.
ionised 8y ago
Consider that each Electron app runs its own instance of Chromium. Chromium itself is a memory hog and apps like Slack routinely take up to a gigabyte of memory. For a fucking chat app. How many Electron apps does the average developer run on his machine now? I'm back-end developer and I still need four or five Electron apps running to do my job. All in all they are taking up between 4-7Gb of memory. That's just absurd to me, and we are all on 2017 MacBook Pros with 16Gb RAM. Combined with Docker, IntelliJ, Robo3T etc, I'm pushing up against my RAM limit frequently, because Electron apps are all a bloated mess. Every single one of them. It's even worse if we start getting multiple end-user apps are written with Electron, because the average consumer machine doesn't have a lot of memory like developer machines tend to have. This kind of development shouldn't be encouraged in my opinion.

hs86 8y ago

For Chrome users that leave the browser open all the time, is there a reason to choose an Electron based chat-app, that usually sits in the background, over just installing its PWA on the desktop? Chrome now supports native notifications on Windows/macOS and even apps without full PWA support seem to work fine by just creating a shortcut and setting it to open as a new window without the browser's UI.

bn-usd-mistake 8y ago
I assume this is due to a web limitation: Discord has system-wide push to talk (I.e. system wide shortcut) only in the electron app, not in the PWA.
- WorldMaker 8y ago
  Yeah, there's lots of little things in the Electron API that would be good to see adopted into PWA standards. Probably also some Node native modules out there that would be good candidates for PWA standards. With so many Electron apps in the wild these days, it seems like a great opportunity for the standards bodies to comb them for good ideas for greater platform-wide adoption. (What are people doing in Node processes in Electron that would be tough to do in {Service, Web} Workers? What APIs for deeper native integration would be of benefit?)
saint-loup 8y ago
For me the reason would be first-class status in the taskbar/dock. I like having some apps only a click away and in its own window, not lost among many open tabs. For some time you could do that with any web page in Chrome, with "the create a shortcut" option. But now Chrome opens them in a new tab, not in a dedicated window.
- hs86 8y ago
  After adding the new shortcut you can go to chrome://apps and right-click on any app to select "Open as window". This should bring back the desired behavior and these app shortcuts now have their own entry in my taskbar/dock.

lousken 8y ago

if only electron vanished from the earth...

dang 8y ago
Please don't post unsubstantive comments here.
exitcode00 8y ago
Think this is bad? Just wait until everyone adopts asm.js. So we can compile C++ code to "fast web apps" which will run in the asm virtual machine, in the javascript DOM sandbox, in the thin webbrowser client, and finally in the OS. You can laugh, but that day is coming and I fear getting armies of college grad hipster-coders creating unreliable slow layered software until we have nothing but "Material" UI flat buttons and cursor lag when typing simple messages in a simple application. AHHHH
- jf- 8y ago
  But think of the competitive advantage you can gain from doing your app natively. If they really are so slow then you’re in the money.
  - lousken 8y ago
    Problem is that i'm sysadmin so i have to deal with the results, but i guess i could start business with native apps.
- AnIdiotOnTheNet 8y ago
  You forgot the new OS wars, which happen on top of this "platform". Remember guys, one more layer of abstraction is all we need, then there will be no more problems forever!
  - exitcode00 8y ago
    ROFL, at some point there will be a javascript CPU (https://twitter.com/steipete/status/1047415826083729408 https://twitter.com/steipete/status/1047415826083729408) - and the entire OS will be asm.js. Then the cycle will begin anew with web browsers being built for the OS. God help us all D:

burtonator 8y ago

I've been heads down into the Electron internals for 2-4 months now and working on a document manager for PDF and web content: https://getpolarized.io/ https://getpolarized.io/ (self plug) The inevitable thing that always gets brought up is memory usage. It's really not insanely bad if the app is important. I wouldn't use it for a calculator but if it's an important app allocating 150MB of RAM seems worth it. The biggest change here seems to be the build system and the upgrade to Chrome. The Chrome updates are what's important here. Since Chrome is evergreen if your behind a few versions the standard libraries in NPM just stop working. I got bit a while back when when they were a bit behind in releases.

diminoten 8y ago
Who doesn't have 150MB to spare? This laptop has 16GB, why are people hemming and hawing over 150MB???
- hyder_m29 8y ago
  A lot of electron apps (like Slack) could well use over 1GB.
  - diminoten 8y ago
    So I guess I can only run ~16 instances of Slack. Damn...
    - arama471 8y ago
      But that implies you _only_ run Slack.
    - leppr 8y ago
      That means a $1k+ computer with Linux can only run 16 Slack instances. If you're on Windows and aren't as wealthy, the count goes down to 5. Soon you have to micromanage your computer resources instead of purely focusing on work.

legostormtroopr 8y ago

I can't wait to hear about all the new features at ElectronConf... oh... nevermind.

bluetidepro 8y ago
I don't get the joke? Is/WAS "ElectronConf" a real thing?
- dx87 8y ago
  It was going to be, but they didn't have enough minorities and woman giving talks, so they cancelled it. Looks like they deleted the announcment, but here is an old reddit post where people are talking about it. https://www.reddit.com/r/javascript/comments/6f8u2s/githubs_electronconf_postponed_because_all_the/ https://www.reddit.com/r/javascript/comments/6f8u2s/githubs_...
  - sifoobar 8y ago
    Surreal. I guess the good news is that this level of dysfunction should take care of the other Electron issues all by itself if we just wait a little while.
  - choochootrain6 8y ago
    GitHub is just scared they're going to have PR problems because of the 2014-2016 lawsuit. Hopefully Microsoft can fix GitHub's broken mentality towards gender inclusiveness.
- g45y45 8y ago
  yeah, but it was postponed because the speakers were all men. Some reddit commentary: https://www.reddit.com/r/javascript/comments/6f8u2s/githubs_electronconf_postponed_because_all_the/ https://www.reddit.com/r/javascript/comments/6f8u2s/githubs_... the official site just has a logo: http://electronconf.com/ http://electronconf.com/
- deleted 8y ago
  [deleted]

jeklj 8y ago

Looking forward to the many positive comments here regarding this widely-used piece of open-source software.

sidcool 8y ago

I have heard a lot of complaints about Electron on various aspects, but one thing it has done well is to open the niche of cross platform Desktop apps to an average regular developer like me. It can be also used to quickly test an idea before dedicating platform specific resources. I hope the team adds more features keeps Electron alive.

criddell 8y ago
Microsoft adopting Chromium is a big hint that they are going to make some big investments in Electron. I think Electron's future is bright. My big complaint isn't the resource usage, it's how the applications never feel right on any platform.
- krzyk 8y ago
  Exactly, Electron apps feel always like webpages :(
  - jazoom 8y ago
    I've never once felt VS Code was a webpage.
    - criddell 8y ago
      It feels close to that for me. It definitely feels foreign on every platform.
      - y4mi 8y ago
        IntelliJ has the same problem. so does everything adobe creates and ... honestly, almost everything that caters to a niche doesn't really try to be native, as that would often create an inferior product for that specific usecase. though there are very bad examples as well. all these chat apps like discord, slack and rocketchat for example.
- chr1 8y ago

rewgs 8y ago

One major issue with Electron that I don't see talked about much is backwards compatibility. This release states that because Chrome no longer supports Mac OS 10.9, Electron doesn't either. Resource usage aside, there's far too much control of a given app being given to the Chrome team.

jlokier 8y ago
Ouch. Thanks for mentioning the issue. I'm still happily using 10.9 on my main laptop and in no rush to change, and I was hoping to look into using Electron for a project, so that's going to be awkward.
- sroussey 8y ago
  Does Apple make security updates for 10.9 anymore? Seems like a security risk.
  - godDLL 8y ago
    Having used all of the subsequent iterations of OS X, now I will be reverting to my Time Machine copy of 10.9 because really, the usability of it has gone downhill from that point on. Or even 10.8, I'm not yet sure. Who cares if it's secure but sucks so much that I'm not using it anymore?
tuananh 8y ago
that's a known limitation right from when they started this project.

fabiospampinato 8y ago

There are always many negative comments regarding Electron apps, so as a developer who has made a couple Electron apps let me briefly illustrate to you what the advantages are: - I can use the same UI components that I use for making websites and easily share code between all platforms. Maybe this will change in the future with the advent of WebAssembly, but right now no other stack gives you this. - Bundling a cross-platform auto-updating app is wonderful. I just have to configure electron-webpack [1] and everything is taken care of. In the past I've made a password manager with GTK3 + Python, bundling it was a real nightmare and I don't think the situation improved much in the last few years. - Sometimes, like when you're going to need a HTML renderer anyway, using basically a browser for rendering the UI can actually be an advantage, a couple of examples: Example 1. Evernote needs to render their notes, basically arbitrary HTML, and the macOS app uses Safari's engine for this. Now they have to check across all platforms if their notes are always rendered the same, even for rendering a simple note they show you a spinner, and the native UI is arguably ugly anyway. In comparison my soon-to-be-released Electron note-taking app [2] looks more native to me, it's faster, requires less resources, and I get cross-platform support basically for free. Example 2. I was using Ship [3], an app for managing GitHub issues. The native parts of the UI were written in Objective-C, the issue/comments part were written using web technologies, and their server was written in C#. What you get is an app that doesn't work across platforms and sharing code between all the parts of your application is basically impossible. - Lastly I'm by no means an expert on other cross-platform UI toolkits, but some of them try to mimic the native widgets and do an awful job at that, as a result I don't have any Java GUI app installed because they all looked like crap to me, how many do you have installed on your desktop? [1] https://github.com/electron-userland/electron-webpack https://github.com/electron-userland/electron-webpack [2] https://imgur.com/a/ZQd8Vad https://imgur.com/a/ZQd8Vad [3] https://www.realartists.com/blog/ship-20.html https://www.realartists.com/blog/ship-20.html

LeoPanthera 8y ago
> I can use the same UI components that I use for making websites and easily share code between all platforms. I propose that using web components for desktop/mobile applications is not a good thing.

ronlobo 8y ago

Nice! Has anyone played around with flutter.io? Is it similar to electron?

forgot-my-pw 8y ago
Flutter for desktop is still pretty new, but it sounds promising. https://medium.com/flutter-community/flutter-on-desktop-a-real-competitor-to-electron-4f049ea6b061 https://medium.com/flutter-community/flutter-on-desktop-a-re...
- choochootrain6 8y ago
  If Fuschia becomes the next big OS do you think Flutter could replace web technologies?

faitswulff 8y ago

Discord seems to buck the trend of both Electron and React Native being bloated and slow. How do they do it?

Klonoar 8y ago
The thing about Electron (that is often drowned out in these threads) is that it's a web browser, which means... like any website, there's a litany of weird performance tricks you need to know and be aware of to make a good performant UI that doesn't have performance degrade over time. Like many websites in tabs in a browser, sometimes... it's easier to just kill the tab or window, and re-open it. Usually a sign you've done something wrong in your UI handling code.

rafaelvasco 8y ago

I stay away from Electron and JS desktop apps in general because: - Huge distribution size. Your code is 1% at most. 99% is redundant. I want 10 meg at worst hello world dist size. - This is more a problem in JS ecosystem in general: No good enough standardized or not way to do the frontend part of the app. Angular is not good enough, neither is React or anything else. Though it is gradually getting better.

patagonia 8y ago

So someone should clearly fork it to Firefox. Not me. Not if you want it done right. There has been a lot of talk on HN about Chrome having to big a slice of the pie. Whelp.

PascalW 8y ago

A lot of people express concerns about Electrons resource usage. I wonder if people are aware of projects like zserge/webview [1]? It provides a cross platform API on top of the built in platform browsers and thus is very lightweight. Of course, it means you have to deal with cross-browser issues, but I guess webdevelopers are used to this anyway. I'm also aware that these projects don't provide all the APIs that Electron provides, but many apps that are really just a wrapper around a webapp this is totally fine IMO. [1] https://github.com/zserge/webview https://github.com/zserge/webview

skymt 8y ago
That doesn't seem like it would solve anything, unless I'm missing something substantial. Which specific browser engine it uses isn't as important for resource consumption as the fact that it's spinning up an entire browser engine per process.
- PascalW 8y ago
  At least the binaries are substantially smaller because they don't actually include the browser. I can also imagine there's some potential for sharing the same engine across multiple apps, though I'm not sure if they actually do this.

tommoor 8y ago

I've worked with Electron and previously NW.js for over 6 years. Here's what you need to know – if an apps performance is bad 99.9% of the time it's the developers code, not Electron that's the issue. Sure, the bundle size is large and the memory footprint is ~200Mb but those should not be limiting factors if you have a computer from this decade.

casper345 8y ago

I use Electron as a quick MVP for basic apps. If the apps become more complex, then we will talk about moving to a native platform if we need to focus on native libraries or performance. Pick the tool for the job at hand.

dolguldur 8y ago

One of the less obvious reasons why Electron has become so widely used is that Apple hasn’t invested anything meaningful into improving AppKit in the last 5-10 years. If Cocoa was a joy to use I’m sure there would be more native apps.

dtougas 8y ago

I have high hopes for Electron. In some regards, it feels like the new Java. I remember in the early days, using Eclipse and thinking how bad the performance was, but appreciated all the functionality it brought, despite being written in Java. Now days, I am in love with the JetBrains IDEs, and don't think twice about the fact they are Java. The performance is great, and they look good (IMHO). I suspect that in the future we will feel the same way about Electron apps.

mezzode 8y ago

I still think that the majority of Electron apps can and should just be PWAs. Most like Discord pretty much just wrap their webapp anyway.

solarkraft 8y ago

> Electron v4.0.0 includes Chromium 69.0.3497.106 Isn't this already outdated by months?

johnwyles 8y ago

Isn't it funny the Palm Pre was in some sense what Electron apps have become? Just an anecdote - I understand all the differences between them but I didn't even think at the time the Pre came out that it was "ahead of it's time" but I suppose it was - then again there was also the iPhone that killed it as well.