41 ms·

Electron is flash for the desktop (2016)

• carapace 10y ago
  "It would take 450 floppy disks to store these three simple apps."
• andreicon 10y ago
  Flash used to work on the desktop as well, they had this little "projector applications" iirc
  • nsebban 10y ago
    You could "compile" your animation as an executable file, as well as an SWF file.
    • zwetan 10y ago
      you still can, it is called a "projector", you basically merge the Flash Standalone player exe with a SWF into one executable.
  • rhapsodic 10y ago
    They still do, but if you want a Flash-based desktop app, your best bet is Adobe AIR, which gives it access to native APIs.
• k__ 10y ago
  Isn't it more like Adobe Air with JS instead of AS?
  • trebor 10y ago
    Actually, Adobe Air has supported JS for a long time. Certain APIs were only exposed to AS, but I'm sure that's changed over time.
  • tantalor 10y ago
    The analogy is extremely weak. At best, "flash" is a stand-in for "bad performance".
    • throwaway2048 10y ago
      The funny part is flash and air have way better preformance than html 5 and electron.
• toni 10y ago
  On macOS, the alternative would be to use Fluid[1]. You can build mini-apps from a lot of websites and the footprint is very little. (No affiliation, just a happy user) [1] http://fluidapp.com/ http://fluidapp.com/
  • josephg 10y ago
    Unless I'm missing something, isn't that just wrapping the webpage in an embedded WebView? If so its basically doing the same thing as electron, except using Safari instead of Chrome and not giving the app any native API access. This helps in 2 ways: - Safari is less of a resource hog than chrome - It avoids the huge 380 meg download of electron But it doesn't solve the runtime problems. The app is still running inside a VM (safari), so its still going to be way slower than its native equivalent and it'll use way more memory. Also in a real browser background tabs get throttled in dozens of ways. But I bet none of that throttling happens via Fluid, because even background windows can be visible at any time on macos. I'd be curious to see a quick comparison of CPU and RAM usage of slack-for-desktop and slack-in-fluid if anyone is willing to give it a whirl. I'd do it myself except I deleted slack after writing that blog post.
    • rvanmil 10y ago
      Slack with Fluid: 1 process, 208 MB. Slack Electron: 4 processes, 56 MB + 355 MB + 64 MB + 29 MB = 504 MB This is after signing in to one team, (janky) scrolling through a couple of channels and running for a few minutes.
• jlebrech 10y ago
  it's a stop gap will WASM is used for both desktop and web.
• eru_melkor 10y ago
  Holy shit! Are we behind reddit on this? https://www.reddit.com/r/programming/comments/64oqaq/electron_is_flash_for_the_desktop/ https://www.reddit.com/r/programming/comments/64oqaq/electro...
• tyingq 10y ago
  >But that's not abnormal for slack. In fact, slack often idles at 5% CPU usage. Whats it doing? I have no idea. Probably something like this: https://github.com/Microsoft/vscode/issues/22900 https://github.com/Microsoft/vscode/issues/22900 (not the cursor thing specifically, but something that feels lightweight, but isn't) Which is probably fixable. I would guess Vscode is more code than Slack, and they were able to fix this, albeit with very good help from a customer.
• rhapsodic 10y ago
  I wonder how a JS/HTML desktop using the Adobe AIR runtime would compare.
  • floatboth 10y ago
    heh, speaking of Adobe Air, I remember Air based twitter clients running smoothly on my Eee PC 900 (single core Celeron 900 MHz!!)
• sktrdie 10y ago
  If you like Node.js and HTML/CSS, just have a node daemon running in the background with an HTTP server to your app! It's just like Electron, but without the CPU/RAM/Battery usage. You can even have binaries that stay open after a double-click and automatically open your browser to localhost:40023 (or whatever).
  • madshiva 10y ago
    That's horrible and are not native at all.
    • Spivak 10y ago
      So it's basically no worse than Electron. Seriously, if browsers supported an app:// URL which just ran a local site with special privileges and allowed for some custom branding Electron would be dead overnight.
      • fifafu 10y ago
        if they'd be giving you access to the complete node.js ecosystem maybe. With electron you can easily integrate native c++ libaries for high performance stuff or things that require hardware access. It's not like electron is just a webbrowser.
        • sktrdie 10y ago
          You can do all the C++ fast stuff you want on the server.
• paraboul 10y ago
  FWIW, we're working on https://github.com/nidium/Nidium https://github.com/nidium/Nidium presicely to fix this. A new kind of browser engine, not based on any existing engine, allowing developers to use a subset of the web (webgl, 2d, layout) without being forced to use a bloated ecosystem (and which also works on mobile and low end device). Previous HN discussion : https://news.ycombinator.com/item?id=6314961 https://news.ycombinator.com/item?id=6314961
  • deleted 10y ago
    [deleted]
  • SOLAR_FIELDS 10y ago
    > To build nidium you need at least 5.7GB of disk space. A build from scratch may take 30 to 90 minutes, depending of the speed of your computer. Is this abnormally large for a project like this?
    • pavlov 10y ago
      Building Chromium/CEF requires several times more disk space and takes several hours on my new MacBook Pro. So I guess the answer is "not abnormally large".
    • paraboul 10y ago
      Well, it has a lot of dependencies to build : - mozilla spidermonkey - Google Skia - ffmpeg - portaudio - leveldb - OpenSSL And various other stuff.
    • cookiecaper 10y ago
      Just for comparison: I can build WINE from scratch in 6 minutes on my laptop (10 years ago, it took 20 minutes).
  • Etheryte 10y ago
    Both your webpage and your docs are riddled with typos and the like. While it isn't indicative of code or project quality, it sure makes taking the project seriously a lot harder.
• lazarus101 10y ago
  In most cases it's either an Electron app or no desktop app at all. It's simply not feasible to write native apps.
  • krzyk 10y ago
    Then don't, it's really wasteful to have webdevs write desktop apps using Electron. I don't see a gain over using a webpage. I use slack this way and I don't see any problems.
    • jgforbes 10y ago
      You might not necessarily want something like code-editors rely on external servers, while still taking advantage of the UX of web-development. VSCode gets around this by running an npm node locally.
    • lazarus101 10y ago
      No one would bother writing Electron app if there was no demand. Most users, (even tech savvy users) prefer using Electron Slack instead of keeping the webapp open in a browser.
  • alkonaut 10y ago
    Why not? People do native mobile apps despite those platforms being more or less at parity, while desktops are overwhelmingly just one platform. The tools to write cross platform mobile apps that aren't just a browser with lipstick (like xamarin) exist for both desktop and desktop.
  • cgh 10y ago
    Qt exists and is really nice to work with. It has multiple language bindings. How is it unfeasible?
    • lazarus101 10y ago
      Development time needed to create desktop apps (for Windows, Mac and Linux) given that there's already an existing webapp: - using Electron: 1 month - using QT: 2 years
• migueloller 10y ago
  > If you want to use JS and react to make a native app, try react native instead. Given the discussion of the recent ReactXP thread, I'm guessing most people don't realize you can do this today. React Native supports macOS [1] and UWP [2]. Edit: There's even some early work on Ubuntu support [3]. [1] https://github.com/ptmt/react-native-macos https://github.com/ptmt/react-native-macos [2] https://github.com/Microsoft/react-native-windows https://github.com/Microsoft/react-native-windows [3] https://github.com/CanonicalLtd/react-native/blob/ubuntu/README-ubuntu.md https://github.com/CanonicalLtd/react-native/blob/ubuntu/REA...
  • mijoharas 10y ago
    I'm probably in that camp too, I thought it was just for android and iOS still (even though I consider myself to keep up to date with these types of things). Do you know if they have anything for linux yet?
    • migueloller 10y ago
      There's some early work for Ubuntu here [1]. You can also currently use React to share code across iOS [2], Android [3], UWP [4], macOS [5], web [6], VR [7] and a bunch of other stuff that is there mostly for fun (like React Hardware [8] and React Sketch.app [9]). There's also experimental work on defining a set of primitives that works across all of these platforms [10]. [1] https://github.com/CanonicalLtd/react-native/blob/ubuntu/README-ubuntu.md https://github.com/CanonicalLtd/react-native/blob/ubuntu/REA... [2] https://github.com/facebook/react-native https://github.com/facebook/react-native [3] https://github.com/facebook/react-native https://github.com/facebook/react-native [4] https://github.com/Microsoft/react-native-windows https://github.com/Microsoft/react-native-windows [5] https://github.com/ptmt/react-native-macos https://github.com/ptmt/react-native-macos [6] https://github.com/necolas/react-native-web https://github.com/necolas/react-native-web [7] https://github.com/facebook/react-vr https://github.com/facebook/react-vr [8] https://github.com/iamdustan/react-hardware https://github.com/iamdustan/react-hardware [9] https://www.npmjs.com/package/react-sketchapp https://www.npmjs.com/package/react-sketchapp [10] https://github.com/lelandrichardson/react-primitives https://github.com/lelandrichardson/react-primitives
• jonursenbach 10y ago
  I don't understand the React Native comparison. AFAIK, you can't build desktop applications with that, nor can you build mobile applications with Electron like you can with React Native.
  • t1amat 10y ago
    There is native support for Windows (from Microsoft), macOS, Ubuntu (from Canonical) in addition to the first party support for iOS and Android.
    • mijoharas 10y ago
      Thanks, I was looking for a linux version.
    • jonursenbach 10y ago
      Ah, neat.
