25 ms·

That's nonsense. Desktop apps have been frequently released since forever. The underlying issue here is that Electron reduces the barrier to entry for cross-pl

That's nonsense. Desktop apps have been frequently released since forever. The underlying issue here is that Electron reduces the barrier to entry for cross-platform development. That is, it's cheaper to build a single cross-platform application in Electron than it is to build two or three native applications, and you can re-use your existing web experience. I can completely understand why companies might choose this approach. The trade-off — and there is a trade-off — is that Electron applications are shite in comparison with proper native applications. They fail to integrate with the host platform, they are slow, they hog memory and drink power. It's fine to make those trade-offs – in some ways, it's better that you can get an application at all than the alternative of 'no support for your platform'. But let's be honest here – there is nothing preventing e.g. Spotify or Slack from building native clients for each platform they support, and I find it difficult to believe that the costs would be prohibitive.

Touche 10y ago
> They fail to integrate with the host platform Just as a counter-point, because native app fans often make this point as though it is universally recognized to be a good thing. I don't want apps to integrate with the host platform. The host platform is not the thing I care about. I use several host platforms in different contexts (I have work and home computers and a smartphone, they all run different OSes) and I would prefer that Slack look like Slack and not have buttons in different places with different UI interactions just because that's the way Reminders.app works. For me, the web is the host platform I care about. It's the one that I can use anywhere and only have to remember the URL.
- matthewmacleod 10y ago
  I accept that not everybody will feel the same way – I do care about my local platform. I want to hit 'space' when I have an item selected and see quick preview. I want my documents indexed in Spotlight, I want to drag-and-drop files between applications, and I want all the rest of the UI niceties I am used to.
  - krallja 10y ago
    And on Windows, I want pressing Alt to highlight the first menu, and the arrow keys to move between and around menus.
- atombender 10y ago
  I doubt you don't care. These are examples "integration with the host platform": * Text selection * Caret behaviour (e.g. Option-arrows on macOS) * Clipboard * Spell check * Open/save dialogs * File system access * Drag/drop * Window management * Accessibility (screen reader support etc.) * Standard right click menus * Indexing (e.g. Spotlight on macOS) * etc. You may be thinking to native UI idioms, which even Apple threw out the window several years ago. Electron apps are mostly very good at the things in the above list, because the Chromium web renderer has spent years abstracting the mechanisms needed to feel native where it matters. Non-native toolkits such as Swing and Qt also spent years trying to achieve native look/feel, mostly through emulation and host OS detection, and they still feel pretty crappy compared to Electron apps. Slack, Spotify and friends do a good job of inventing their own "web but native-feeling" UI. An example of the exact opposite is Google Docs, which still, for all its technological impressiveness, feels like a crummy Swing app trapped in a web page. For example, Google Docs renders its own right-click context menus, which look and feel nothing like native context menus. Google Docs' mini-apps also have a menu bar and a toolbar, but it's part of the host window, so you get two levels of menu bars and tool bars.
  - Touche 10y ago
    No, I don't care about most of those things. I don't know why you didn't believe me when I wrote it the first time :). "Caret behavior", I use a Mac 8 hours a day and I have no idea what option-arrow does. That clipboard shortcuts work the same is the only one that I'm used to enough to be annoyed if it were done differently. There's something about Mac fans that are very preoccupied with all of the details of how Macs work. I'm not criticizing that, you like what you like, but you shouldn't be surprised that I don't care about Spotlight indexing.
    - lobster_johnson 10y ago
      You don't select or navigate in text? Shift+arrows — select characters Option+arrows — jump between words or paragraphs Cmd+arrows — jump to beginning/end of line or text Shift+Option+arrows — select words or paragraphs Option+Backspace — delete one word back Cmd+A — select all I actually used all of these except the last one while writing and formatting this comment! Plus clipboard shortcuts. If you use vim in a terminal 100% of the time, none of those will matter to you because vim invents its own keyboard universe. But if you don't, I don't understand how you can have this opinion. I get super annoyed with anything that somehow overrides these standard keyboard shortcuts, which is suprisingly often. Non-native UIs typically have to reimplement them because modern OSes have made the curious choice of not abstracting them. I don't think it is a "Mac fans" thing. The exact same principles apply to Windows. Even to Linux, although the keyboard standardization there is next to non-existent. (I don't use Linux desktops often, but when I do, I get really frustrated that the terminals use Ctrl as a meta key instead of Command. So "copy" isn't Cmd+C, it's something like Ctrl+Alt+C.)
- jernfrost 10y ago
  1) Why use several host platforms if the platform makes no difference to you? 2) If you know a platform then you should have no problems knowing how to use it. It would be ridiculous to have an app from Windows behave exactly the same in Mac OS just because you don't want to remember the difference. You don't want minimize and maximize buttons put on the opposite side of all other mac apps because that is how it is on windows. You don't want copy paste in Slack to use Ctrl rather than command key because that is what you do on Windows. 3) Whatever time you save from doing everything the same across platforms would be wasted, for anybody not working cross platform who suddenly have to deal with an app with completely non-standard alien behavior. I want my standard mac hot keys to work in a mac app. I want preferences to be in the standard location. I want my color and font selectors to work the way they work all other places. I want drag and drop to work like in all other Mac apps. We Mac users have seen this again and again. When companies don't give a shit about our platform, it is usually just a question of time before a competitor arrives which does, and knocks the other guy out. You don't survive that long ignoring the platform unless you got some lock-in advantage. Why else do you think people make a big point of an app being native Cocoa? It is because they know it sells better, because they know customers want the native well integrated experience.
  - Touche 10y ago
    > 1) Why use several host platforms if the platform makes no difference to you? I don't, I use The Web for 90% of all things I use on a computer. A Chromebook is one of the computers I use the most when not working for precisely this reason. > Why else do you think people make a big point of an app being native Cocoa? It is because they know it sells better, because they know customers want the native well integrated experience. I think you're mistaken, the fact that so many company are switching to Electron is evidence that it doesn't sell better.
    - chipotle_coyote 10y ago
      I think you're mistaken, the fact that so many company are switching to Electron is evidence that it doesn't sell better. Hold on a bit with that assertion. First: which apps built on Electron are being sold, period? All the ones I'm aware of are open source, like Atom, or front ends to services, like Slack. Second: which companies are switching to Electron for development? Again, all the Electron apps I'm familiar with are ones that started out that way. While I'm sure there's probably an app or two out there that began as a native client and then went to "let's just be a web wrapper," I don't know of any big ones offhand. (I've come across companies that have shifted their strategy to using true native applications, however. Facebook famously shifted their mobile strategy from HTML5/JS to native apps some years back, and I know of several iOS apps that were using "write everything in JS, it'll be great!" toolkits that switched to actual native AppKit.) Third, and admittedly anecdotally, in both my experience and what I've consistently heard and read from people who've had the opportunity to study the UX of both native and "wrapped web" apps, just because users don't use the language of developers doesn't mean they don't notice when apps are slow, resource-hoggy, and behave kinda weirdly compared to other apps. I run a Slack for a writing group that's mostly populated by non-technical people and it is not uncommon for users to complain about Slack "slowing down their machine." Just because people don't know the term "native app" doesn't mean they aren't going to be able to tell "this app over here is nicer to use than that app over there," and that might be because "that app over there" doesn't minimize properly, or has weird menus that put common things in uncommon places, or doesn't do what they expect when they right-click on selected objects.