• Ambroos 10y ago
  A lot of Slack's high (background) CPU usage is caused by GIFs, in my experience. Just did a quick check on my quadcore MBP, having Slack fullscreen out-of-view with nothing animated in view gives it a CPU usage of 0,1% with spikes up to 2,5%. Switch to a conversation with a single animated party parrot emoji, go to another fullscreen app once again, and CPU usage never drops below a whopping 22%. For an animated parrot cartoon. I'm not sure if this is a bug in Slack or Electron. Doing the same in Chrome does not cause any issues, as GIFs seem to be suspended when the window is not in view. CPU usage goes down to almost 0 when you switch away from your GIF-filled Chrome window. For Slack, however, it barely changes. A big shame. (On that note, I wonder how much power is wasted by party parrots via CPU usage. Where I work at least one is almost permanently visible in any conversation as a reaction emoji, so it's probably not insignificant.)
  • and0 10y ago
    I want to say that VS Code had the same issue because of the blinking cursor, which was controlled by a CSS property to toggle.
    • josephg 10y ago
      I'm consistently blown away that stuff like this gets past testing. Personally I think every software engineer should have a CPU meter of some for running on their machine while developing. Its an essential element of seeing what you're doing. How can you write decent software without having even that much visibility over what your computer is up to while your code runs? These huge CPU sinks making it through to release required nobody to even glance at a CPU graph.
      • artursapek 10y ago
        I can't live without one. I used to use "MenuMeters" on Mac, and now use "System Load Indicator" on Ubuntu: http://i.imgur.com/XHlNius.png http://i.imgur.com/XHlNius.png. I also visualize the system load in my tmux bar: http://i.imgur.com/y5KENxA.png http://i.imgur.com/y5KENxA.png I find them both extremely useful in finding when I'm running wasteful software (either written by myself or someone else). https://github.com/artursapek/dotfiles/blob/master/battery.rb https://github.com/artursapek/dotfiles/blob/master/battery.r... https://github.com/artursapek/dotfiles/blob/master/.tmux.conf#L64 https://github.com/artursapek/dotfiles/blob/master/.tmux.con...
• geodel 10y ago
  Very timely article. But I have been told to shut up and use Atom/VSCode/Slack like everyone else and upgrade hardware if software runs slow. I find memory/cpu efficient applications not just useful but respectful to users specially when upgrading hardware is not possible due to financial or policy reasons.
  • ChrisLTD 10y ago
    We're also in an era when the speed of laptop and desktop CPUs has essentially stalled. Put another way, if our apps hog more resources there aren't necessarily faster machines we can buy.
    • alexforencich 10y ago
      Yes, this is extremely important to remember. The days of "who cares if we use a few extra bytes of RAM or a few extra CPU cycles here and there as computers will be twice as fast and have twice as much memory this time next year" are long over. And with the huge push for mobile and slim, portable computers, power efficiency is paramount as users really care about battery life. Yes, sure you can get a more powerful laptop than your nice, sleek, portable macbook air, but it's going to weigh 5x as much and the battery life will suck, especially if you actually use that power. People want to be able to use their CPU and RAM to run multiple applications efficiently, not waste it on a few laggy memory and CPU hogs.
  • taude 10y ago
    I'm running VSCode and Slack on an 11" MB AIR with 8GB Ram (Early 2014). I'm not really seeing performance problems, even with about 40 tabs open on my Google Chrome. While I do occasionally see Slack occasionally popping up on my Activity Monitor, as a user I don't feel I've actually been negatively impacted by this. What kind of hardware are you on as a developer?
• 01walid 10y ago
  That is why I do not use Slack for Desktop, and just keep a pinned tab of Slack open almost all the time. I also tend to reduce my usage of any Electron-based app because I want to better make use of my laptop resources in my development workflow requirements. I feel like I agree with most what's said there, the same would apply to NW.js and the likes. This should be a heads up for GUI developers to [re]consider Qt and QML. It made real progress in the last few months. and there are some nice bindings to it.
• fknop 10y ago
  Meanwhile, we're still waiting for those "pro-native" people to give us better user experience. I agree that Electron has its issue like having multiple copies of Chromium (and not Google Chrome). Obviously native apps are better overall, but only if they provide a better UX. Being a vscode user, I don't know which native editor provides the same UX.
  • Longhanks 10y ago
    There are native editors reaching from very bare bones (vim) to medium like VS Code (Sublime) to full IDE (Visual Studio). All of those run native interfaces.
    • lobster_johnson 10y ago
      Sublime is a hybrid. It has its own renderer that doesn't use Cocoa on macOS, for example, and I believe its input fields aren't native, either. "Native" should mean that it uses native UI widgets offered by the platform itself, which hardly any editor does.
  • nonsince 10y ago
    Emacs provides a better UX, Visual Studio (proper) provides a better UX, Sublime provides something close, although not as good. Slack's UX is incredibly basic. It's a couple of steps above a basic CRUD app. There are billions of IRC and XMPP clients ranging from toy to professional-quality, I use IRSSI, which is admittedly basic, but I find it hard to believe that there is no better native chat UX in existence than Slack's.
    • foldr 10y ago
      >Emacs provides a better UX VSCode is clearly aimed at people who disagree with this statement. It's hardly a matter of objective fact.
• boskonyc 10y ago
  Why would a tech company not build its flagship product natively on the platforms where it runs? It seems like a generation drift: an obliviousness to the world outside of JS/web dev, and a general disregard for application performance.
  • 52-6F-62 10y ago
    Put simply: time to market. Experienced front-end devs with a designer on hand could put together the UI inside of a day, with a workable user experience. Hell, if you're not afraid of bloating in the codebase, you could use a large number of libraries to put together a basic, working version inside of a day or two. Stretch that to a couple of weeks (at most) and you have a prototype you can release. The proof is in Atlassian and Microsoft chasing after Slack on this. Very few people came forward to wave the "Let's just go back to IRC" flag. It's shiny, new, you can drag and drop gifs and files into it, and it runs pretty swiftly (ignoring all of the obvious flaws). Most, especially less technical, users would find it a charm to work with. In my experience, they do -- and above all of the competitors. The rest of your points are rather valid. But maybe its not so much obliviousness, as eagerness and impatience, and the reality of the market being as timely and pressing as it currently is. It's a race -- just like the telephone and the radio (for my point I'm ignoring the scale of impact here).
    • alkonaut 10y ago
      > Experienced front-end devs That's the problem right there(?). People bringing a DOM to the desktop because the developers were fluent in JS. > time to market If there were no drawbacks in terms of complexity/performance/size etc then I'd agree, but now when you have a perf issue that is too large it might be a huge issue to fix. You also only get one chance for a first impression - and poor performance is a huge turnoff. Looking blingy and having all the features doesn't save an app with a 200ms lockup. or a 10% CPU at idle.
      • jernfrost 10y ago
        Agree, I think this is a combination of lack of imagination by developers who only know JS, and management who has bought the myth that cross platform development is 3x faster than making native apps. I saw this happen at work. My team were all experts on native mobile development. We could crank out stuff fast, because we knew our tools well. But then some management dude got the idea that we would do it 2-3x faster if we went with JavaScript. Turns out it was more like 2-3 slower than making all the native versions, because we did not have strong experience with these tools and APIs were more limited, poorely documented, buggy, and the tools were subpar.
• forgottenacc57 10y ago
  It's not flash for the desktop, the author just wants to say something mean about electron cause he's angry. The flash analogy doesn't hold in any way. "Well, flash was errr ummm BAD you know.... and this electron thing it's BAD too .... err umm SAME AS FLASH! Grumpy grump just wants to yell and stomp.
• qeternity 10y ago
  How much of all this nonsense is caused by devs using any and every JS library out there? We've seen this problem on the nodejs side before, and it's even more painful on the browser side. Sure, Slack almost certainly doesn't know all 15m LOC in Chrome, but they sure as hell should know every LOC in their JS, whether that's from in-house code or 3rd party libs.
• luxuryballs 10y ago
  Most users will never notice this, and if some problem is solved using Electron well then Electron solved the problem, life goes on. If you don't like an app or how it behaves then just don't use it.
• evmar 10y ago
  I've been working on a hobby app for some years that is a modern refresh of an old idea. As the article exhorts (and just for funsies, it's just a hobby) I'm writing it using native code and to be conservative on resources. Every place I need to render text or make a thing respond to a mouse click I need to manually do all my own text layout and event handling and so on. (The app is in a domain where it needs special rendering -- I can't just reuse a system widget or library like Qt for this.) Meanwhile, people are making apps similar to mine on top of Electron and banging out features way faster than I ever could. If they want some popup to have some bold text, or use the GPU to animate, or properly handle Arabic text layout, they get it all for basically free, they just need to bang out some divs. I am jealous.
  • Mithaldu 10y ago
    Well, the question is: Does your app run always like a daemon or just when you actually need it? It can be fine to prototype in Electron, or to make tools in it. But if you're making a chat program or anything similarly long-lived, it's the worst decision you can make for your user.
    • true_religion 10y ago
      Vs code is in electron and fairly long lived.
    • ceedan 10y ago
      "it's the worst decision you can make for your user" - Is it? Because there are a lot of Slack users who don't care at all about your tradeoffs. Most of them don't even notice. We're just the unfortunate ones who do notice.
      • Mithaldu 10y ago
        Whether they notice or not is orthogonal to whether it's a bad decision for them or not though.
        • 10y ago
• Udo 10y ago
  It's appropriate to call Chrome an OS-like platform, and it's quite convenient to ship apps with, but it's not "Flash for the desktop". As someone who is opposed to bloat but sometimes appreciates convenience, I think Electron is getting a bad rap here for something that was screwed up by the JS app developers. Go to Electron's website and download the demo (called API Demos). It's 3 processes and consumes 0.0 CPU on idle. Is it super efficient space-wise for what it does? Certainly not. And RAM usage is a valid concern. But churning CPU cycles on idle is not Electron's / Chrome's fault. I also suspect that if an app is behaving grossly on Electron, it's probably a bad actor within a generic browser environment, too. My recommendation would be to not ship simple web apps wrapped in this huge machine without a good reason. But there are good reasons to use Electron or NW. It's just a poor choice when all you need is a thin wrapper around your website.
  • josephg 10y ago
    Blog author here. Thats a fair criticism. I wanted to pick on Spotify and Atom more in my blog post, but both Spotify and Atom have cleaned up their act. I couldn't get either one to reproducibly use lots of CPU. Props to everyone involved in fixing that. But I'd also argue that Flash could always be written to be efficient too. The problem with flash was never the little games people made. The problem was that one tab with a stupid punch-the-monkey banner add playing somewhere that would sit on 20% cpu even when the tab was in the background. I think Electron is similar, except in the desktop space. Well written apps seem to be able to keep CPU load down (although they still have a huge download and a huge RAM footprint). But there's been a running trend of noticing some dumb software running somewhere on my machine eating all my CPU. And in the last year or two its been an electron app, every time. Just like flash before it.
    • apo 10y ago
      > ... I couldn't get either one [Spotify or Atom] to reproducibly use lots of CPU. Props to everyone involved in fixing that. It seems deceiving to conceal that information when your call to action is to ditch Electron for the sake of performance.
• bartkappenburg 10y ago
  I even got more used Slack memory than the article's writer: https://imgur.com/a/AQGYD https://imgur.com/a/AQGYD
• feelandcoffee 10y ago
  I get the idea of Electron Apps having some hate for the performance. I mean if I have to open a large SQL file (> 250MB) and compare the performance between Atom and Sublime... well the difference will be day and night. But there are a few differences between Flash and Electron that are not small. I mean the first thing is, Electron is open source in a open Standard, and have a fast development cycles to fix performance and security issues. I think it's like a PHP situation. Electron is easy to use and sells itself as a cheap way to build apps, so this attracts lazy developers so we have a lot of problems, but that doesn't mean the technology is bad. But this is not a Electron problem, I mean web pages right now are heavy and slow for nor real reason. We need better fron-end developers. I love VS Code, Hyper, and others, so maybe I'm biased, but I think Electron will be a interesting option to make desktop Apps something again.
  • GrinningFool 10y ago
    > but I think Electron will be a interesting option to make desktop Apps something again For most of the computing world, desktop apps have never stopped being a thing.
    • feelandcoffee 10y ago
      Sorry I was vague, and yeah you're right they have never stooped. I was thinking more in the Hype thing for new developers. You know like a small Renaissance in the Desktop UI/UX deparment, you know would be cool see beautiful desktop Apps in sites like Behance, Dribbble, etc spotting the first places, instead of the classic App with default OS UI or weird adapted ports of Mobile apps.
• Andrex 10y ago
  > I just ... don't care about your app enough to justify running more chrome instances Is the author going to uninstall Slack, Atom, Chrome, and Spotify, then? Electron has won out because key apps have opted to use it and decided that the trade-offs of user CPU and battery are worth some amount less than their productivity as developers. Yes, there are alternatives to developing native desktop apps in JavaScript (I'm not sure I've seen React Native used this way, but it probably exists somewhere out there.) People opt for Electron because it's holistic, battle-tested and easy to use. I'm not excusing Electron's (many) flaws. There should be a concerted effort by the team to "disable" parts of Chrome that don't make sense for native apps, or at the very least let it be configurable. He's right, there's no reason Slack should have access to the GamePad API (or WebVR, etc.) My overall point is that like everything, productivity of the end-user is always going to have some kind of trade-off with the productivity of the developer (or more specifically, the business considerations of the company.) Always. We don't write assembly anymore even though the apps would be a gajillion times faster than writing Electron-wrapped web apps. Now, complaining that Electron/Slack/etc. are CPU/battery-hungry is completely valid and a good discussion to have, but you only get me to jump into the HN comments once you start delivering global developer edicts with no regard for the other considerations those projects have made. > The other sad fact is that even most developers have no idea that this is even happening on their computers. They run slack but have no idea how hungry it is. As a developer its your responsibility to know this stuff. I'm not sure I completely agree here, "responsibility" is a bit heavy of a word. > Users: Please complain more about slow programs. Its 2016. We carry supercomputers in our pockets. Its simply not ok for apps to be sluggish. Wait, this is the first instance (edit- second, but mentioned in passing in the previous paragraph) the author mentions "sluggishness" as a metric. IMO sticking with measurable stats like CPU and battery life are better because you have no idea if someone other than yourself experiences or even perceives this sluggishness. What about non-developers at BigCo that only run Chrome, Slack, Spotify, and Word? Would they feel sluggishness? I would guess not, since I rarely experience it as a developer on a Macbook using Chrome, Slack and Atom. (Things only get dicey when I start doing Vagrant stuff.) > Also all you web devs: Go learn C or Rust or something. Your program runs on a computer. Until you know how that computer works, you're doomed. Doomed to have a successful career? I prefer being "doomed" then. (For the record, I do know > And until then get off my lawn shakes fist. Aaaaand there we go. Maybe next time don't bury the lede? :P > Oh, and read this talk on the website obesity crisis. Its very funny. And very sad. And very true. This is an entirely separate concern (and one I agree with.) Heavy web pages are heavy because they are multi-megabytes to download, not because their "installed" wrapper (Chrome) is hundreds of megabytes.
• zelos 10y ago
  I just noticed this morning that VSCode has started causing my MBP's fans to spin up whenever I type in it. I spent about an hour updating my MacVim setup to replace it.
• ap46 10y ago
  You'd think they'd afford a Mac & windows developer.....
• loppers92 10y ago
  Long time javascript programmers are the loser (if they never learned more than javascript) they don't know how to programming an almost perfect program. That is the reason why they using javascript on Desktop. The average programmer learns just one fucking language but being a good programmer you need at least to learn 2+ languages. That you can see the performance issues in your stack. I started with PHP and javascript while this time I didn't care about performance and now I'm a c/golang programmer. When I started to study c and golang I just released how bad the whole javascript stuff is actually.
  • blueprint 10y ago
    Or maybe it has something to do with time-to-market for existing web apps, or other loserish things. No, can't be. You must be right. Especially because you know more than one language. After all, when you learn more languages, it makes your words more true!
    • loppers92 10y ago
      Can you tell me why Microsoft and google trying to write either supersets or a javascript clone to replace javascript? Because that language is an issue itself. I don't know one good programmer who is saying that you need javascript to make real money or that language is awesome. This language is a bug nothing else.
      • blueprint 10y ago
        Just because that tangential point can be made to appear valid in a different context, it does not mean that it is the proof to support your original argument. Sounds like you're primarily just upset about Javascript and/or front-end web technologies.
    • ionised 10y ago
      I'm definitely more inclined to listen to a developer with knowledge of multiple languages than one who insists on stuffing Javascript everywhere.
  • 10y ago
• tempodox 10y ago
  > Also all you web devs: Go learn C or Rust or something. Your program runs on a computer. Until you know how that computer works, you're doomed. I can only encourage everyone to heed this advice.
  • arca_vorago 10y ago
    Maybe time to ressurect my abandoned wxwidgets inspired assembly project?
  • Afforess 10y ago
    Won't happen. All the signs point to more and more developers understanding less and less of what is going on underneath the covers. If anything, we are < 50 years away from only AI and machine learning algorithms understanding chip design and microcode. Soon enough, no human is going to be able to parse the tech stack below the operating system.
• Gonzih 10y ago
  Telegram Desktop is very good example of modern desktop client done in the most efficient way. C++ and qt, nothing else. Works like a charm an all major operating systems. Easy to install, use and update. Great stuff.
  • blueprint 10y ago
    How do they manage to get the very native feel to the UI on Telegram for MacOS? Or is that a different native client? Also curious… in what language and UI framework is their iOS client written?
    • jhasse 10y ago
      That's a different one.
    • mi100hael 10y ago
      QT uses native macOS APIs & components in many cases. https://doc.qt.io/qt-5/osx-issues.html https://doc.qt.io/qt-5/osx-issues.html
  • zegerjan 10y ago
    Except they've rewritten their Mac app in Swift now. So there must be a reason they moved away from that.
    • Kipters 10y ago
      They didn't rewrite the app. There are multiple official apps, you could also write your own (that's what is happening for Unigram, an open source UWP client for Telegram)
    • narrowtux 10y ago
      Probably because Qt apps don't feel like native macOS apps.
    • Gonzih 10y ago
      telegram-desktop and telegram for mac are different projects
• brilliantcode 10y ago
  I don't get this article. What does the author propose instead? Cross-platform is tough to get right and it places much burden on developers focusing on application logic for his niche. I don't think it's fair to label Electron as Flash just because it's doing things in the background that Chromium authorizes. We know that Chrome Browser and it's underlying technology is in use everywhere and anyone can open it up and take a peek or embed Chromium in their C++ projects. On top of that Electron takes care of cross-platform issues, and it's performance is under constant iteration by Google, so you have a much better chance of getting to market without having to do the plumbing work. While I share the concern that Electron seems to spin up fan on my Macbook, it's quite rare that I don't think much about it. If anything, Electron improves desktop user experience by leveraging web technology. I shudder to think what Slack will look like if it was done with Java Swing. But in some HN'ers mind, that is the "right" way of building this world. I see a big split in thinking amongst the demographic well marinated by Java Is Everywhere (TM) vs Javascript is Everywhere.
• fareesh 10y ago
  From what I understand, a barebones JS-on-desktop framework at minimum needs blink, V8 (or equivalents) and some custom bridges to provide native APIs to JS, right? Which one of these is the resource hog?
• franciscop 10y ago
  While I love Node.js and its environment, I totally agree with this post. I don't have the Slack client installed for this reason and only use Electron when I write code. React Native seems like a nice middle ground: Javascript, but compiled to native. PS, I notice that the author is using Ghost for the blog, so I am guessing the author is in the same line (like Node.js but not Electron).
  • johnonolan 10y ago
    Not sure what line that is but Ghost's desktop app is definitely Electron. For the record, it was also built handedly by one open source contributor (Felix Rieseberg) and absolutely would not exist if not for Electron.
    • franciscop 10y ago
      Cleared up (I hope)
  • oakesm9 10y ago
    Just to note, React Native doesn't compile Javascript to native code. It uses Javascript running in a Javascript engine (JavascriptCore usually) to control native views through a bridge. You're still running Javascript on user's machines, but the UI is native.