Etheryte 10y ago
> The underlying issue here is that Electron reduces the barrier to entry for cross-platform development. It's very far-fetched to call a lower barrier to entry an issue. The easier we can make it for people to get started, the better, isn't it?
- matthewmacleod 10y ago
  Point taken – 'issue' is not the correct term here. Perhaps 'cause' is better. Lowering the barrier to entry is great, I agree. It's awesome that Electron and web technologies can be used to quickly launch proof-of-concept desktop apps. I find it significantly less awesome that companies with hundreds or thousands of engineers continue to use it after the concept has been proven, however!
  - cr0sh 10y ago
    But these apps aren't "proof-of-concept" apps - they are fully functioning, working cross-platform applications. So are you saying that these companies which have implemented these apps should instead say "You know what, we have this app developed, and working on the major platforms - but let's instead devote three new teams, one each for Windows, Mac, and Linux - to re-implement this app natively! I'm sure upper management will agree!" That's not going to work. That's going to be shot down and laughed at. No company is going to re-implement a working cross-platform application over to three separate native contexts, and maintain all three. That just won't happen. It works already. The users probably like it just fine. What benefit to the company will this get them? Nothing - just more costs for maintenance across three platforms. If native is wanted by the users, likely what would happen - if it happens at all - will be the company says "Ok - we'll make it native for Windows, maybe even Mac - maybe. Linux? Forget it!" It's not the developers. Developers would love to make native apps, for all the platforms. But developers are limited by the companies they work for, and by the economic realities that all the platforms can't be supported natively; at most, only one or two can - because at that point, with the number of users on those platforms, the additional costs of maintenance and support are pretty much saturated. Adding additional native platforms doesn't just add onto those costs, it actually (in theory) multiply them - because a single person might use the application across multiple platforms. So if they have problems on two or three different native platforms, now there are three different support issues (needing more people to support) - instead of a single complaint for a single platform. I get it, though - it would be great if these apps were native, and worked on every platform, from now and into the future (even on platforms that don't exist yet!). That's just not going to happen; if native is wanted, then only the most widely used platforms will be supported, and even then, one of those will likely be dropped, and it won't be the one from Redmond. So - what can be done? I dunno. The concept the author brings up ("use React Native") might be the solution. Or some other interface that abstracts a platform's OS and other native functionality out to an API that is the same for all platforms. But now you have issues with security and other access - which you still have with Electron, but it is more contained and constrained, since it has to go thru the Chrome engine and the various rules/settings browsers have for sandboxing bad actors. Or - you leave it to the user and their operating system (and slim it all down - maybe that's what React Native does; I don't know, I've never used it). Or - you (that is, the company) just says "Sure - we'll do a native only implementation - for Windows only." - because that's how it usually goes.
Veen 10y ago
What you call "trade-offs" appears to me to be developers externalizing their costs onto users. There are costs to developing desktop applications and developers don't want to pay them, so they make users pay for them in wasted hardware dollars, bandwidth, RAM, battery life, and poor integration.
- wickedlogic 10y ago
  Yes. You just described modern computing.
  - sametmax 10y ago
    Computing for ever. We use C to avoid writing assembly. Use Java to avoid writing C. Use Python to avoid writing Java. The world is asking for more and more software, and the resources to provide it are not following so people are taking shortcuts. Want something better ? Someone has to pay for it.
    - cableshaft 10y ago
      Yeah, but Python still doesn't seem to have a great cross-platform desktop GUI, as far as I can find. I'd prefer to code entirely in Python if I could, but I haven't liked a single GUI library I've tried for Python. Although to be fair I haven't really tried PyQT out still, but I don't like the idea of having to buy a commercial license for it.
      - sametmax 10y ago
        PyQT is alright. Kivy as well. Or anything in any other language. But none of them are close enough to the benefit of being able to use the tone of experience from the Web UI into the desktop. Eventually all GUI app toolkit ends up with a custom MVC framework, a client/server architecture, some kind of db for persistence, their own implementation of asynchronous event and communication models and a declarative layer to create the UI without code. For the most advanced this layer separate structure and layout. Well guess what, this is what the Web has natively being doing for ever. Since the web is now the most popular platform, with millions of libs and tutorials on it, people just reused that. It just makes sense. The problem is not the concept. The problem is we should have driven this effort with a standard to sanely close the gap between the desktop and the web so that you don't have to spawn a freaking browser-engine-os for every one of your app. But no, the web is the only platform with a standard. And it flourished while all the big players created closes gardens with proprietary shitty API. And this is the result. Have you not seen Jurassic Park for god sake ? Life finds a way.
obstinate 10y ago
Can't say I agree. Native apps are often garbage. Discord is another Electron app that I think is actually quite a bit better in most dimensions (attractiveness, functionality, speed) than the native apps it replaces (Mumble, Teamspeak, Skype, etc.).
- Cthulhu_ 10y ago
  But is that due to technology choices, or due to more attention being paid to UX? (and I do believe webapps give more flexiblity in that regard) I get the feeling that UX and UI designers for web- and mobile apps are just a different breed than their native desktop equivalents. It might just be my Windows bias though, iirc Windows didn't have a strong / great UX guideline until their current one came around - and I haven't used many modern windows apps yet, the ones I do use are stuck in the 90's with their button bars and such.
  - obstinate 10y ago
    It's never going to be possible to fully separate the factors out. With infinite time and effort by the exact same set of devs, I'm willing to grant that electron apps will be worse than native apps. But that hypothetical circumstance (same set of devs, infinite time and effort) does not exist in reality.
  - mlsarecmg 10y ago
    That is due to the technologies available on the web being easily more suitable for GUI development than older native tools or desktop frameworks. We're in a similar boat, we made WPF apps. Now we're bringing it to the web and Electron. The things you can do now in React, heck i wouldn't even know where to begin in WPF or QT. If you look at modern Electron apps like Atom, VSCode, Discord and so on, the things they do and how flexible they are, this would mean so much hardship and pain in older solutions to the point where it's probably not viable any longer.
    - LeoNatan25 10y ago
      Other than declarative vs imperative, please substantiate your post with examples of what isn't possible in WPF or Cocoa. I have a feeling it's more of an experience / competency issue rather than lacking APIs.
throwaway2048 10y ago
In discussions like this its important to try to distinguish between a priori reasons and post hoc justifications. The real reason that parties like slack and spotify choose electron is because its easy for the devs they have that only really know JS/HTML. Its not that they couldnt hire more/different devs that could do it in a saner way, its not that its too expensive or that the ROI is not good, when we are talking about companies worth hundreds of millions to billions of dollars focusing on a core market, that is just completely laughable post hoc bullshit. Its that they dont give a shit, either about the user experience, or improving their toolset. They are happy where they are, and see no reason to change.
TuringTest 10y ago
If you basically agree with the parent post, why do you say it's nonsense? > The underlying issue here is that Electron reduces the barrier to entry for cross-platform development. Precisely. > The trade-off — and there is a trade-off — is that Electron applications are shite in comparison with proper native applications. But native applications are shite in terms of portability. > But let's be honest here – there is nothing preventing e.g. Spotify or Slack from building native clients for each platform they support See the part where the original post said "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". The costs may not be "prohibitive", but they certainly would multiply effort and resources, and divide profit.
- aidenn0 10y ago
  The "nonsense" part was that "nobody" was writing desktop apps for the past 5-10 years.
  - nilliams 10y ago
    Well they were exaggerating but I think they had a point, til recently on my Desktop machines I only cared about having a web-browser, terminal (+ Steam at home). Lately there are more UI-ish apps I value having everywhere including desktop (Spotify, Hipchat, Whatsapp, VSCode). I'd also love a decent cross-plat podcasts app. I think it's clear there's now more demand for certain types of consumer-ish desktop apps (chat apps & music apps especially) than there was a few years ago.
rndmize 10y ago
> The underlying issue here is that Electron reduces the barrier to entry for cross-platform development. Actually, the incentive is even stronger than this. The ability to visit a website and start using an identical version of the app immediately is just as important - I doubt that Slack and Discord would have had half the success they did if users had to download the application before using it, regardless of them being available on all platforms. Discord has had the ability to give links to others to join a chat server since its inception, resulting in a two-step process to use it: click the link, type a name. This is miles less of a barrier to entry than: click link, download app, find downloads, install app, run app, create account, join server (rough process for most text/voice apps up to this point).
- Cyph0n 10y ago
  Most people I know just the app though. Heck, I actually only discovered the Discord web client yesterday.
- mercer 10y ago
  It's a difficult trade-off, even for me as a user. The fact that I can load Slack on all my devices and in the browser definitely played a role in my adoption of it. The fact that Slack is dog-slow and a memory-hog on my MacBook Air, on the other hand, has kept me from using it as a central part of my own work. Similarly, I am actively pushing everyone I communicate with the switch from WhatsApp to Telegram because the latter has a performant native app. If I were to build an app where cross-platform support was crucial, I'd probably start with Electron as well because of time and budget concerns, and switch to native if the app 'takes off'. But on the other hand, I can imagine there being serious risks to building out an entire platform that way and having to rebuild it from scratch later on. Maybe there's never budget/time for it, leaving me locked in? I suppose React Native could help in that regard.
bmpafa 10y ago
Bingo--half these diatribes against Electron just seem to be making the case for premature optimization.
- Cthulhu_ 10y ago
  Spotify, Slack and Atom are no longer hip startups though - they're established applications, and at least two of them have a very lucrative monthly subscription model. They can afford to optimize.
  - yesimahuman 10y ago
    But the user experience is already great, so what's the gain? Electron and the web clearly make a first class app platform on desktop. EDIT: thanks for the downvotes. I'd love to hear your thoughts on how electron is keeping Slack and Spotify from building a massive business and how their desktop users find the experience so bad they don't use the tools obsessively. Clearly there are things to improve w/ Electron (energy usage), but "terrible experience" is not how I'd describe Spotify and Slack on desktop, and their businesses clearly reflect that. Moving to a native stack has major tradeoffs, would it 10x their business at least? I strongly believe that answer is "no."
    - josephg 10y ago
      Its a terrible experience to discover my battery life is cut in half because of a cursor animation in VS Code, or to have my laptop heat up and the fans engage because of an animated GIF in slack. But its worse than that - most users don't even know why their battery life is awful. So they blame apple, or microsoft, or dell or whoever. And they just don't use their computers as much, because its all a bit gross and slow. And thats bad news for our entire industry.
      - mlsarecmg 10y ago
        Hasn't it already been pointed out a thousand times now that this was just a bug in Chrome that has been fixed right away?
Cthulhu_ 10y ago
The cost argument is indeed a moot point - look at all of the major software companies, and you'll see that actual development is nowhere near their primary expense. They can afford to implement their own programming languages and OSes (and some do), but apparently it's too expensive or too difficult to make native apps for the respective platforms? This goes for mobile too.
- deedubaya 10y ago
  It's moot if you're an established company with deep pockets moving slowly. If you're starting from scratch with limited funds, it is definitely not a moot point. Would Slack have been as wildly successful if they had to implement native apps on all 3 platforms + iOS + Android + etc? I'd have a hard time believing so.
  - deleted 10y ago
    [deleted]
  - matthewmacleod 10y ago
    No, and that's fine. I don't think anyone is going to begrudge a small team the power of developing a 'desktop' application using cross-platform tools like that. It's great that the barrier to developing an application in that way is lowered. But that doesn't excuse the abuse of that platform. Spotify used to have a pretty convincing native Mac app, which was spiked in favour of their current abomination, and I've watched performance plummet. Using Electron as a cost-cutting measure is fine, but it's not good for user experience and it's OK to be honest about that.
    - srssays 10y ago
      Electron is great for user experience. Compare to something like JetBrains' IDEs which are written in Java and are much less native feeling than Atom (and just as resource-hungry).
      - bitwize 10y ago
Cthulhu_ 10y ago
The main challenge, I think is that all of those apps are cross-platform, but also want to keep the same look and feel on all platforms - they're using their own UX patterns inside the container which generally don't match up with their host OSes. There are some applications that do try so - 1password, GitHub for Mac/Windows to name a few that come to mind - but they seem to get less love than the cross-platform webapps. It feels like they get a certain amount of dev time before going to minimal maintenance mode.
xpaulbettsx 10y ago
Clarified my statement above re "nobody"
burnbabyburn 10y ago
isn't QT cross platform?! in my opinion this is an hiring problem, they assume that if you know javascript you can be spendable on more things and not only on the desktop to write an application.
spoiler 10y ago
Maybe I have the wrong impression, but I feel like the author of the original post never wrote anything cross platform that's sufficiently complex (ie, more than a "let's fill out a form and press OK" Qt app). > The trade-off — and there is a trade-off — is that Electron applications are shite in comparison with proper native applications. There's nothing inherently electron-specific that makes an app "shite" any more than writing one in Qt would. You can write shit in any language, framework or platform. The day someone invents a system that protects us from our own stupidity will be the day humans become obsolete. > They fail to integrate with the host platform, Untrue. You can—if you need to—integrate with the host platform by writing a native node module, however it becomes less cross-platform at this point. > they are slow, they hog memory and drink power. Yes web apps use a bit—sometimes considerably, depending on what you do—more memory, and a bit more CPU (and hence bettery), but they are not perceivably slower, unless you're doing something stupid (in which case the equivalent Qt app would probably suffer in the same way). > But let's be honest here – there is nothing preventing e.g. Spotify or Slack from building native clients for each platform they support, and I find it difficult to believe that the costs would be prohibitive. Maybe, maybe not. I think using a cross-platform solution wouldn't be ideal for them (they'd need to either rely on something like Qt, write their own rendering engine, or use something like SFML; all of these are overkill compared to Electron), and the alternative is writing it in different languages for each platform, which would probably inevitably cause the projects to get out of sync in one way or the other over time.
- abdulkareemsn 10y ago
  In article Author says he implemented user space usb driver for Chrome on Mac (guess what Chrome is cross platform)
  - spoiler 10y ago
    Implementing a feature for macOS in Chromium is considered a cross platform project these days?
deleted 10y ago
[deleted]
treehau5 10y ago
> That's nonsense. Proper this and proper that, and don't get me wrong, I agree, but parent is correct -- and that is these apps wouldn't even exist if it wasn't for Electron. It just wouldn't have been a consideration for it to be a desktop app. Instead it would have just been thrown up on the web. For example VSCode would have just been some type of online IDE clone like Cloud9 or something similar. If you think this is nonsense, you are out of touch, and I don't mean this as an insult, although I realize there isn't a good way to say that.
- _jal 10y ago
  I think people are talking past each other. Yes. Electron enables some new stuff. New stuff that wouldn't exist otherwise. Yes. Electron is a bucket of bloat that saddles what should be small, simple apps with enormous amounts of crap that has nothing to do with the app's functionality. Both of these can be (and are) true.
  - matthewmacleod 10y ago
    I think that's the real take-away here. There are upsides and downsides; I am pleased that it is easier to release desktop applications, but sad that the performance of them is so much worse. I wonder if one of the issues is that so many developers have now worked almost exclusively in the 'web' sphere, and aren't aware that native development maybe isn't as difficult as they think.
    - laythea 10y ago
      On the plus side, this is an ideal situation to take advantage of - by creating native and fast applications, it becomes easier (compared to before when everyone was doing it "the hard way") to distinguish your product in a bloated market.
      - nilliams 10y ago
        Not sure if ironic, seems a sure bet most users won't notice and gladly prefer the "bloated" product. Yet to hear a single non-dev coworker complain about Spotify being "bloated".
ballenf 10y ago
> ... Electron applications are shite in comparison with proper native applications. Is that true from a user's perspective? The average user I know would not have the idea that Slack is somehow inherently worse than say MS Word or any other truly native app they use everyday. What would Slack gain by integrating better with my Mac? Slack starts up too fast for me to read the little quotation (penultimate Macbook Pro). I actually wish it was slightly slower because I like those cheesy quotes when I can catch them. Everything feels almost instant. Not bash instant, but as fast as any mainstream messaging app. I leave it running all the time and get what feels like normal full hours upon hours of battery life. There are apps or browser tabs that I've noticed destroying battery life, but Slack nor Atom nor MS Visual code are on that list for me. The anti-Electron complaints all kind of feel like the same argument that comes up as each new layer of abstraction gains acceptance. I'm sure there's a lot that Electron can and should improve. Running multiple copies of Chrome does sound awful, but until I read that I didn't know the atrocities it was committing. Just doesn't feel productive to try to make Electron go away vs. working to improve it or create a better cross-platform abstraction.
- brandon272 10y ago
  Slack behaves perfectly fine for me and I don't have incredible hardware. It's non-Electron apps that are typically mentioned by macOS' energy management system as "consuming significant energy", in my experience. Edit: Mass downvotes; lol ... Just stating my personal experience!