• anaisbetts 10y ago
  Here's the thing. You know what the alternative to all of these Electron apps coming out is? If your answer is "A native Cocoa/WPF app", you are on another planet, the answer is, "It wouldn't exist at all". Nobody in the last 5-10 years cared about writing Desktop apps before Electron came along, there's basically zero money in it, and it's massively expensive, both in terms of actual dev time per feature (easily 10x the cost), and also in finding specialist developers who know these dated technologies. And as for Qt, Qt has existed for over two decades - if its massive "Beatles walking off the plane" moment hasn't happened by then, sorry, it's not gonna. But now? People are making all kinds of great new apps, and more often than not, they come out on all three platforms. People are excited about the Desktop again - Electron is so good it's single-handedly revitalizing the platform that two of the largest tech companies in the world are behind, yet couldn't do. That is a Big Deal.
  • hn_throwaway_99 10y ago
    The other thing I find ionic about this whole article is that it's perfectly easy to only use Slack within Chrome as a normal web app. And the UI is almost exactly the same because it's nearly all the same code. So if the Electron bloat is such as issue for you, just hit Slack in the web directly.
    • joshstrange 10y ago
      s/ionic/ironic But I find it to be a humorous typo given the topic of this discussion as ionic is a browser-based cross-platform mobile framework.
      • cozzyd 10y ago
        Indeed, we should start calling electron-less applications ionic.
    • apexalpha 10y ago
      I do this. Go to Slack and click 'add to desktop' and Open as Window and you're good to go. Same for Whatsapp Web etc...
• api 10y ago
  Electron is a sub-optimal solution to the fact that desktop development today is horrible. You either have to write your app twice (or three times if you want Linux) or use Qt, which limits you to either C++ or this weird langauge/ecosystem nobody knows called Qt Quick. Electron lets you write desktop apps that work decently well everywhere in a language you already know.
  • irishcoffee 10y ago
    > use Qt, which limits you to either C++ or this weird langauge/ecosystem nobody knows called Qt Quick Hmm, PyQt would remove the need to use c++ if that is an issue.
    • mi100hael 10y ago
      Then you have to bundle and distribute Python, which is also a huge pain.
      • lima 10y ago
        Distributing a PyQT app with PyInstaller is absolutely painless. It's a single binary and "just works", the interpreter is automatically bundled.
    • jhasse 10y ago
      Isn't PyQt GPL though?
      • cpburns2009 10y ago
        PyQt is GPL. PySide is the LGPL alternative. Last I knew PySide was still working on Qt 5 support though.
• mk89 10y ago
  All nice comments from the author. Good ideas, except that most of the time these should come from upper-management: security and performance? They are additional features. We'll bother with them later. Lots of developers have great ideas when they are given space, meaning when it's in the "sprint". Some developers simply don't know about the existence of benchmark tools, etc., but, by experience, many of them know how to google. What matters is 1) time-to-market, 2) it's swooshy enough, 3) it does what it's supposed to do. I may also completely wrong: it's not always management to be bad here. Sometimes, it's a "bunch" of people who think they are doing the right thing (like choosing a technology instead of another). Management can't always be blamed for it (of course not) - especially when one of the people choosing is trustworthy.
• GrumpyCoder 10y ago
  I know I'm being completely naive but can all electron apps share one runtime (sorta like one browser with multiple tabs)?
  • jhasse 10y ago
    Yes, they would simply link stuff dynamically (.so, .dll, .dylib files). But everyone is using a slightly different version of Electron and macOS and Windows don't have a good enough package manager, so everyone is static linking everything.
  • alexforencich 10y ago
    No, that would just bring back DLL hell.
• kazagistar 10y ago
  So when are we gunna start seeing Web Assembly targeting Electron and go full circle?
• discreditable 10y ago
  Would it make more sense to distribute electron as a dependency and allow apps to use it? That way, instead of 10 apps requiring 10 different electrons we have 10 apps that can use a pre-installed electron.
  • hundchenkatze 10y ago
    Isn't that what Chrome/FF/Safari/Edge/IE/... all do?
  • ascagnel_ 10y ago
    How does an app bundling Electron in that way differ from an app using a native embedded browser widget (other than that it can run in Chrome vs. Edge/Safari/etc.)?
    • discreditable 10y ago
      > using a native embedded browser widget (other than that it can run in Chrome vs. Edge/Safari/etc.)? I didn't know that was possible, do people do that?
      • ascagnel_ 10y ago
        Not too many apps do it, but it is possible. https://developer.apple.com/reference/webkit/wkwebview https://developer.apple.com/reference/webkit/wkwebview https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls.webview https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.con...
  • belovedeagle 10y ago
    No, because history has shown that shared libraries on any and all platforms inevitably become bundled into applications themselves (leaving one wondering WhyTF someone would choose something as unnecessarily complex as Docker over, you know, static linking). Those who do not know history are doomed to reinvent it, poorly. Or something like that.
• lazyjones 10y ago
  I fully agree with the author, only I'd call Electron the PHP for the desktop (it does help people get started quickly, at a cost). There are working solutions for cross-platform native UI development and high-performance, slim code: http://wiki.lazarus.freepascal.org/Multiplatform_Programming_Guide http://wiki.lazarus.freepascal.org/Multiplatform_Programming... The problem is: most people don't bother learning new languages unless it's very easy (well, Pascal is!). I hope Go will have a cross-platform UI soon.
  • dubcanada 10y ago
    What does PHP have to do with this? And Go already has bindings for QT which is a cross-platform UI framework. This has nothing to do with people not wanting to learn new languages, it's just the time it takes to build an app. For you to build a QT hello world app takes probably 20 minutes worth of downloading, setup, and coding. To do the same you download electron, create an index.html with hello world and drag and file into electron, bam a hello world app. The problem is desktop development is overly complex. React and modern Javascript make creating desktop apps using HTML/CSS with some combination of Javascript easy. What we need to do is find a way to create a very slim browser that contains just an HTML/CSS to 2d context and a Javascript engine. Call it Electron slim and release that.
    • lazyjones 10y ago
      > What does PHP have to do with this? It's the RAD choice for beginners since... ca. 1997? > For you to build a QT hello world app takes probably 20 minutes worth of downloading, setup, and coding. To do the same you download electron, create an index.html with hello world and drag and file into electron, bam a hello world app. Perhaps the first time ever, the 2nd attempt you will be equally fast. Does a well-funded startup not have 20 minutes to test a platform? As far as Lazarus is concerned: give it a try, it won't take 20 mins. > What we need to do is find a way to create a very slim browser that contains just an HTML/CSS to 2d context and a Javascript engine. Christ, no. There are no slim browsers anymore and it's a pitiful environment for native applications.
  • erinaceousjones 10y ago
• sixdimensional 10y ago
  Look at WebAssembly, then consider...
• cdnsteve 10y ago
  If I wanted to make a desktop App work on Windows and macOS today, without using Electron, what are my options to build something very quickly that also include the benefits of Electron: self updating, app crash reporting, windows installers, no licensing fees?
  • devopsproject 10y ago
    react
• _pmf_ 10y ago
  Flash was a relatively slim runtime that enabled high performance applications; Electron is the polar opposite.
• Lagged2Death 10y ago
  Sure! You say. Disk size is cheap you say! Here's some irony for you: You really need an SSD in a modern PC - largely because of exactly this sort of insane bloat - and as a consequence, no, disk space isn't so cheap anymore.
• crispytx 10y ago
  I think Electron is really great for developing an MVP. But yeah, Slack should probably build their next version with Visual Studio and Xcode the way Microsoft and Apple intend for people to build apps for those platforms.
• harisamin 10y ago
  A while ago I had been working on a native Mac slack app. I was 70% complete but sidelined it. Should I pick it up again? Would ppl here be interested in paying for something like that? Here are some links to screenshots so you know its not just vaporware :) https://twitter.com/harisamin/status/727634194814373889 https://twitter.com/harisamin/status/727634194814373889 https://pbs.twimg.com/media/ChkTccjVAAAZ0Kt.png https://pbs.twimg.com/media/ChkTccjVAAAZ0Kt.png https://pbs.twimg.com/media/ChkTcbMUkAIYolx.png https://pbs.twimg.com/media/ChkTcbMUkAIYolx.png
  • kitsunesoba 10y ago
    I believe it would get a fair amount of attention if it were open sourced. There's lots of Apple platform devs out there who'd love to have a more native Slack experience and would contribute to such a project in a heartbeat (myself included).
  • NegativeLatency 10y ago
    I'd be interesting in working on that if you open sourced it!
  • sovande 10y ago
    Most users will accept issues with their free program if the alternative is to pay. I'm pretty sure the message pane you have there is a WebKit controller so it is debatable how native this would be.
    • harisamin 10y ago
      There actually isn't any webkit here at all, except for the slack api oauth login. Everything is native. Trust me, I'm not faking this :)
  • pdimitar 10y ago
    I'll easily pay you $30 once for it as long as it is open-source and has active commit log. Most of us tech folks hate abandonware, have that in mind.
• sametmax 10y ago
  People complaining about electron are the same type than the ones that used to say : - why are people writing this stuff in C. It's so slow and you don't have as much control on memory. Write it in Assembly. - why are people writing this stuff in Java. It's so slow and you don't have as much control on memory. Write it in C. - why are people writing this stuff in Python. It's so slow and you don't have as much control on memory. Write it in Java. Eventually people want to solve a problem with the best ratio cost/quality for them, not "doing it the proper way". So unless you provide a better solution for them to do that, or pay big money to create such solution, they will find the ugly-hackish-half-baked-working-for-them solution that let them do this. We had PHP. Now we have JS. I hate it. You hate it. We all hate it. But I created portable GUI apps with an installer before in my favorite language and others and it was a pain. All of it. The UI, the event model, the API, the portability edge cases, the new stuff to learn, the packaging, the dependencies... It sucked. So get over it or provide a solution, but stop complaining. And before you start providing an EXISTING solution, remember people tried it and they didn't like it as much as electron. And since electron is so bad, that should tell you something. So the market is saying you are wrong. You can ignore it from your better tech tower... Try to boycott electron apps all you want. But we know how it has played for betamax, lisp and the ogg format. P.S: oh, and if electron is flash, remember that flash won the web for 15 years while it sucked. And you know why ? Because it allowed people to do stuff they wanted easily, like videos and animations. And it's not because we couldn't do it any other way, we could. Yet we had to wait almost 2 decades to see it dies, at the price of battery, stability, security and everything else. Feature trumps everything. People. Don't. Care. We only manage to kill it because we finally replaced it with systems that could compete on easiness and features. So you know what to do.
  • scribu 10y ago
    > So get over it or provide a solution, but stop complaining. Complaining is a necessary first step in finding a better solution. Before being able to solve a problem, you need to first articulate what the problem is.
    • sametmax 10y ago