- _jal 10y ago
  > Is that true from a user's perspective? It is for this user. > What would Slack gain by integrating better with my Mac? Far better resource management, one would hope, for starters. As the article pointed out, when you're measuring your IRC client's memory use in hundreds of megs, there's a problem. It isn't uncommon for me to need to choose which "essential" apps to turn off to get something done on a maxed-out MBP. So Slack gets turned off, and maybe someone gets annoyed that I don't respond to something, while I run a few VMs in Slack's former memory space. As far as other things, well, using a platform's capabilities as appropriate is generally considered good form - HCI concerns, and, generally, just people like things to be consistent. I don't know why we're supposed to forget this now. I personally don't care if Electron goes away or what, but to the extent that I'm forced to run Slack by my cow-orkers' choices, it sure would be nice if it were less of a bucket of ass.
deleted 10y ago
[deleted]
roryisok 10y ago
This issue is so furiously divisive, and I feel like it brings out the worst in HN. I'm from a web dev background. Some of the comments here make me feel like I should be ashamed of that fact. I can see both sides of this argument (every time it comes up) As a consumer of apps, I want the leanest, most minimalist, fastest thing going. I want native apps on my devices (If you think slack is a hog on the desktop you should try it on Windows Phone). But as a developer, I know that electron is a shortcut that means my app will take less time to build. I can take my existing skills, take work I've already done on a WinJS app and publish it on Mac OS, Linux and Win 7. I can spend more time with my family, instead of spending all my evenings learning py+qt, or xamarin, or react native, or whatever the new fangled thing is. And I know people will use it. Hell, I've even got better odds of pushing an electron app than a native one, as I can submit a pull request and maybe have it appear on https://electron.atom.io/ https://electron.atom.io/ Obviously, seeing the Electron hate always gives me pause for thought, but at the end of the day it feels like the hatred is from fellow coders (if a dribbling front-end-js writing low-life such as myself can call you writing-assembly-on-a-napkin-while-you-quote-stallman-types fellow coders) and my apps user-base is overwhelmingly non-technical.
- pseudalopex 10y ago
  Your non-technical users are capable of noticing that a certain application makes their computer slow or drains their battery or doesn't support a certain feature of their platform. It may take them longer to notice, and they won't know why, but that won't stop them from switching if a better alternative comes along. Delivering high-quality web apps generally requires knowing JavaScript and CSS. Delivering high-quality desktop apps generally requires knowing the tools of that ecosystem. Sometimes we compromise to get things out the door, but we should be honest with ourselves when we do.
  - roryisok 10y ago
    I'm honest with myself. I'm not disputing that Electron is not the most optimal way to create a desktop app, I'm saying that it makes desktop development (particularly cross-platform development) faster and easier. I know I could make a more efficient app by going native. And hopefully in time, I will. But for the sake of getting it out the door I'll most likely go the Electron route.