• JetJaguar 10y ago
  Typical hackernews a-hole...ignore it.
  • sctb 10y ago
    We detached this comment from https://news.ycombinator.com/item?id=14088559 https://news.ycombinator.com/item?id=14088559 and marked it off-topic. Please comment civilly and substantively or not at all. https://news.ycombinator.com/newswelcome.html https://news.ycombinator.com/newswelcome.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
• richsu-ca 10y ago
  I get < 1% CPU usage when it is idling on a Windows 10 desktop. Will check later on the MacBook Air and see what I get. Memory used is 71 MB Total no. of processes: 5 Measured using Windows Sysinternals - Process Monitor.
• d--b 10y ago
  Electron is just another proof that ease of programming matters. Node.js too was a terrible idea. Who in their right mind would write server-side javascript? It turns out: pretty much anyone who didn't want to have to screw around for hours before being able to respond to a simple http request. Similarly, it is way harder to write a desktop app than a browser app. DOM / CSS manipulation, however bad they are, are years ahead compared to what you can easily do with WPF and friends. And what about Python for data analysis? The one language that is known to be 10x slower than C becomes the de-facto standard for a field where what matters most is code performance. Again: ease of programming. The success of electron only shows that there is a market for a UI library that can be written just like what you do in the browser but for native desktop apps... Please someone, write that !
  • goatlover 10y ago
    > Node.js too was a terrible idea. Who in their right mind would write server-side javascript? It turns out: pretty much anyone who didn't want to have to screw around for hours before being able to respond to a simple http request. Pretty sure you could do that as easily in PHP, Ruby, Python, Perl before Node. > And what about Python for data analysis? The one language that is known to be 10x slower than C becomes the de-facto standard for a field where what matters most is code performance. Again: ease of programming. When code performance matters most, you're probably still using Hadoop, C/C++, Fortran. Python is mostly in competition with R, Matlab, SPSS and Excel. Julia is the new kid on the block, and it was designed to be more performant than Python and R.
    • lerpa 10y ago
      > Pretty sure you could do that as easily in PHP PHP is awful but still the best option for making something simple very fast, as it is supported virtually in every kind of provider, even free ones.
  • stedalus 10y ago
    Your Python example doesn't really support your argument. Python succeeded for data analysis and scientific computing in part because it provided easy access to existing numerical libraries written in C and Fortran. So you got the best of both worlds: ease of use and near-native speed. It would not have succeeded if everything was done in interpreted Python.
• sparkling 10y ago
  tl;dr: Everybody wants native apps, but nobody wants to write them.
• c-smile 10y ago
  Just in case: FreeConferenceCall / StartMeeting ( https://www.startmeeting.com/spring-2016-updates https://www.startmeeting.com/spring-2016-updates ) is using Sciter ( https://sciter.com https://sciter.com ) for their UI. This app provides video communication, screen sharing and chat so is comparable with the Slack, Skype and others. Sciter core is a single dll of 5-8 mb in size (StartMeeting uses it as a static library ). Sciter does not create any processes or even threads (modulo HTTP client that uses thread pool). StartMeeting runs the same UI on all supported desktop platforms: Win/Mac/Lin.
• douche 10y ago
  I'm surprised to see so little mention of Java as a cross-platform native app platform. Maybe I'm just old enough to remember coming up though when Swing and AWT were the next big thing. Nowadays, IntelliJ and it's derivatives are all Java-based, and pretty popular and performant. I love getting a chance to get out of web-dev world and go build some ugly tools with WinForms from time to time. You have to do more work yourself, but there's so much less magic involved.
  • MaanuAir 10y ago
    To continue in the Java vein: weren't Eclipse SWT & RCP supposed to be the ultimate answer to native cross platform UI development in Java? I had no experience with them: did they gain some adoption or recognition at least? Maybe all cross-platforms app solutions are just doomed to stagnate, at least until the next hype one rises, after all.
• ska 10y ago
  Shipping the prototype is hardly a new problem, this is just the latest iteration.
• ryandrake 10y ago
  I have a couple of hobby desktop (macOS) applications in various stages of done-ness, which, if there were a low-effort solution, I'd like to port to Windows. Yet even with the business logic nicely separated out into portable C++, it's a huge pain. In the 10 or so years since I've done Windows, the development environment on that platform became totally foreign. C++/MFC seems to be dead and buried, now we have WPF (which is also going away if I'm reading things right) and C# and XAML and Windows Universal and all these layers of exotic technology I now need to learn and master just to get a simple native looking port of this thing. Screw that, I'll find something else to work on thankyouverymuch. I totally see the pain and the burning need out there for a way to write something that works across the "big three" platforms that have grown more and more distant from each other over the years. But Javascript and a browser? Really, that's the answer? I'd even be willing to toss out my investment in Objective-C native code on macOS if I could keep my C++ business logic. Is Qt really viable? My understanding (again, maybe dated) is that a Qt application looks like a Qt application, not a native application. Is this still true?
• jscholes 10y ago
  People grew up and stopped using Flash, slowly phasing it out. If Electron is as influencial as some comments here seem to think it is, the big players in the desktop market will (hopefully) step up and put together new APIs and tools which fill the gap Electron is currently filling. And they'll do it all natively and without the terrible bloat, poor productivity and bad accessibility that Electron currently brings to the party.
• dangoor 10y ago
  There was some effort in the past to allow browsers to provide desktop app-like experiences for webapps. Progressive Web Apps are doing similar, though the target is very strongly toward mobile. It would be more efficient for disk space, though likely not CPU/RAM, to just make webapps be able to work more like desktop apps.
• wooptoo 10y ago
  Or you could use Chrome Apps, i.e. a desktop shortcut which opens a web page in a separate window.
• dezzeus 10y ago
  Actually, there was a long running discussion about making a runtime mode of Electron, in order to address many issues: https://github.com/electron/electron/issues/673 https://github.com/electron/electron/issues/673 I also recently joined the discussion with a more general idea which I (partially) expressed here: https://github.com/electron/electron/issues/673#issuecomment-292617796 https://github.com/electron/electron/issues/673#issuecomment...
• jksmith 10y ago
  I love how the latest generation of interest in a particular development area like UI goes down the road of reinvention thanks to the latest in thing or programmer prejudice. The wasted bandwidth is insane. Somebody needs to write a variation of Sisyphus that turns the boulder into UI development. Suggest not spreading this web dev lunacy onto desktop. The issue has already been solved with reasonable solutions for 25 years. Desktop development, automatic software updates, all that stuff.
• ppidugu 10y ago
  I'm a big fan and total believer that deletion of few apps like Spotify, Slack and Atom could improve the performance of CPU. Recently I have been getting lags with my WebStorm for even firing up smallers commands like $ git status $ git log I downloaded bunch of cpu profiler tools to observe how much CPU does spotify, slack and atom and also some other fancy react, electron app built apps take. Results are unbeliavale.....FYI: My Ram is 4GB with two 2GB slots. But after a complete cleanup and deletion of above troublesome apps performance is just amazing. I'm having a happy life with my WebStorm. I'm very positive that for my future node.js apps that is running nodemon would be fine too. RIP Electron Family of Apps .
• poorman 10y ago
  I tweeted SlackHQ back in May 2016 about how Slack was using 17GB of RAM. https://twitter.com/NickPoorman/status/737647940026634240 https://twitter.com/NickPoorman/status/737647940026634240
• thinkloop 10y ago
  Why would anyone use electron for an app that requires being constantly online - just use the site?
• cerved 10y ago
  Spotify runs at less than 1% for me but maybe that's because I don't own a crapbook
• kurinj 10y ago
  I always thought Electron was a great idea, but it definitely seems like something that should only be used for prototyping. There's some excellent software that uses it, but using the Chromium browser as a runtime is a dirty half-measure. I hope they're​ trying to pare it down in future releases and make an effort to utilize host-OS resources. The less your code​ is doing, the better!
• isaiahg 10y ago
  Lately I've been playing around with Red language and their view feature. Easiest way I've created an interface before. The Red language is really interesting and cool, but their view construct is the coolest. If you haven't played around with it, it's worth about try at least.
• erinaceousjones 10y ago
  > Maybe we should be buying slower computers so we feel the pain. Facebook has been internally intentionally slowing down their office internet once a week to help build empathy with their users in other 3rd world internet speed countries (coughAustraliacough). Yep. I've just got back from spending over a month on a ship in the middle of the Atlantic, with two very flakey 256kbps satellite connections (capped to like 125kbps each as well). Shared between roughly 50 people. Our policy is to let anything through (it's a research ship, so being able to look up stuff on the internet is a must) but aggressively apply QoS rules and caching to the network. With the sheer amount of applications that assume they have a low-latency high-bandwidth connection which they can open hundreds of TCP connections on, just tweaking the firewall / bandwidth shaper / application control is a full-time job just by itself. First observation, relevant to Slack: Before we locked down the firewall, Slack running on 2 laptops was by far the highest traffic application. Even though the few Slack users just had the client open but minimized - not actually using it. It was persistently using 20kbps, all day every day, until we blocked it outright. What the hell other stuff does it have to do other than download text!? Slack / other devs using Electron oughtta test their apps on extremely slow shared internet. Second comment, relevant to Facebook intentionally slowing down office internet: The Mobile Facebook site (m.facebook.com) was by far the nicest to use on our severely degraded uplinks. No timeouts, pages took under 10 seconds to load, we didn't have to wait several minutes of blank page while another F%$£ing web font that's Arial but with the letter T slightly more aesthetically pleasing to download. No massively parallel loading of resources. Good use of caching. It struck me that a lot of our problems were problems because devs never have to deal with that kind of crappy internet, it's not an edge case that gets tested. It results in people unable to load important stuff like Google, GMail, Outlook web app, and as such their products lose users. No matter how much we tweak our network internally, even restricting the internet use to a single computer doesn't result in usable web apps anymore. This is probably something that we share with third-world internet; a much larger market than our "research ship" niche. Finally: People who put company logos in their email signatures hate other people. Base64-encoded PNG images make one-line email responses increase in size by like a factor of 100.