Tloewald 10y ago
Electron is like almost any other cross-platform VM, including Java (which is living under most of the "native" apps on the world's most popular platform), .NET, and so forth. It doesn't share resources between instances but then you also don't get dependency hell (wrong version of Java for application X, etc.) Subjectively, I'd say that Electron's performance overheads are not bad compared to, say, Smalltalk in the 90s, where one Smalltalk application could bring a fully loaded state of the art workstation to its knees. And don't get me started about Flash. I had a whole project cancelled after an engineeer brought up the CPU meter during a fairly simple animation.
- BatFastard 10y ago
  There are always bad engineers. I can write a shitty function in any language.
  - Tloewald 10y ago
    I've never seen anything performant built on top of Smalltalk, including the Xerox Star's built in apps which were developed by universally acknowledged geniuses. Flash's performance issues were legion. Chrome is widely considered the best current desktop browser in a very competitive space. If it has problems it's definitely in idle power consumption (which indicates wasted idle CPU) but it is used by a hell of a lot of people who have free alternatives.
newhere420 10y ago
> Electron applications are shite in comparison with proper native applications. They fail to integrate with the host platform, they are slow, they hog memory and drink power. Are they though? The two applications that use the most energy on my Mac - by far - are Steam and Skype. Steam still has trouble with HiDPI and freezes when performing various UI interactions. The number of problems with Skype are uncountable. I'm currently booted into Windows for work, looking at my current process stats, the top memory consumers are: * Visual Studio (hodge podge of all kinds of things, 800MB) * Chrome (215MB) * Microsoft Intune (presumably native, 114MB) * GitHub (.NET WPF application, 108MB) * Explorer (native, 103MB) * Search Indexer (native, 107MB) * Lync (who knows, 98MB) Meanwhile, the supposedly terrible Electron apps: * Spotify - 58MB * Slack - 93MB * VS Code - 60MB As far as interfaces go, Spotify, Slack and VS Code easily outclass GitHub, Visual Studio, Explorer and Lync in usability.
- frik 10y ago
  Steam always used a HTML renderer, even in its 2006 first incarnation. Nowadays it uses the same CEF (chrome library) as electron uses. So Steam was one of the first "Electron" apps. A very first one was Windows Explorer as of Shell update that came with Internet Explorer for Windows 95 (included by default in Win98). All the sidebars of Explorer were HTML based.
  - gant 10y ago
    No, VGUI is not HTML. Here's a fun one. Start Steam with `-dev` and hit F7. Widget factory VGUI edition! Oh also, https://developer.valvesoftware.com/wiki/VGUI_Documentation https://developer.valvesoftware.com/wiki/VGUI_Documentation
    - frik 10y ago
      Have I talked about VGUI? No. Valve used a very ubscure/niche HTML render engine initially for Steam (2006). The company/website behind that isn't online anymore. An older version of the Wiki had some brief info, but all these info vanished.
jrochkind1 10y ago
Not just cross-platform, I think it significantly reduces the barrier to entry (and total cost of your app) even for single platform.
signal11 10y ago
OneNote is a great example. It has fairly well-regarded native apps for each platform it supports, _and_ a decent web (HTML5) interface. I think the issue is time and resources. Small teams, like Slack, would like to create a slick experience but they don't have the time. Companies like Facebook went the other route -- HTML5 on mobile, got their fingers burnt, and went all-in on native. StackOverflow's iOS app appears to have improved a lot too, in v1 it was a thin shell around the web interface. I hope React Native catches on. I'm not a huge fan of how 'heavy' Electron is myself.
- thiht 10y ago
  Facebook's HTML5 app was 5 years ago, this example comes every time but it's outdated. technologies like Electron or React Native didn't even exist at the time. 5 years is huge when it comes to web technologies.
psyc 10y ago
This reminds me of what's happened with Unity (the game engine). There's a completely false perception that Unity is eating other engines' lunch. It isn't. All that happening is that game development has been democratized on an absolutely massive scale. So more games are being made. Most of them are bad. Most of the best games are made with either Unreal, or much more commonly, proprietary C++/asm engines.
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
username223 10y ago
Those who forget desktop Java will be doomed to repeat it. For those of you who aren't old enough to have been around, Sun initially pushed Java as a "write once, run everywhere" GUI language. It quickly became clear that Java applications were ugly and terrible everywhere, even in the primitive days of X11R5, when programs used a mixture of Xt, Motif, Qt, GTK, and raw X11 protocol (xv was awesome). Having a Java program for some task was worse than having no program at all, since it would discourage someone from writing a decent native solution. Fortunately Sun found ways to make money using Java server-side, and Apple helped kill it client-side by not providing it by default.
- emj 10y ago
  I would like to offer http://openstreetmap.org http://openstreetmap.org as a counter example, where the best editing app is made in Java and the most used one is Javascript. There have been QT4 editors but they have never gained traction, I never found the problem to be performance between native and Java. I think Javas problem was it's Unix engineering roots, with too little focus on UI, and perhaps a little too much of the "we don't care about performance"-mindshare. The latter being the only problem I see with some electron apps.
shalmanese 10y ago
Facebook still has not made any desktop apps available, leading me to rely on a hodgepodge of 3rd party, electron-esque shells to provide a desktop experience. This is despite their mobile apps being the most minutes used apps of any company. Even then, they tried to go with a electron-esque approach and only backed off when the performance and UX tradeoffs became unacceptable. If one of the most profitable companies in the world can't see the business case for supporting a first party desktop ecosystem, it's very hard to believe many other companies have the justification. This isn't an engineering problem, it's a business problem.
ender89 10y ago
They don't. Java apps have been cross platform since their inception, .net is extremely close to being just as versatile, x11 is available on mac and pc, and python will run on literally anything. There's a pile of cross-platform options out there for you. What electron does is reduce the barrier to designing UIs, since you can do it all in html and javascript and its just as easy as hiring the guys who did your website to design. Because the one thing all those platforms have in common? Aside from .net (which isn't mature), they all have absolutely hideous windowing systems. Just ugly.

Touche 10y ago

> They fail to integrate with the host platform Just as a counter-point, because native app fans often make this point as though it is universally recognized to be a good thing. I don't want apps to integrate with the host platform. The host platform is not the thing I care about. I use several host platforms in different contexts (I have work and home computers and a smartphone, they all run different OSes) and I would prefer that Slack look like Slack and not have buttons in different places with different UI interactions just because that's the way Reminders.app works. For me, the web is the host platform I care about. It's the one that I can use anywhere and only have to remember the URL.

matthewmacleod 10y ago
I accept that not everybody will feel the same way – I do care about my local platform. I want to hit 'space' when I have an item selected and see quick preview. I want my documents indexed in Spotlight, I want to drag-and-drop files between applications, and I want all the rest of the UI niceties I am used to.
- krallja 10y ago
  And on Windows, I want pressing Alt to highlight the first menu, and the arrow keys to move between and around menus.
atombender 10y ago
I doubt you don't care. These are examples "integration with the host platform": * Text selection * Caret behaviour (e.g. Option-arrows on macOS) * Clipboard * Spell check * Open/save dialogs * File system access * Drag/drop * Window management * Accessibility (screen reader support etc.) * Standard right click menus * Indexing (e.g. Spotlight on macOS) * etc. You may be thinking to native UI idioms, which even Apple threw out the window several years ago. Electron apps are mostly very good at the things in the above list, because the Chromium web renderer has spent years abstracting the mechanisms needed to feel native where it matters. Non-native toolkits such as Swing and Qt also spent years trying to achieve native look/feel, mostly through emulation and host OS detection, and they still feel pretty crappy compared to Electron apps. Slack, Spotify and friends do a good job of inventing their own "web but native-feeling" UI. An example of the exact opposite is Google Docs, which still, for all its technological impressiveness, feels like a crummy Swing app trapped in a web page. For example, Google Docs renders its own right-click context menus, which look and feel nothing like native context menus. Google Docs' mini-apps also have a menu bar and a toolbar, but it's part of the host window, so you get two levels of menu bars and tool bars.
- Touche 10y ago
  No, I don't care about most of those things. I don't know why you didn't believe me when I wrote it the first time :). "Caret behavior", I use a Mac 8 hours a day and I have no idea what option-arrow does. That clipboard shortcuts work the same is the only one that I'm used to enough to be annoyed if it were done differently. There's something about Mac fans that are very preoccupied with all of the details of how Macs work. I'm not criticizing that, you like what you like, but you shouldn't be surprised that I don't care about Spotlight indexing.
  - lobster_johnson 10y ago
    You don't select or navigate in text? Shift+arrows — select characters Option+arrows — jump between words or paragraphs Cmd+arrows — jump to beginning/end of line or text Shift+Option+arrows — select words or paragraphs Option+Backspace — delete one word back Cmd+A — select all I actually used all of these except the last one while writing and formatting this comment! Plus clipboard shortcuts. If you use vim in a terminal 100% of the time, none of those will matter to you because vim invents its own keyboard universe. But if you don't, I don't understand how you can have this opinion. I get super annoyed with anything that somehow overrides these standard keyboard shortcuts, which is suprisingly often. Non-native UIs typically have to reimplement them because modern OSes have made the curious choice of not abstracting them. I don't think it is a "Mac fans" thing. The exact same principles apply to Windows. Even to Linux, although the keyboard standardization there is next to non-existent. (I don't use Linux desktops often, but when I do, I get really frustrated that the terminals use Ctrl as a meta key instead of Command. So "copy" isn't Cmd+C, it's something like Ctrl+Alt+C.)
jernfrost 10y ago
1) Why use several host platforms if the platform makes no difference to you? 2) If you know a platform then you should have no problems knowing how to use it. It would be ridiculous to have an app from Windows behave exactly the same in Mac OS just because you don't want to remember the difference. You don't want minimize and maximize buttons put on the opposite side of all other mac apps because that is how it is on windows. You don't want copy paste in Slack to use Ctrl rather than command key because that is what you do on Windows. 3) Whatever time you save from doing everything the same across platforms would be wasted, for anybody not working cross platform who suddenly have to deal with an app with completely non-standard alien behavior. I want my standard mac hot keys to work in a mac app. I want preferences to be in the standard location. I want my color and font selectors to work the way they work all other places. I want drag and drop to work like in all other Mac apps. We Mac users have seen this again and again. When companies don't give a shit about our platform, it is usually just a question of time before a competitor arrives which does, and knocks the other guy out. You don't survive that long ignoring the platform unless you got some lock-in advantage. Why else do you think people make a big point of an app being native Cocoa? It is because they know it sells better, because they know customers want the native well integrated experience.
- Touche 10y ago
  > 1) Why use several host platforms if the platform makes no difference to you? I don't, I use The Web for 90% of all things I use on a computer. A Chromebook is one of the computers I use the most when not working for precisely this reason. > Why else do you think people make a big point of an app being native Cocoa? It is because they know it sells better, because they know customers want the native well integrated experience. I think you're mistaken, the fact that so many company are switching to Electron is evidence that it doesn't sell better.
  - chipotle_coyote 10y ago
    I think you're mistaken, the fact that so many company are switching to Electron is evidence that it doesn't sell better. Hold on a bit with that assertion. First: which apps built on Electron are being sold, period? All the ones I'm aware of are open source, like Atom, or front ends to services, like Slack. Second: which companies are switching to Electron for development? Again, all the Electron apps I'm familiar with are ones that started out that way. While I'm sure there's probably an app or two out there that began as a native client and then went to "let's just be a web wrapper," I don't know of any big ones offhand. (I've come across companies that have shifted their strategy to using true native applications, however. Facebook famously shifted their mobile strategy from HTML5/JS to native apps some years back, and I know of several iOS apps that were using "write everything in JS, it'll be great!" toolkits that switched to actual native AppKit.) Third, and admittedly anecdotally, in both my experience and what I've consistently heard and read from people who've had the opportunity to study the UX of both native and "wrapped web" apps, just because users don't use the language of developers doesn't mean they don't notice when apps are slow, resource-hoggy, and behave kinda weirdly compared to other apps. I run a Slack for a writing group that's mostly populated by non-technical people and it is not uncommon for users to complain about Slack "slowing down their machine." Just because people don't know the term "native app" doesn't mean they aren't going to be able to tell "this app over here is nicer to use than that app over there," and that might be because "that app over there" doesn't minimize properly, or has weird menus that put common things in uncommon places, or doesn't do what they expect when they right-click on selected objects.

Etheryte 10y ago

> The underlying issue here is that Electron reduces the barrier to entry for cross-platform development. It's very far-fetched to call a lower barrier to entry an issue. The easier we can make it for people to get started, the better, isn't it?

matthewmacleod 10y ago
Point taken – 'issue' is not the correct term here. Perhaps 'cause' is better. Lowering the barrier to entry is great, I agree. It's awesome that Electron and web technologies can be used to quickly launch proof-of-concept desktop apps. I find it significantly less awesome that companies with hundreds or thousands of engineers continue to use it after the concept has been proven, however!
- cr0sh 10y ago
  But these apps aren't "proof-of-concept" apps - they are fully functioning, working cross-platform applications. So are you saying that these companies which have implemented these apps should instead say "You know what, we have this app developed, and working on the major platforms - but let's instead devote three new teams, one each for Windows, Mac, and Linux - to re-implement this app natively! I'm sure upper management will agree!" That's not going to work. That's going to be shot down and laughed at. No company is going to re-implement a working cross-platform application over to three separate native contexts, and maintain all three. That just won't happen. It works already. The users probably like it just fine. What benefit to the company will this get them? Nothing - just more costs for maintenance across three platforms. If native is wanted by the users, likely what would happen - if it happens at all - will be the company says "Ok - we'll make it native for Windows, maybe even Mac - maybe. Linux? Forget it!" It's not the developers. Developers would love to make native apps, for all the platforms. But developers are limited by the companies they work for, and by the economic realities that all the platforms can't be supported natively; at most, only one or two can - because at that point, with the number of users on those platforms, the additional costs of maintenance and support are pretty much saturated. Adding additional native platforms doesn't just add onto those costs, it actually (in theory) multiply them - because a single person might use the application across multiple platforms. So if they have problems on two or three different native platforms, now there are three different support issues (needing more people to support) - instead of a single complaint for a single platform. I get it, though - it would be great if these apps were native, and worked on every platform, from now and into the future (even on platforms that don't exist yet!). That's just not going to happen; if native is wanted, then only the most widely used platforms will be supported, and even then, one of those will likely be dropped, and it won't be the one from Redmond. So - what can be done? I dunno. The concept the author brings up ("use React Native") might be the solution. Or some other interface that abstracts a platform's OS and other native functionality out to an API that is the same for all platforms. But now you have issues with security and other access - which you still have with Electron, but it is more contained and constrained, since it has to go thru the Chrome engine and the various rules/settings browsers have for sandboxing bad actors. Or - you leave it to the user and their operating system (and slim it all down - maybe that's what React Native does; I don't know, I've never used it). Or - you (that is, the company) just says "Sure - we'll do a native only implementation - for Windows only." - because that's how it usually goes.

Veen 10y ago

What you call "trade-offs" appears to me to be developers externalizing their costs onto users. There are costs to developing desktop applications and developers don't want to pay them, so they make users pay for them in wasted hardware dollars, bandwidth, RAM, battery life, and poor integration.

wickedlogic 10y ago
Yes. You just described modern computing.
- sametmax 10y ago
  Computing for ever. We use C to avoid writing assembly. Use Java to avoid writing C. Use Python to avoid writing Java. The world is asking for more and more software, and the resources to provide it are not following so people are taking shortcuts. Want something better ? Someone has to pay for it.
  - cableshaft 10y ago
    Yeah, but Python still doesn't seem to have a great cross-platform desktop GUI, as far as I can find. I'd prefer to code entirely in Python if I could, but I haven't liked a single GUI library I've tried for Python. Although to be fair I haven't really tried PyQT out still, but I don't like the idea of having to buy a commercial license for it.
    - sametmax 10y ago
      PyQT is alright. Kivy as well. Or anything in any other language. But none of them are close enough to the benefit of being able to use the tone of experience from the Web UI into the desktop. Eventually all GUI app toolkit ends up with a custom MVC framework, a client/server architecture, some kind of db for persistence, their own implementation of asynchronous event and communication models and a declarative layer to create the UI without code. For the most advanced this layer separate structure and layout. Well guess what, this is what the Web has natively being doing for ever. Since the web is now the most popular platform, with millions of libs and tutorials on it, people just reused that. It just makes sense. The problem is not the concept. The problem is we should have driven this effort with a standard to sanely close the gap between the desktop and the web so that you don't have to spawn a freaking browser-engine-os for every one of your app. But no, the web is the only platform with a standard. And it flourished while all the big players created closes gardens with proprietary shitty API. And this is the result. Have you not seen Jurassic Park for god sake ? Life finds a way.

obstinate 10y ago

Can't say I agree. Native apps are often garbage. Discord is another Electron app that I think is actually quite a bit better in most dimensions (attractiveness, functionality, speed) than the native apps it replaces (Mumble, Teamspeak, Skype, etc.).

Cthulhu_ 10y ago
But is that due to technology choices, or due to more attention being paid to UX? (and I do believe webapps give more flexiblity in that regard) I get the feeling that UX and UI designers for web- and mobile apps are just a different breed than their native desktop equivalents. It might just be my Windows bias though, iirc Windows didn't have a strong / great UX guideline until their current one came around - and I haven't used many modern windows apps yet, the ones I do use are stuck in the 90's with their button bars and such.
- obstinate 10y ago
  It's never going to be possible to fully separate the factors out. With infinite time and effort by the exact same set of devs, I'm willing to grant that electron apps will be worse than native apps. But that hypothetical circumstance (same set of devs, infinite time and effort) does not exist in reality.
- mlsarecmg 10y ago
  That is due to the technologies available on the web being easily more suitable for GUI development than older native tools or desktop frameworks. We're in a similar boat, we made WPF apps. Now we're bringing it to the web and Electron. The things you can do now in React, heck i wouldn't even know where to begin in WPF or QT. If you look at modern Electron apps like Atom, VSCode, Discord and so on, the things they do and how flexible they are, this would mean so much hardship and pain in older solutions to the point where it's probably not viable any longer.
  - LeoNatan25 10y ago
    Other than declarative vs imperative, please substantiate your post with examples of what isn't possible in WPF or Cocoa. I have a feeling it's more of an experience / competency issue rather than lacking APIs.

throwaway2048 10y ago

In discussions like this its important to try to distinguish between a priori reasons and post hoc justifications. The real reason that parties like slack and spotify choose electron is because its easy for the devs they have that only really know JS/HTML. Its not that they couldnt hire more/different devs that could do it in a saner way, its not that its too expensive or that the ROI is not good, when we are talking about companies worth hundreds of millions to billions of dollars focusing on a core market, that is just completely laughable post hoc bullshit. Its that they dont give a shit, either about the user experience, or improving their toolset. They are happy where they are, and see no reason to change.

TuringTest 10y ago

If you basically agree with the parent post, why do you say it's nonsense? > The underlying issue here is that Electron reduces the barrier to entry for cross-platform development. Precisely. > The trade-off — and there is a trade-off — is that Electron applications are shite in comparison with proper native applications. But native applications are shite in terms of portability. > But let's be honest here – there is nothing preventing e.g. Spotify or Slack from building native clients for each platform they support See the part where the original post said "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". The costs may not be "prohibitive", but they certainly would multiply effort and resources, and divide profit.

aidenn0 10y ago
The "nonsense" part was that "nobody" was writing desktop apps for the past 5-10 years.
- nilliams 10y ago
  Well they were exaggerating but I think they had a point, til recently on my Desktop machines I only cared about having a web-browser, terminal (+ Steam at home). Lately there are more UI-ish apps I value having everywhere including desktop (Spotify, Hipchat, Whatsapp, VSCode). I'd also love a decent cross-plat podcasts app. I think it's clear there's now more demand for certain types of consumer-ish desktop apps (chat apps & music apps especially) than there was a few years ago.

rndmize 10y ago

> The underlying issue here is that Electron reduces the barrier to entry for cross-platform development. Actually, the incentive is even stronger than this. The ability to visit a website and start using an identical version of the app immediately is just as important - I doubt that Slack and Discord would have had half the success they did if users had to download the application before using it, regardless of them being available on all platforms. Discord has had the ability to give links to others to join a chat server since its inception, resulting in a two-step process to use it: click the link, type a name. This is miles less of a barrier to entry than: click link, download app, find downloads, install app, run app, create account, join server (rough process for most text/voice apps up to this point).

Cyph0n 10y ago
Most people I know just the app though. Heck, I actually only discovered the Discord web client yesterday.
mercer 10y ago
It's a difficult trade-off, even for me as a user. The fact that I can load Slack on all my devices and in the browser definitely played a role in my adoption of it. The fact that Slack is dog-slow and a memory-hog on my MacBook Air, on the other hand, has kept me from using it as a central part of my own work. Similarly, I am actively pushing everyone I communicate with the switch from WhatsApp to Telegram because the latter has a performant native app. If I were to build an app where cross-platform support was crucial, I'd probably start with Electron as well because of time and budget concerns, and switch to native if the app 'takes off'. But on the other hand, I can imagine there being serious risks to building out an entire platform that way and having to rebuild it from scratch later on. Maybe there's never budget/time for it, leaving me locked in? I suppose React Native could help in that regard.

bmpafa 10y ago

Bingo--half these diatribes against Electron just seem to be making the case for premature optimization.