• woah 10y ago
  I understand why you'd want to wring every last efficiency out of your computer, but I run Slack, Spotify, and many windows of VS Code on my bottom of the line MacBook all day, frequently on battery power, and don't have a problem. What's the big deal?
• joeblau 10y ago
  I've slowly started to remove Electron apps from my workflow. I used to use Atom, but I've switched to an paid for Sublime. The last two apps I have which use electron are Hyper and Slack. Hyper could go, but I really like the interface and Slack probably isn't going anywhere. Real-time update: I just checked Activity Monitor and Hyper is leading average energy impact followed by Xcode. Looks like I might be switching back to iTerm this weekend.
  • wishinghand 10y ago
    What is the draw of Hyper over iTerm2?
    • hoschicz 10y ago
      It runs Javascript! You can tune and theme it with CSS and JS! That's actually the biggest selling point. I couldn't imagine using Hyper: I open terminals very often and waiting for Chrome to load when I need to just run a command would be very exhausting.
    • joeblau 10y ago
      Honestly, and I know this is stupid, it just looks better and can be customized a bit more. Since I really should be more focused on performance, I'm going to switch to either iTerm or Terminal.
    • joeblau 10y ago
      I switched back to iTerm2 last night. Deleted Hyper and Atom. I found a patch with dark mode in iTerm which I'm using now: https://github.com/gnachman/iTerm2/pull/318 https://github.com/gnachman/iTerm2/pull/318
• jernfrost 10y ago
  Good someone pointed it out. The web hype has gone of the rails. We got perfectly good development tools for native development which works fine. There are lots of cross platform GUI tool kits too. They offer a better development experience, more dev tools and better performance and memory utilization. It is only because the world is drowning in JavaScript developers who don't want to learn anything else. They want to reuse their latest hipster framework everywhere. They go on and on how terrible desktop development is, because hey it wasn't equally fast as JavaScript when they had never tried it. Newsflash it is slow and hard to do things you have no experience in. As a counterpoint, I was able to create a mobile app with native tools for both Android and iOS in less time than it took me to create one in JavaScript. Cross platform JavaScript is highly overrated. It really isn't all that cross platform, often buggy and with primitive debugging and development tools.
• dheavy 10y ago
  "The modern web makes me want to throw up", "Electron is flash for the desktop", "Databases have failed the web" — wow... author does not look very happy with the state of the web development today.
• aylmao 10y ago
  So much this.
• skybrian 10y ago
  There is competition, for example between Slack's electron app and their website, or between Sublime, Atom, and VS Code. It seems like the author of this post doesn't trust users to choose memory usage and battery life over other things. I expect that's correct - they are sometimes less important to users than other things. Emacs is tiny now, but at one time it was considered a memory hog and people kept using it.
• tastythrowaway2 10y ago
  I thought director was flash for the desktop?
• Tloewald 10y ago
  Saying that "React and friends" are the good thing you want (without Chrome) is kind of nuts. React is insanely bloated for what it is, and it's also highly dependent on the bloated browser (and especially Chrome). React Native is an intermediary layer between a work in progress VM and JavaScript. So, we can't win there. In a sense what we really want is for the browser to be an OS-level feature so that the browser-based-app is low cost, as is the case with chrome OS and you could argue was Microsoft's vision with IE. This is doable today if you write cross-browser code and wrap your web app in a platform-native web view, but then you lose the conveniences of Electron (cross-platform APIs to solve common problems such as menus) AND you have to deal with browser incompatibilities. All this to save RAM and 5% Of one CPU core. Perhaps in an ideal world we'd have a lightweight VM with nice JavaScript APIs. The immediate problem we run into is that really fundamental UI gadgets, such as styled text fields and canvases, are not implemented similarly on the platforms we care about (Windows, Mac, Gnome, Android say), so we have to reinvent that wheel and before you know it you have another bloated virtual machine, except this one isn't battle tested and it only exists three years in the future.
• deleted 10y ago
  [deleted]
• userSumo 10y ago
  I am a young programmer, student, front end developer/designer, with some knowledge of languages such as java, php. I am developing one electron app, and it is going great. And I don't even know javascript that much. But in my case, usage of browser engine is essential, since it has to do with rendering HTML and so on. I have less than 1000 lines of javascript and almost everything was working after 2 weeks. It is not that big of a project anyway, but from the begging I knew that it should be fairly easy and doable. In fact, I can imagine that I could do so many kinds of apps with electron, and I can easily see how I would approach it. Let's say music player. No problem. I believe that electron can easily play media, and it would all look great. Or some productivity tool, or note taking app. Working with files, editing text files, even viewing documents like .pdf would be easy (would just use some plugin). Or even embedding youtube videos in notes would be easy. And all that with easy control of layout and great rendering of fonts and images, plus animations. With little knowledge of front end stuff, and some general programming principles, you can already see how you could build app on the top of electron, which is a platform everyone here knows without even trying. It makes me feel kind of powerful to be able to do such a nice apps myself.
  • userSumo 10y ago
    but if there was something exciting like red-lang with easy to do custom UI ( if needed ) and with some ecosystem around it, i would definitely look into it http://www.red-lang.org/ http://www.red-lang.org/
• sigil 10y ago
  This is Electron scapegoating. The real issue is twofold: 1. Electron makes it trivial for developers who don't regularly reason about native performance to release desktop apps. The result: a flood of apps that "don't do much" but use more resources than you'd expect. 2. At the other end, Electron makes complex apps easier to build. The Slack app might be low-to-medium complexity, but the Spotify app has a ton of functionality, and I bet dev effort was orders of magnitude lower than for a native app like iTunes. The result: in this day and age, complex cross platform apps with higher resource requirements are more likely to be built with Electron. In short, there's some selection bias going on in both cases, and it isn't directly related to Electron. Electron is just the enabler. I agree with the author on point 1: performance matters, memory usage matters, and we as web developers should broaden our horizons and learn lower-level languages. I feel that way regardless of Electron though. On point 2: I spent the last year building a cross platform continuous sync app (basically, a Dropbox V1) in Electron [0]. We were a team of 2. I also write C and C++ for a living, and I simply can't imagine building the same thing in a lower level language in the same timeframe. It's not just a UI concern either: writing a sync engine in node (the backend half of any Electron app) worked out amazingly well. Node is a great I/O orchestrator. The app runs at < 1% cpu when not actively syncing, 40MB backend process, 70MB frontend process. Reasonable for what it does. Dropbox uses more than double that although, granted, it's also not native code. [0] https://blend.io/download https://blend.io/download