Cthulhu_ 10y ago
Spotify, Slack and Atom are no longer hip startups though - they're established applications, and at least two of them have a very lucrative monthly subscription model. They can afford to optimize.
- yesimahuman 10y ago
  But the user experience is already great, so what's the gain? Electron and the web clearly make a first class app platform on desktop. EDIT: thanks for the downvotes. I'd love to hear your thoughts on how electron is keeping Slack and Spotify from building a massive business and how their desktop users find the experience so bad they don't use the tools obsessively. Clearly there are things to improve w/ Electron (energy usage), but "terrible experience" is not how I'd describe Spotify and Slack on desktop, and their businesses clearly reflect that. Moving to a native stack has major tradeoffs, would it 10x their business at least? I strongly believe that answer is "no."
  - josephg 10y ago
    Its a terrible experience to discover my battery life is cut in half because of a cursor animation in VS Code, or to have my laptop heat up and the fans engage because of an animated GIF in slack. But its worse than that - most users don't even know why their battery life is awful. So they blame apple, or microsoft, or dell or whoever. And they just don't use their computers as much, because its all a bit gross and slow. And thats bad news for our entire industry.
    - mlsarecmg 10y ago
      Hasn't it already been pointed out a thousand times now that this was just a bug in Chrome that has been fixed right away?

Cthulhu_ 10y ago

The cost argument is indeed a moot point - look at all of the major software companies, and you'll see that actual development is nowhere near their primary expense. They can afford to implement their own programming languages and OSes (and some do), but apparently it's too expensive or too difficult to make native apps for the respective platforms? This goes for mobile too.

deedubaya 10y ago
It's moot if you're an established company with deep pockets moving slowly. If you're starting from scratch with limited funds, it is definitely not a moot point. Would Slack have been as wildly successful if they had to implement native apps on all 3 platforms + iOS + Android + etc? I'd have a hard time believing so.
- deleted 10y ago
  [deleted]
- matthewmacleod 10y ago
  No, and that's fine. I don't think anyone is going to begrudge a small team the power of developing a 'desktop' application using cross-platform tools like that. It's great that the barrier to developing an application in that way is lowered. But that doesn't excuse the abuse of that platform. Spotify used to have a pretty convincing native Mac app, which was spiked in favour of their current abomination, and I've watched performance plummet. Using Electron as a cost-cutting measure is fine, but it's not good for user experience and it's OK to be honest about that.
  - srssays 10y ago
    Electron is great for user experience. Compare to something like JetBrains' IDEs which are written in Java and are much less native feeling than Atom (and just as resource-hungry).
    - bitwize 10y ago

Cthulhu_ 10y ago

The main challenge, I think is that all of those apps are cross-platform, but also want to keep the same look and feel on all platforms - they're using their own UX patterns inside the container which generally don't match up with their host OSes. There are some applications that do try so - 1password, GitHub for Mac/Windows to name a few that come to mind - but they seem to get less love than the cross-platform webapps. It feels like they get a certain amount of dev time before going to minimal maintenance mode.

xpaulbettsx 10y ago

Clarified my statement above re "nobody"

burnbabyburn 10y ago

isn't QT cross platform?! in my opinion this is an hiring problem, they assume that if you know javascript you can be spendable on more things and not only on the desktop to write an application.

spoiler 10y ago

Maybe I have the wrong impression, but I feel like the author of the original post never wrote anything cross platform that's sufficiently complex (ie, more than a "let's fill out a form and press OK" Qt app). > The trade-off — and there is a trade-off — is that Electron applications are shite in comparison with proper native applications. There's nothing inherently electron-specific that makes an app "shite" any more than writing one in Qt would. You can write shit in any language, framework or platform. The day someone invents a system that protects us from our own stupidity will be the day humans become obsolete. > They fail to integrate with the host platform, Untrue. You can—if you need to—integrate with the host platform by writing a native node module, however it becomes less cross-platform at this point. > they are slow, they hog memory and drink power. Yes web apps use a bit—sometimes considerably, depending on what you do—more memory, and a bit more CPU (and hence bettery), but they are not perceivably slower, unless you're doing something stupid (in which case the equivalent Qt app would probably suffer in the same way). > But let's be honest here – there is nothing preventing e.g. Spotify or Slack from building native clients for each platform they support, and I find it difficult to believe that the costs would be prohibitive. Maybe, maybe not. I think using a cross-platform solution wouldn't be ideal for them (they'd need to either rely on something like Qt, write their own rendering engine, or use something like SFML; all of these are overkill compared to Electron), and the alternative is writing it in different languages for each platform, which would probably inevitably cause the projects to get out of sync in one way or the other over time.

abdulkareemsn 10y ago
In article Author says he implemented user space usb driver for Chrome on Mac (guess what Chrome is cross platform)
- spoiler 10y ago
  Implementing a feature for macOS in Chromium is considered a cross platform project these days?

deleted 10y ago

[deleted]

treehau5 10y ago

> That's nonsense. Proper this and proper that, and don't get me wrong, I agree, but parent is correct -- and that is these apps wouldn't even exist if it wasn't for Electron. It just wouldn't have been a consideration for it to be a desktop app. Instead it would have just been thrown up on the web. For example VSCode would have just been some type of online IDE clone like Cloud9 or something similar. If you think this is nonsense, you are out of touch, and I don't mean this as an insult, although I realize there isn't a good way to say that.

_jal 10y ago
I think people are talking past each other. Yes. Electron enables some new stuff. New stuff that wouldn't exist otherwise. Yes. Electron is a bucket of bloat that saddles what should be small, simple apps with enormous amounts of crap that has nothing to do with the app's functionality. Both of these can be (and are) true.
- matthewmacleod 10y ago
  I think that's the real take-away here. There are upsides and downsides; I am pleased that it is easier to release desktop applications, but sad that the performance of them is so much worse. I wonder if one of the issues is that so many developers have now worked almost exclusively in the 'web' sphere, and aren't aware that native development maybe isn't as difficult as they think.
  - laythea 10y ago
    On the plus side, this is an ideal situation to take advantage of - by creating native and fast applications, it becomes easier (compared to before when everyone was doing it "the hard way") to distinguish your product in a bloated market.
    - nilliams 10y ago
      Not sure if ironic, seems a sure bet most users won't notice and gladly prefer the "bloated" product. Yet to hear a single non-dev coworker complain about Spotify being "bloated".

ballenf 10y ago

> ... Electron applications are shite in comparison with proper native applications. Is that true from a user's perspective? The average user I know would not have the idea that Slack is somehow inherently worse than say MS Word or any other truly native app they use everyday. What would Slack gain by integrating better with my Mac? Slack starts up too fast for me to read the little quotation (penultimate Macbook Pro). I actually wish it was slightly slower because I like those cheesy quotes when I can catch them. Everything feels almost instant. Not bash instant, but as fast as any mainstream messaging app. I leave it running all the time and get what feels like normal full hours upon hours of battery life. There are apps or browser tabs that I've noticed destroying battery life, but Slack nor Atom nor MS Visual code are on that list for me. The anti-Electron complaints all kind of feel like the same argument that comes up as each new layer of abstraction gains acceptance. I'm sure there's a lot that Electron can and should improve. Running multiple copies of Chrome does sound awful, but until I read that I didn't know the atrocities it was committing. Just doesn't feel productive to try to make Electron go away vs. working to improve it or create a better cross-platform abstraction.

brandon272 10y ago
Slack behaves perfectly fine for me and I don't have incredible hardware. It's non-Electron apps that are typically mentioned by macOS' energy management system as "consuming significant energy", in my experience. Edit: Mass downvotes; lol ... Just stating my personal experience!
_jal 10y ago
> Is that true from a user's perspective? It is for this user. > What would Slack gain by integrating better with my Mac? Far better resource management, one would hope, for starters. As the article pointed out, when you're measuring your IRC client's memory use in hundreds of megs, there's a problem. It isn't uncommon for me to need to choose which "essential" apps to turn off to get something done on a maxed-out MBP. So Slack gets turned off, and maybe someone gets annoyed that I don't respond to something, while I run a few VMs in Slack's former memory space. As far as other things, well, using a platform's capabilities as appropriate is generally considered good form - HCI concerns, and, generally, just people like things to be consistent. I don't know why we're supposed to forget this now. I personally don't care if Electron goes away or what, but to the extent that I'm forced to run Slack by my cow-orkers' choices, it sure would be nice if it were less of a bucket of ass.