• shadowmint 10y ago
  yeah yeah. It's bad. So big. So slow. So bloated; so... What's your alternative? I don't see any meaningful suggestions in this article, just complaints. You don't like how resource intensive electron apps are? Well, don't use them. If its really a big deal, people not using the apps will inform the people making the apps that they're bad. That's not happening, so clearly it's not a big deal for most people. Still... things could always be better in a perfect world. Are you building desktop applications? What are you using for it then, and whats your cross platform perf story like? How long do cross platform releases take you? What are you paying for your tools and tooling?
  • niutech 10y ago
    The alternative mentioned in the article is React Native, which runs on iOS/Android/Ubuntu/OSX/Windows. Another lightweight alternatives to Electron are: Mozilla Positron (https://github.com/mozilla/positron https://github.com/mozilla/positron), Webkit for Android/Windows (https://github.com/daewoong-jang/webkit-android https://github.com/daewoong-jang/webkit-android) and Qt Quick (https://www.qt.io/qt-quick/ https://www.qt.io/qt-quick/).
• artursapek 10y ago
  When I profile Slack on x.slack.com, it seems to be pretty good about being "idle". The flame chart is mostly empty. As the article also points out, I think this is a problem with Electron/Chrome. Just want to be sure the Slack devs get their credit here.
• peternicky 10y ago
  This guy compares electron to react native...totally invalidated his opinion, in my eyes.
• jrochkind1 10y ago
  I didn't realize react-native could be used on the MacOS desktop. Anyone have experience with it, is it ready for prime time?
• ericlnu 10y ago
  Good article. I've almost always had slow computers... My current cell phone is faster than my netbook, with more RAM too. So I know the pain. So please give everyone a break. My internet access isn't crap either, but when browsing the web is painful to the point where the only thing running on your 'desktop' machine is the browser, there's a big problem. Not only the machine, but developers' mentality.
• ericlnu 10y ago
  Good article. I've almost always had slow computers... My current cell phone is faster than my netbook, with more RAM too. So I know the pain. So please give everyone a break. My internet access isn't crap either, but when browsing the web is painful to the point where the only thing running on your 'desktop' machine is the browser, there's a big problem. Not only the machine, but developers' mentality.
• smokeyj 10y ago
  There's two kinds of developers. Dorks who care about programming, and programmers who care about creating deliverable value. What do consumers think about electron apps? That's all that matters. Consumers don't know what the heck electron is, only that their apps work seamlessly across platforms. The only people who complain about electron apps are dorks who have an axe to grind with web developers. I'd rather have my apps use more resources than crashing unexpectedly and opening up security holes because the developers thought it'd be hipster to write it in C.
  • MarkMc 10y ago
    I completely agree with the content of your message, just wish you had used a word less derogatory than 'dorks'
    • smokeyj 10y ago
      I don't think it's derogatory enough. There's always these same rehashed arguments against electron - and it's always because of the same reason. The developer thinks he's a special snowflake and knows something that everyone else doesn't. He knows the "right way" and everyone else is dumb for not realizing it. FTA: It turns out modern operating systems already have nice, fast UI libraries. So use them you clod! FTA: Also all you web devs: Go learn C or Rust or something. I just want to know who the hell keeps upvoting this neckbeard bullshit.
      • 4D1 10y ago
        One problem, you cant optimize at all with electron, you are stuck with shoving a complete web browser solution into your program to make a GUI. You are stuck with a massive amount of dependencies (html/css parser, javascript VM...) to various massive projects for what, easy cross platform support? Sure cross platform GUI's have been a problem, but any developer can agree that dependency to this level within professional code is a great way to cause a massive amount of headache from required library changes, bugs and memory leaks that you have NO control over due to it not being your code, required security updates that require code refactoring for no fault of your own, etc. People keep bringing this up because it is a bad solution to a large problem. Maybe the reason its being rehashed so much is because there is truth to what is being said. I would try finding a graphics library such as opengl, and build a UI in the spirit of something like: https://github.com/ocornut/imgui https://github.com/ocornut/imgui https://github.com/vurtun/nuklear https://github.com/vurtun/nuklear
• grinich 10y ago
  At Nylas we made a huge bet on Electron-- our desktop app Nylas Mail actually started as a fork of Atom Shell before the project was rebranded to "Electron." To be honest, we would have never built this app without Electron. It allowed us to have a small team (2 devs) ship the first version of the app without learning an entire new dev toolchain on multiple platforms. There certainly can be performance issues with building on Chromium/Node but those can be pretty easily addressed. We even had an early engineer with tons of Cocoa/ObjC programming experience and they still preferred shipping with Electron. The HN crowd complaining about Electron kind of feels like the early criticism of Dropbox or the iPod. "This is technologically inferior and has fewer features so it is clearly worthless." For some reason there's a deep-rooted philosophical opposition to Electron-like technologies from lots of hackers. But I predict it will be like Java-- everyone "hates" the JVM for years and calls it slow and then one day it's running nearly every mobile device and being used across Google. It's not crazy to think Electron will evolve like this-- it certainly has the momentum. And the ideas of a web-based desktop app platform have been pushed by Google, Apple, and Microsoft in the past. Seems like we're finally getting there... (For the curious: https://github.com/nylas/nylas-mail https://github.com/nylas/nylas-mail )
  • pdimitar 10y ago
    It pains me to see how a person responsbile for a pretty important app is as oblivious as you are to the real issues. Many people use laptops and their battery life matters a lot, being one "minor" factor. Not to mention that in a technical sense, your app really shouldn't take any CPU while idling. Doing a socket wait is something a Raspberry Pi Zero handles without going to more than 1% CPU, for half a second. At any rate, other people in this thread explained it much better than I could: https://news.ycombinator.com/item?id=14091782 https://news.ycombinator.com/item?id=14091782
    • namuol 10y ago
      > [...] oblivious as you are to the real issues [...] I understand that you're frustrated, but this kind of language does not foster productive discourse. As I understand it, Nylas (grinich's OSS Email product/platform) wouldn't have been possible to build with a two-person dev team had they chosen to implement it in something other than Electron. Are you suggesting we're better off without competitors to the existing email desktop-clients?
• tehabe 10y ago
  I would prefer progressive web applications, which are stored in a cache and run in the available "browser" of the system, might it be Chrome, Safari, Firefox, or Edge.
• johnnydoebk 10y ago
  Is there a Servo + WASM based alternative to Electron yet? Would it be more effective?
  • deleted 10y ago
    [deleted]
  • oridecon 10y ago
    I won't touch these kind of apps until Servo is here, with 60 FPS animations. If they can deliver that it will be a game changer. I find disgusting that Electron (or even UWP apps) can't do that on PCs with high-end hardware. A simple laggy fade effect on a modal and my eyes start rolling to the back of my head.
  • niutech 10y ago
    Yes, there is Graphene with Servo: https://github.com/browserhtml/browserhtml/wiki/Building-Graphene-(Servo-flavor) https://github.com/browserhtml/browserhtml/wiki/Building-Gra...
• murukesh_s 10y ago
  Better than JRE based ones. They eat far more memory and are slow and often buggy.
• automathematics 10y ago
  So many divisive opinions here, but in case anyone reads this far down, here's my 2 cents: - Yes, desktop apps existed before Electron. But the top comment is right. How many desktop apps. NOT utilities but full featured apps (like Spotify and Atom) that you loved either got swallowed up by other companies (Mailbox) or discontinued due to "lack of use" (read: lack of profitability). I'm sure if you dig deep you can remember quite a few... I'm a game developer with a background in C++. But I'm developing my company's prototype in electron. This is because I can do it myself without needing to tap a bunch of people to help and find funding. I can bootstrap. Electron allows this and it's incredible. I couldn't make a cross platform game engine in a year on three platforms using native. Maybe you can and you're just a better human/coder than me (but seriously, email me in a year with your progress!) but Electron is allowing it. What does this allow? This allows me to release a product (yay) and maintain a product easily (double yay!) and when you guys don't throw money at me.... I can KEEP maintaining it because of my low overhead. With native code and a staff of 20 I would be forced to shut down the product. THAT BEING SAID If the game does well? I'm not only using Electron, I'm using React (yes, it's a game. Yes I know, I've had this discussion. I'm crazy) so the next step is to port it to react native on the desktop and remove the Electron dependency. Totally doable since Microsoft is supporting it on the Univ. Windows Platform (https://github.com/Microsoft/react-native-windows https://github.com/Microsoft/react-native-windows) but macOS? Someone's working on it but it's of course not apple (https://github.com/ptmt/react-native-macos https://github.com/ptmt/react-native-macos). Ubuntu is on top of shit though (https://developer.ubuntu.com/en/blog/2016/08/05/introducing-react-native-ubuntu/ https://developer.ubuntu.com/en/blog/2016/08/05/introducing-...) I can't speak for Spotify or Slack or any of the people mentioned (yes I know Spotify isn't using electron) but for a small company of 1 and a half people Electron is allowing innovation and project completion in a way that nothing else is for me. It's a great door to open to allow future optimizations. And hey, maybe Electron will slim down too... give it time. Remember how bad Windows development was? No? I do. But .NET has come a long way, maybe electron will too. If not, we can always port!
  • castone 10y ago
    Why not use Unity instead?
• mananvaghasiya 10y ago
  Election really is flash of desktops, just use 3-4 years old hardware to feel the pain.
• itaysk 10y ago
  On Windows I was a huge proponent of Chrome's "save to desktop" feature, which basically gave me the same experience of a native app (separate window, no window chrome, pinnable to start and taskbar, notifications, links open in separate window, etc). I have recently switched to Mac and I miss this feature so much. I have found https://applicationize.me/ https://applicationize.me/ but it's not seamless as "save to desktop". I wonder why they dropped it from the Mac version of Chrome...
• tdelet 10y ago
  Is being "Flash for the desktop" considered a good thing? Wasn't AIR Flash for the desktop? And didn't that already flop?
  • zwetan 10y ago
    considering Adobe MAX 2016 Resources about 8 Billions AIR Applications installs, I would not call that a flop see here for more numbers and details https://discuss.as3lang.org/t/adobe-air-by-the-numbers/476 https://discuss.as3lang.org/t/adobe-air-by-the-numbers/476
• cbhl 10y ago
  I think JavaScript is the new PHP -- it's accessible enough that people are going to be coding in it for the foreseeable future. Chrome eats a lot of RAM, and frankly, most of these apps don't need all of Chrome. But any solution that requires moving away from JavaScript (e.g. C++/Qt apps) is too expensive in terms of retraining developers. (Facebook found it was cheaper to create Hack and HHVM than to train its engineers to stop writing PHP-like code.) Maybe the answer here is a "React Native" library that results in native Windows/Linux/OS X desktop apps. But, with larger corps focusing on "mobile first" and "responsive design" memes, I don't imagine either Facebook or Google being the first to build such a thing.
• dethos 10y ago
  Good to see I'm not alone, I've been complaining about this "bloat" and mindset for ages.
• kruhft 10y ago
  It's not Flash, it's the new Visual Basic 6.
• JepZ 10y ago
  There are two totally different points mixed up in that blog post. 1. Delivering your app with electron 2. Writing a web app versus writing a 'native' app Yes, delivering an app with electron might be subpar as it brings code to your computer which it probably already has. Most Computers which are targeted by electron apps already have a browser and lots of them have up-to-date chrome or firefox browsers which offer features very similar to electron. So I don't say there is no reason why one should use electron, but I urge every developer to make their web apps accessible to browsers too and let people use their browser if they want. Even offlines usage is no problem anymore as we have serviceworkers in the majority (by market share) of browsers nowadays. The second point, however, is very poorly laid out in the blog post. Web apps do not have a general problem with performance as suggested by the article. Maybe some are badly developed but in the end, they are all backed by the tremendous efforts that were put into browser performance in the past years. The question if web apps can deliver the required performance was answered by the 60 FPS discussion a few years ago. At the moment, the web is the only truly OS independent platform I know of. That is a very valuable feature and one we should treat with the deserved respect. So please write quality web apps and do us all a favor, instead of just choosing one specific platform. Yes, react-native is an option too, but I think it is a bit limiting to define just one framework as the one true way.
• ceedan 10y ago
  The best perf improvement for slack is to disable animated images in the Accessibility Settings... this also removes some of the fun from Slack. I have suggested to them that they should have a setting to only play gifs when they're hovered-over, but still waiting on that to be implemented... Other tips I've ritualized, use /collapse very often when on slack, and avoid message reactions with animated gifs. Animated things are why Slack will idle at 5%+. Lots of them and you're going to idle even higher. Don't leave slack open on a channel where people frequently use /giphy or post lots of animated emojis (#random, etc). Reactions to comments with animated gifs are the worst, because /collapse wont hide them. In my test locally, a chat window with no animated things is idling at 0-1.5% CPU. I just added 1 animated gif reaction to a comment and it's idling at 4-6%. It's absolutely horrible. I removed that comment and then posted using /giphy, now it's idling at 2-3%. A Slack Helper task started to run at 12%. Ran /collapse and both are back down to 0-1%. Reacted to a message with 10 animated gifs, slack is idling at 9-12%. Slack Helper is at 26.9%. Brutal. Can't /collapse to fix this, either. - In Advanced Settings, just turned on "Disable Emoji Spritesheet" and slack is idling at 7-9%, Slack Helper at 27-30%. - In Accessibility Settings, disabled "Allow animated images and emoji" and Slack is idling at 0-1% and Slack Helper at 0-1%.
• Marazan 10y ago
  Flash player was A pretty minimal download and was not a resource hog. Shitty punch the monkey ads hacked together by people who couldn't program were the CPU killers
• mydigitalself 10y ago
  Btw, I can tell you exactly what the "Preventing Sleep" is all about. I'm 100% positive there's a bug in Chrome's WebRTC stack that causes that to happen. Fire up Chrome, doesn't happen. Go on a Hangout, yip "Preventing Sleep".
  • bengotow 10y ago
    But... isn't this correct? I wouldn't want my machine falling asleep while on a conference call, so preventing sleep is a good thing?
    • belovedeagle 10y ago
      I'm pretty sure GP is talking about CPU low-power state like OP did, not OS sleep. They're entirely different things.
• gavanwoolery 10y ago
  All of this extra memory and CPU power has made us lazy. Simple applications often lag, because they are written on top of heaps of crap. Yet you look at a 4k demo that does more impressive stuff with a fraction of the resources. When we step really far back, an application should not require that much code. Nor should the process of abstracting an application on top of a native system. These things only get muddled when you depend on specific functionality of the system that is difficult to abstract (i.e. native GUI component and layout), which you can easily simulate with your own GUI renderer, potentially in a more optimal way. Anyhow, I'll sit here waiting patiently until someone figures out how to write once, run everywhere in a relatively bloat-free manner. :)
• mschuster91 10y ago
  I disagree with the "flash" sentiment. The biggest disadvantage of Flash was and is that it's closed-source. Which means it's likely still filled with exploits waiting to be exploited. Also, it could not be ported to any other platform by the community. Electron, on the other hand, is open source and can be built for a wide variety of systems and CPU architectures, as well as it can be audited for security issues.
• rcarmo 10y ago
  I'd take this a step further and posit that JavaScript is the modern equivalent of Ethernet (the original protocol): simple enough to actually work despite all its shortcomings, hence doomed to success.
• deleted 10y ago
  [deleted]
• ndesaulniers 10y ago
  Electron exists to allow JS devs to bypass browser vendors slowly coming to agreement on new features.
• tyler_mann 10y ago
  The electron bundle zipped without any extra app code is only 40MB. This is barely any bigger than the smallest of most iOS that get auto-downloaded to your phone every day. I haven't ever noticed any significant performance hits and I use Slack/Spotify every day. The problem you are speaking to is the same one that comes with any framework that is distributed. Any app using Swift 1.0 had to ship the Swift runtime with the app bundle until they eventually baked it into the OS and allowed sharing framework versions. The same problem happens with JVM if you've ever used a java app on Mac that doesn't use the built-in Java runtime. Its not really a concern to me, as I think this size is negligible and the runtime for Chrome is already the model of isolation so this just extends that slightly further. However I'm sure the Electron folks would be happy if you wanted to contribute to further the performance/usage requirements of the platform.
• mmagin 10y ago
  No mention of Adobe Air? :)
• abalone 10y ago
  There actually is a Flash for the desktop. It's called Adobe AIR. And it suffers from the same CPU/energy hog problems. I do wish big, well-funded companies would invest is proper native apps. I get that making it easy to crank out cross-platform apps has benefits, but is it really too much to ask for nice native implementations of our most important tools?
• bhargav 10y ago
  Electron is flourishing because of low barrier to entry like many already touted. But lets ask something [probably] more constructive? I've made 3 apps with Electron that I could probably never make since I would be busy learning OS specific things. Can we not have low barrier to entry for creating native apps? Are there any solutions/frameworks that one can utilize? Is it just a matter of poor documentation/support from OS makers? What is it? Edit: Some of the contents that said something along the lines of: Is it really slow? It opens so fast for me... The worse thing a developer can do is judge their application anecdotally and not through something more empirical. Its our job to make our shit available to more users and support more platforms (hence Electron is used) but it is also our responsibility to make sure they can use our app and have 50 tabs open and do other more important shit like... watching genitals in a flash player. I was in this Electron phase but I started to run traces and see how much of a hog it is. If you really care about what you are working on, use Electron as a prototype, get it out there, then start making a native app. I think this is the best of both worlds. You get your shit out there, people let you know how it stinks and in the mean time you make something that is better suited for their OS. P.S: Sorry for the overuse of "shit". I am fishing for upvotes.
  • ziikutv 10y ago
    So many up votes (thanks for taking the bait!) But I really am wondering: > Can we not have low barrier to entry for creating native apps? Are there any solutions/frameworks that one can utilize? Is it just a matter of poor documentation/support from OS makers? What is it?
• quantum_state 10y ago
  It seems to me that there is not much to worried about ... it is an ecosystem ... things would naturally evolve ... if electron happens to consume too much power n conserving power is an important concern ... the developers will need to do the right thing .. otherwise the app developed will not get used by that many ppl ...
• farzher 10y ago
  Electron is amazing. It's the best thing to happen to desktop since I can remember. Yeah it makes slow apps, but these apps wouldn't be possible otherwise. It's perfect for prototyping new exciting ideas, it's fun to use, and there's no alternative. When your app get super popular maybe you should rewrite it in gross native code though.
• luord 10y ago
  The other day I read a blog post that argued how "Fight for the users" should be a core tenet for every developer. I agree; and, unfortunately, the main undercurrent of the defense of electron, at least in this thread, is one of almost complete disregard for the users. Yes, most of them probably won't notice the performance impact. Most of them also don't notice whether their applications are insecure or overstep their privacy boundaries. It doesn't mean we shouldn't care about security or should build hidden trackers into all the code we produce. That aside, Electron is just an ugly idea in general (obligatory IMO). I wouldn't want to run an entire browser just to run my own apps, next to the actual browser. And I say this as someone who works almost exclusively in web development and who likes javascript.
• frogfuzion 10y ago
  Very late to the conversation! I'm not going to offer an opinion, but just anecdotal evidence. We don't use Slack, but since we have Office 365 I was tasked with evaluating if Microsoft Teams was something we should start using instead of Skype, etc. I have advised to wait. I was seeing similar metrics to what OP is describing where the Teams Client was using 200+ Mb of RAM (many times more than VISUAL STUDIO). Also the UI seemed laggy. I'm not 100% sure it is Electron, but the installer and interface seemed as much.
• rjurney 10y ago
  What strange things to want to be in 2017. "Desktop" and "Flash" are not exactly hot spaces or desirable technologies.
• zensavona 10y ago
  ...and you know what Flash did for the web when it came out? Allowed us to watch videos, drag and drop, consume all kinds of media and have interactive applications on the web which were at the time totally unachievable with JavaScript. Is the internet's memory so short that you've forgotten how recently we have largely switched to HTML5 video?
  • douche 10y ago
    We've just spent the last 10 years spinning to get back to where we were, because Steve Jobs vetoed Flash support. Before that, we bailed on similar capabilities from Java applets, and had to reimplement them. Doubtless there's multiple technologies before my time that gave us the same powers, but were abandoned because reasons.
• ilzmastr 10y ago
  How is "We carry supercomputers in our pockets. Its simply not ok for apps to be sluggish." not a non sequitur?
• sanbor 10y ago
  For something like a music player maybe electron it's not the best choice. But Slack might have several features where they need to parse and show html. Also, they're probably using webrtc for calls. On top of that, they can reuse most of their code which is a web app. That means less bugs and if they fix a security issue in the web app they also fix the desktop/electron app. I wonder why the author doesn't just use the web app in chrome. The notifications works pretty well. Personally, I prefer the performance penalty and enjoy apps in Linux than having great desktop apps that only work on Windows and/or Mac. It would be great to not have to choose but we all have limited resources and Linux often doesn't make it in native desktop apps.
• beezischillin 10y ago
  The best way forward for Electron is probably to get a very thin, light core instead of the current Chromium-based one. Even on a good 16 gigs of ram and an i7 you feel Electron-based applications' effect on a system. If you want a compromise between easy multiplatform desktop app development and not wasting resources, the ideal way there may be something like Microsoft's React-based desktop framework that they just released. (in my opinion at least)
• iameli 10y ago
  So minimize your use of the Electron APIs. And then when someone releases a leaner Javascript runtime, port to that, keeping 90% of your application intact. This would be a good idea even if Electron didn't have these problems.
• iameli 10y ago
  So minimize your use of the Electron APIs. And then when someone releases a leaner Javascript runtime, port to that, keeping 90% of your application intact. This would be a good idea even if Electron didn't have these problems.
• Akira1364 10y ago
  I tried Hyper, listed in their "apps made with Electron" gallery thing. lol 250 megabyte fancy command-prompt
• johnchristopher 10y ago
  So. Where is the html5 of electron apps ?
• z3t4 10y ago
  Computer resources are like a budgets. It doesn't matter how much you get, it will all be used.
• yourapostasy 10y ago
  Electron has its place, but I'm not entirely certain touting Electron-powered text editors is a satisfactory success story. The success story is on the business side, IMO: it is another write once, deploy everywhere mechanism. Text editors are a very personal choice, but if I had to choose between an Electron-based text editor or Emacs in say, a developing world context, Emacs would win every time because re-purposing a 5+ year old laptop that only gets power from a solar panel is feasible with Emacs, at the cost of a steep learning curve. There are always tradeoffs. Electron is very suitable for the particular contexts that it fits within, and OP made some salient points that there are some settings where it clashes with user demands. For the paying market that say, Slack cares about though, they are not sensitive to the tradeoffs made to run Electron underneath to the point that it hurts Slack's revenue to a level Slack cares about. This opens up an opportunity for someone else to step in and take the niche that Slack has currently declined to occupy, and that's not a bad outcome.
• guzgarcia 10y ago
  Electron as is, consumes relatively more resources than QT and it's obvious because uses Chromium under the scene. But this is not the only reason for a slow electron based program. Code is the most important thing in any application and it's the primary cause of bad performance. A well writen and optimized application will have a good performance, no matters on which platform is based (good ones, obviously). "Electron is slow" is like "Java is slow" right now. Do you want a probe of a well writen electron app? Check VS Code; it's fast, it have a good performance and consumes a lot less resources than Atom, for example.
• jitbit 10y ago
  Just reminding everyone that Telegram (a self-funded company, also a messenger) builds cool NATIVE clients for all platforms. And Slack (a company valued at $4 billion) writes some intern-level Electron apps. This comes from a desktop dev living in Europe (also frontend dev, backend dev, "you name it" dev). This goes to you bay area folks, you hipster-coders, JS-framework lovers ;) No offense.