deleted 10y ago

[deleted]

roryisok 10y ago

This issue is so furiously divisive, and I feel like it brings out the worst in HN. I'm from a web dev background. Some of the comments here make me feel like I should be ashamed of that fact. I can see both sides of this argument (every time it comes up) As a consumer of apps, I want the leanest, most minimalist, fastest thing going. I want native apps on my devices (If you think slack is a hog on the desktop you should try it on Windows Phone). But as a developer, I know that electron is a shortcut that means my app will take less time to build. I can take my existing skills, take work I've already done on a WinJS app and publish it on Mac OS, Linux and Win 7. I can spend more time with my family, instead of spending all my evenings learning py+qt, or xamarin, or react native, or whatever the new fangled thing is. And I know people will use it. Hell, I've even got better odds of pushing an electron app than a native one, as I can submit a pull request and maybe have it appear on https://electron.atom.io/ https://electron.atom.io/ Obviously, seeing the Electron hate always gives me pause for thought, but at the end of the day it feels like the hatred is from fellow coders (if a dribbling front-end-js writing low-life such as myself can call you writing-assembly-on-a-napkin-while-you-quote-stallman-types fellow coders) and my apps user-base is overwhelmingly non-technical.

pseudalopex 10y ago
Your non-technical users are capable of noticing that a certain application makes their computer slow or drains their battery or doesn't support a certain feature of their platform. It may take them longer to notice, and they won't know why, but that won't stop them from switching if a better alternative comes along. Delivering high-quality web apps generally requires knowing JavaScript and CSS. Delivering high-quality desktop apps generally requires knowing the tools of that ecosystem. Sometimes we compromise to get things out the door, but we should be honest with ourselves when we do.
- roryisok 10y ago
  I'm honest with myself. I'm not disputing that Electron is not the most optimal way to create a desktop app, I'm saying that it makes desktop development (particularly cross-platform development) faster and easier. I know I could make a more efficient app by going native. And hopefully in time, I will. But for the sake of getting it out the door I'll most likely go the Electron route.

Tloewald 10y ago

Electron is like almost any other cross-platform VM, including Java (which is living under most of the "native" apps on the world's most popular platform), .NET, and so forth. It doesn't share resources between instances but then you also don't get dependency hell (wrong version of Java for application X, etc.) Subjectively, I'd say that Electron's performance overheads are not bad compared to, say, Smalltalk in the 90s, where one Smalltalk application could bring a fully loaded state of the art workstation to its knees. And don't get me started about Flash. I had a whole project cancelled after an engineeer brought up the CPU meter during a fairly simple animation.

BatFastard 10y ago
There are always bad engineers. I can write a shitty function in any language.
- Tloewald 10y ago
  I've never seen anything performant built on top of Smalltalk, including the Xerox Star's built in apps which were developed by universally acknowledged geniuses. Flash's performance issues were legion. Chrome is widely considered the best current desktop browser in a very competitive space. If it has problems it's definitely in idle power consumption (which indicates wasted idle CPU) but it is used by a hell of a lot of people who have free alternatives.

newhere420 10y ago

> Electron applications are shite in comparison with proper native applications. They fail to integrate with the host platform, they are slow, they hog memory and drink power. Are they though? The two applications that use the most energy on my Mac - by far - are Steam and Skype. Steam still has trouble with HiDPI and freezes when performing various UI interactions. The number of problems with Skype are uncountable. I'm currently booted into Windows for work, looking at my current process stats, the top memory consumers are: * Visual Studio (hodge podge of all kinds of things, 800MB) * Chrome (215MB) * Microsoft Intune (presumably native, 114MB) * GitHub (.NET WPF application, 108MB) * Explorer (native, 103MB) * Search Indexer (native, 107MB) * Lync (who knows, 98MB) Meanwhile, the supposedly terrible Electron apps: * Spotify - 58MB * Slack - 93MB * VS Code - 60MB As far as interfaces go, Spotify, Slack and VS Code easily outclass GitHub, Visual Studio, Explorer and Lync in usability.

frik 10y ago
Steam always used a HTML renderer, even in its 2006 first incarnation. Nowadays it uses the same CEF (chrome library) as electron uses. So Steam was one of the first "Electron" apps. A very first one was Windows Explorer as of Shell update that came with Internet Explorer for Windows 95 (included by default in Win98). All the sidebars of Explorer were HTML based.
- gant 10y ago
  No, VGUI is not HTML. Here's a fun one. Start Steam with `-dev` and hit F7. Widget factory VGUI edition! Oh also, https://developer.valvesoftware.com/wiki/VGUI_Documentation https://developer.valvesoftware.com/wiki/VGUI_Documentation
  - frik 10y ago
    Have I talked about VGUI? No. Valve used a very ubscure/niche HTML render engine initially for Steam (2006). The company/website behind that isn't online anymore. An older version of the Wiki had some brief info, but all these info vanished.

jrochkind1 10y ago

Not just cross-platform, I think it significantly reduces the barrier to entry (and total cost of your app) even for single platform.

signal11 10y ago

OneNote is a great example. It has fairly well-regarded native apps for each platform it supports, _and_ a decent web (HTML5) interface. I think the issue is time and resources. Small teams, like Slack, would like to create a slick experience but they don't have the time. Companies like Facebook went the other route -- HTML5 on mobile, got their fingers burnt, and went all-in on native. StackOverflow's iOS app appears to have improved a lot too, in v1 it was a thin shell around the web interface. I hope React Native catches on. I'm not a huge fan of how 'heavy' Electron is myself.

thiht 10y ago
Facebook's HTML5 app was 5 years ago, this example comes every time but it's outdated. technologies like Electron or React Native didn't even exist at the time. 5 years is huge when it comes to web technologies.

psyc 10y ago

This reminds me of what's happened with Unity (the game engine). There's a completely false perception that Unity is eating other engines' lunch. It isn't. All that happening is that game development has been democratized on an absolutely massive scale. So more games are being made. Most of them are bad. Most of the best games are made with either Unreal, or much more commonly, proprietary C++/asm engines.

deleted 10y ago

[deleted]

deleted 10y ago

[deleted]

username223 10y ago

Those who forget desktop Java will be doomed to repeat it. For those of you who aren't old enough to have been around, Sun initially pushed Java as a "write once, run everywhere" GUI language. It quickly became clear that Java applications were ugly and terrible everywhere, even in the primitive days of X11R5, when programs used a mixture of Xt, Motif, Qt, GTK, and raw X11 protocol (xv was awesome). Having a Java program for some task was worse than having no program at all, since it would discourage someone from writing a decent native solution. Fortunately Sun found ways to make money using Java server-side, and Apple helped kill it client-side by not providing it by default.

emj 10y ago
I would like to offer http://openstreetmap.org http://openstreetmap.org as a counter example, where the best editing app is made in Java and the most used one is Javascript. There have been QT4 editors but they have never gained traction, I never found the problem to be performance between native and Java. I think Javas problem was it's Unix engineering roots, with too little focus on UI, and perhaps a little too much of the "we don't care about performance"-mindshare. The latter being the only problem I see with some electron apps.

shalmanese 10y ago

Facebook still has not made any desktop apps available, leading me to rely on a hodgepodge of 3rd party, electron-esque shells to provide a desktop experience. This is despite their mobile apps being the most minutes used apps of any company. Even then, they tried to go with a electron-esque approach and only backed off when the performance and UX tradeoffs became unacceptable. If one of the most profitable companies in the world can't see the business case for supporting a first party desktop ecosystem, it's very hard to believe many other companies have the justification. This isn't an engineering problem, it's a business problem.

ender89 10y ago

They don't. Java apps have been cross platform since their inception, .net is extremely close to being just as versatile, x11 is available on mac and pc, and python will run on literally anything. There's a pile of cross-platform options out there for you. What electron does is reduce the barrier to designing UIs, since you can do it all in html and javascript and its just as easy as hiring the guys who did your website to design. Because the one thing all those platforms have in common? Aside from .net (which isn't mature), they all have absolutely hideous windowing systems. Just ugly.