16 ms·

Electron considered harmful

159 points by kragniz 10y ago

cdnsteve 10y ago
If electron apps had a smarter way to manage chrome core as a dependency, the file size would be peanuts. Every apps is download on the same bundled core. Once this happens you won't have 100mb sizes. An intelligent installer could check core, if not installed download and install otherwise use what's on the system.
- Longhanks 10y ago
  What if there was a centralized way of accessing HTML + CSS + JS applications? Instead of installing apps, you could just... "download" the necessary files to execute them? Perhaps even on demand from centralized.. "servers"?
  - detaro 10y ago
    I really don't want APIs to freely access the filesystem, other processes etc in my browser. And my applications to work offline. I haven't seen many examples of people using Electron to make applications that really should be web apps instead, but more for packaging web apps with native enhancements. Often I'd prefer a "proper" native app, pushing even more features in the browser IHMO is not the answer.
    - tscs37 10y ago
      >I really don't want APIs to freely access the filesystem, other processes etc in my browser. And my applications to work offline. Ctrl+S -> Save whole webpage alternatively get the Webpages source code.
  - josho 10y ago
    > What if there was a centralized way of accessing HTML + CSS + JS applications There is. The major OSs provide APIs to access the platform browser. The downside is you need a platform specific shim to set this up using native code. So, developers need to step outside of their JS worldview for a few days to avoid that 200mb app size penalty. If you are building a platform agnostic app then I understand the value of Electron to avoid that work across each platform. But, it seems several of those Electron apps aren't even platform agnostic, so why not build the platform specific shim and be a better citizen on my hardware. edit: I'm daft
    - mnx 10y ago
      He was ironically talking about the web.
  - nmca 10y ago
    Aha, he missed the joke...
- jasonjayr 10y ago
  For YEARS I remember having to chase down the VBRUN{100|200|300}.dll runtimes for the Visual Basic runtimes. Now that internet is everywhere, couldn't Electron: 1) Setup a common bootstrap mechanism so it's version agnostic 2) Check for the declared version of the app 3) If online (and allowed by system policy) check if there are security issues, or updates for the needed version 4) Advise user where to download the update, or (again, if allowed by policy) allow the user the proceed with the installation? With some magic to allow a 'side-by-side' distribution of the Electron runtime, on good-ol' durable media, wouldn't this go far to minimize the size of the distributions of these Electron apps? You could have a system with one (or more if nessecary) versions of the runtime, and multiple apps using that runtime (with isolated profiles, of course ...)
- RandomOpinion 10y ago
  >If electron apps had a smarter way to manage chrome core as a dependency, the file size would be peanuts. Every apps is download on the same bundled core. Once this happens you won't have 100mb sizes. An intelligent installer could check core, if not installed download and install otherwise use what's on the system. Oooh, we could give this core a snazzy name like "Flash" or "Silverlight" or something too. Once again, history repeats itself.
- ssivark 10y ago
  Isn't that what they call a web browser? For visiting websites and using web apps.
K0nserv 10y ago
I think the points raised are solid, but at this point it seems like Electron is the best worst solution for cross platform UI. Having worked with Qt I never wanna do that again. There's also a much more significant portion of developers who can work on Electron based apps. Part of picking the best tool for the job involves considering maintainability and ease of development after all.
- santaclaus 10y ago
  > Having worked with Qt I never wanna do that again. I've had to work on PyQt5 at work, and was pleasantly surprised out how easy it was to hack up a full app.
- witty_username 10y ago
  What are your problems with Qt? I was using PyQt, and I found it nice (Qt's integration is good).
  - K0nserv 10y ago
    I was using C++ Qt. Just found it really unintuitive and difficult to use compared to web technologies and native macOS development.
    - witty_username 10y ago
      Could you give an example of something that was unintuitive or difficult to use?
  - freeone3000 10y ago
    C++ Qt, I've found, is an entire separate beast. It goes out of its way to not rely on the STL, so that std::string and QString are separate, non-convertible classes. QList and std::list<> are the same, same for QMap and so on and so forth. So data communication is already a pain. We then have further issues with function invocation. Slots and sockets are simple with python, because functions are first-class in python. In C++, they are very much not, so slot-socket binding looks like: connect(sender, SIGNAL (valueChanged(QString,QString)), receiver, SLOT (updateValue(QString)) ); This is less than ideal.
deleted 10y ago
[deleted]
jules 10y ago
This article makes a good point, but what's the alternative? There is no good cross-platform GUI solution. Qt, GTK, JavaFx, wxWidgets, none of them are very good. Electron at least has the advantage of being fully cross-platform and not having to learn a whole new universe if you're already familiar with the web.
- qwertyuiop924 10y ago
  >There is no good cross-platform GUI solution. TTK. That is all.
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]
- lambda 10y ago
  For cross-platform apps, Qt is the best I've used. But it does have its warts, and it is big, it will probably bloat your app by about as much as Electron does. But yeah, there's no one clear winner, which means that Electron is not a uniquely bad choice. Sure, it might be a little heavyweight for a really small simple app, and if you're not aiming for something cross platform your native widget toolkit might be a better idea.
dexwiz 10y ago
Electron, and to a great extent the cross platform fetish, is a perversion of DRY. They don't want to write the same code for two platforms. But its usually not the same code. Its the same logic implemented on two different platforms. Developers are so into code sharing, write once run everywhere, that they don't stop and ask if they should. In every case you are paying a price for abstraction, like running Electron or using a WebGL canvas instead of a native graphics API. The article highlights cases where they price was paid, but the app was still platform specific.
- TeMPOraL 10y ago
  Well, it's the same logic - so almost by definition it should be platform-independent. People are too lazy to introduce proper abstraction between what the application does and what it shows on screen, and suddenly porting is hell. Either way, Electron sucks because it ships a whole goddamn browser to give you just portability; you have to still pile on a ton of JS and CSS hacks to get a decent-looking SPA UI out of it, which you'd get for free with any proper GUI runtime. All that waste because people want to write JavaScript (which I understand - I have my favourite language I'd love to write more too) and this was the most brute-force way to allow it. Embed a system webview if you must, don't ship the goddamn browser!
- sdegutis 10y ago
  Cross platform is a perfectly fine goal. Why should a developer care need to write `open()` on one system and `OpenFile()` on another, when all they really mean is "open this file" with the exact same semantics? That said, I think electron is overkill from a technical standpoint, and ultimately is probably too harsh on hardware, but I've given up caring about that in the short term, because there are bigger problems with how our stupid computers are implemented.
- jeremiep 10y ago
  This makes no sense and completely disregards context. There are perfectly valid use cases for Electron, and they have absolutely nothing to do with what you said. There are also insane amounts of cross-platform native code written on platform abstractions layers. > Developers are so into code sharing, write once run everywhere, that they don't stop and ask if they should. Isn't that the very purpose of Qt or GTK which the article is promoting instead of Electron?
niftich 10y ago
This had me for the first half, where the author walks you through the 'case study' applications that offer minimal functionality despite shipping with an entire browser inside. But then the essay turns into a rant. It's 2016, people, the ship has sailed on pretending JS isn't a real programming language. Phrasing the argument the way he does just betrays his smug elitism. The fact is, for many types of applications, Electron is a really good fit: for example, shipping a single-page webapp as a desktop app, a need that surfaces often in today's world, despite his derision of this concept. An Electron-wrapped SPA is safer than going to the same website in a multi-tabbed browser and co-mingling your disparate cookies in the same jar, not to mention more convenient for the users, because they can treat it like any other desktop application -- with hardware access, and subject to the OS' native task management. For other apps, Electron allows the world's most popular layout system (HTML+CSS) to be used with one of the world's most popular programming languages. This is a huge boon for re-using knowledge, and perhaps does lead to some amateurish projects. Similar criticisms were leveled towards Visual Basic, where drag-and-drop composing and a good IDE enabled people to quickly crank out a GUI app from an idea.
- ivan_gammel 10y ago
  >Electron allows the world's most popular layout system (HTML+CSS) to be used with one of the world's most popular programming languages Just wanted to name the most obvious alternative: embedded browser component like QtWebKit, which allows to code most of the application logic on the language of your choice. Embedded browsers are the way people have been doing it since circa 2000 (by then, Windows was dominating platform and you could use embedded IE for rendering - the typical app size was much smaller than 200 Mb btw). I remember earning some money on a side project around that time - the CD catalog of bathroom equipment, which I implemented by borrowing huge part of my customer's website and embedding it in CBuilder app with few improvements for richer UX.
  - mateuszf 10y ago
    But then you can't share the same code between your web application and desktop application. As a company you would have to pay two separate teams to develop each - developer time is expensive. Yes - electron apps are slower and eat more ram - but someone else is paying for that.
striking 10y ago
See, I totally agree with this essay. But what are the alternatives? Getting started with Qt/GTK isn't nearly as easy, for example. Maybe someone should write an intro to native GUI programming for JS devs.
- ld00d 10y ago
  What's wrong with JavaFX? I don't ever see it recommended, but a lot of us can do Java, and from my experience, it's way better than swing or awt.
  - TeMPOraL 10y ago
    I'd say nothing. If you're working on JVM, it's the best choice.
  - niftich 10y ago
    JavaFX is fairly decent, and I agree that it's more pleasant than Swing or AWT. It's a fairly good choice for places where you can mandate or ensure that Java will be present on the client (e.g. internal line-of-business apps), but also in places where you don't need to have some ancient version to support some ancient application instead -- which cuts down on the pool a bit. Unfortunately, most users know Java from years ago and never understood the difference between an applet or desktop application, and in the minds of some users it's still falsely stereotyped as slow or insecure. In most shops I know, Java is being extensively used on the back-end, but almost no custom Java apps with GUIs. Most shops (and people) who could do Java on the frontend have gone to learn Mono or WinForms or WPF instead, which gives you results that feel nicer to most users.
  - antihero 10y ago
    Purely out of interest, because I might have used one without even realising it, but could you link some desktop applications written in Java that haven't been sluggish as hell or a bit broken feeling?
    - ld00d 10y ago
k__ 10y ago
OT: what's the difference between Electron and Electrode?
- Shengbo 10y ago
  Electron is a cross-platform desktop framework based on a web stack. http://electron.atom.io/ http://electron.atom.io/
  - k__ 10y ago
    How does it compare to https://github.com/electrode-io https://github.com/electrode-io
    - detaro 10y ago
      Electrode seems to be for "normal" web sites/web apps, Electron is for packaging HTML+JS as desktop apps.
      - k__ 10y ago
        Okay, thanks.
    - Shengbo 10y ago
      Sorry, I assumed you were already familiar with electrode. As detaro says, it's for web apps, not desktop ones. Afaik its mostly boilerplate for node+react.
      - k__ 10y ago
        I see, thank you :)
bhouston 10y ago
There are a lot of shitty half working apps, and there always will be.
vvanders 10y ago
As some of who's had to support Qt, wxWidgets and other crazy x-platform UIs I find electron refreshing. Heck, I've got Rust talking to node.js in it. Elm for the front-end and Rust for the processing, it's a surprisingly pleasant development experience.
- nmca 10y ago
  Hey, is this open source? Sounds very cool. If not, can you point me towards any open source apps that are using a similar approach?
  - vvanders 10y ago
    Not yet but it will be once it's a little further along. Rust -> Node -> Rust is pretty simple, just expose a c api and wrap it with node-ffi. Then I have the main thread piping messages over to the relevant windows straight into Elm ports. Nice bit is you can pass callbacks into Rust that calls js via c function pointers. Saves a ton of time marshaling data and is more efficient.
mikewhy 10y ago
Another example of "'____ considered harmful' considered harmful".
- pluma 10y ago
  Eric Meyer put it best, I think. Time for a repost: https://news.ycombinator.com/item?id=13031883 https://news.ycombinator.com/item?id=13031883
traviswingo 10y ago
I can understand the author's frustration with popular tools being very simple and somewhat overkill underneath, but I almost take it as a sense of frustration with himself. Electron was built to ship products as soon as possible. Most of the time, no one gives a flying fuck if the tech stack is the "right" choice and as efficient as it can be. I'd be willing to bet my net worth your users don't care at all how you built it, just that it does what they want it to do. In the end, for most companies, it's more about shipping product that sells than spending 5x more time writing it in C# because "you're an engineer so you should act like an engineer." That's not how the world works. And until you figure that out, you'll constantly be left behind by others who made compromises to capitalize on the market. Early optimization is the root of all evil.
- StavrosK 10y ago
  > I'd be willing to bet my net worth your users don't care at all how you built it, just that it does what they want it to do. That's exactly right, except "what I want it to do" is not use up all my RAM.
  - traviswingo 10y ago
    Yeah...I could do without the RAM munchers.
- ethbro 10y ago
  This is both true, but also makes me weep for the state of software development. (Specifically, performance and security)
  - traviswingo 10y ago
    I concur in that performance and security are very important in building software. I would, however, opt for a less performant version of a product if that means releasing it a couple months earlier than the alternative. I think it's possible to build very well performing applications on a tool like Electron, and once the market has proven that your product is in heavy demand, then you can re-approach it and decide to go native or revamp it using some lower level tools.
sergiotapia 10y ago
I look at Electron apps the same way I used to look at Adobe Air apps. Any League of Legends player knows how bad the launcher is - 80% the fault of Adobe Air. Sure it was easier to build, but your users suffer for it. Electron apps are pretty terrible performance wise, and you can immediately tell it's an Electron app. - Atom - Slack - GitKraken All of these apps have 'tells'.
- chacham15 10y ago
  And yet the League of Legends client was rewritten from AIR to HTML+JS on top of Chromium...
- csydas 10y ago
  While I agree with you that the old League launcher was just trash, I am mildly impressed how long it has lasted and worked for Riot. As much fun as it is to make fun of Riot's spaghetti code, they did a decent job with the Air Client, far more than I would have expected before I knew it was Air.
- jeremiep 10y ago
  Electron apps have exactly the same performance as web apps, which is what its aimed at. Badly performing code can be written in any language; you'd be surprised at how much mediocre C++ code is running on your desktop. You're also running insane amounts of mediocre C# applications. Comparing Electron to AIR makes no sense, they're radically different runtimes with radically different ecosystems. AIR stands alone while Electron reuses the web stack already used by millions of developers. I find it rather elitist to dismiss Electron apps as "easier" to build or having users suffer. Thats completely false and grossly overlooks the context in which these apps were built. This is the kind of comment you'd expect from a beginner without much experience wanting everything to be in his favourite language.
- oldsj 10y ago
  Yea but look at VSCode, definitely an exception to this. The feel of code vs atom is night and day to me.
  - 10y ago
baybal2 10y ago
what is electron?
- witty_username 10y ago
  Downvoted; this question can easily be answered via a search engine.
  - deleted 10y ago
    [deleted]
  - FullMtlAlcoholc 10y ago
    Downvoted. It's generally considered rude to expend more effort being snarky than answering a simple question. To the parent: Electron is a framework for building cross-platform desktop apps with HTML CSS and JavaScript in an embedded chrome browsers/node.js environment. More info here: http://electron.atom.io http://electron.atom.io
    - witty_username 10y ago
      How would I say my message without being snarky?
      - FullMtlAlcoholc 10y ago
        If all I can add to a discussion is "Just google it", I just won't respond. For better or for worse, people aren't going to respond by saying 'By golly, you're right! I'm so lazy, but from now on, I will google stuff first instead of asking questions." They're just going to say basically "What an asshole, fuck this guy. Maybe he wants an answer that is curated and summarized by a human, not a litany of links where you don't know what to focus on. For example, when I asked what dependency injection is, some kind stranger responded "It's a million dollar term for a 5 cent concept. Pass objects as arguments to functions instead of instantiating them inside." Of course, this is a limited definition, but it was put into layman's terms and it answered my question. From that answer, I was able to really learn what it was instead of being stuck on phase 1 of understanding. When you're online, it's much easier to come off as a dick than it is in person so what I try to do is imagine someone coming up to me earnestly and genuinely asking the same question and respond thusly. Accordingly, when I know I'm asking a simple question, I add self-deprecation to the beginning. Example: "I have the technical and programming acumen of a bag of rocks, so excuse my elementary question, but..."
baby 10y ago
Yeah no. Electron is fine to write desktop apps. I've seen native app with more ugly UIs and being laggy, etc... For many apps Electron is fine and will perform as well, or even better than native apps (just because, developers you know).
adamnemecek 10y ago
I dislike JS just as much as the next guy but the only real contender on the list is Qt. Which you need to license for commercial development. Furthermore, even though I like to think that I'm ok in C++, I would really think twice before using it on my next project these days. The JS performance issues should go away for the most part when wasm is standard. Also a lot of people write some compile to JS language, not JS, so I think that most of the points of this blog will be rendered moot in the near future.
- falcolas 10y ago
  If you're doing commercial development, why is a license (and the attendant support) a big deal? Its cost in relation to that of your developers is neglegable. Or is the cost of the license really that prohibitive for a well supported and performant piece of software? [EDIT]: I found the pricing after a bit of creative googling: Startups is about $1,000 a year, non-startups are about $3,500 a year. Even without the discount, that's roughly equivalent to a month of one developer's time. IMO, not a terrible deal, for something you can freely license and use for cross platform development.
- witty_username 10y ago
  Qt is LGPL, you don't need to share your application code; you only need to share Qt's code (which only matters if you modify Qt). (not legal advice; I'm not completely sure about this) > The LGPL allows you to keep the source code of your application private as long as it is “work that uses” the library. Dynamic linking is usually recommended here.
jmlucjav 10y ago
I have been wondering...does Slack freeze for like a couple of minutes a couple of days a day for someone else? I am on win10, on pretty hefty machines. No idea if it's because Electron or something else, but it's really annoying. I could not find any trace of issues in the event viewer etc.
- r618 10y ago
  Yes it does for me, too / win 10, too /; I _think_ it is connected to @mention of my nick
seanwilson 10y ago
> For the love of God, learn something else. Learn how to use GTK or Qt. Maybe Xwt is more up your alley. How about GNOME’s Vala thing? Learn another programming language. Learn Python or C/C++ or C#. All of this takes time. If you want to launch an app on multiple platforms, Electron is a very time efficient way to do this. Obviously native apps for every platform would be ideal but not everyone has the resources for that. > Let me be clear about this: JavaScript sucks. It’s not the worst, but it’s also not by any means good. ES6 is a really great step forward and I’m thrilled about how much easier it’s going to be to write JavaScript, but it’s still JavaScript underneath the syntactic sugar. Use something like Typescript or Flow then. The above is like saying C++ sucks because assembly is a bad language to code in.
stevebmark 10y ago
"If you want to make a quick little app, instead of using something convenient that you know, you should learn a REAL language like C" Why is this garbage on the front page? Stop giving condescending people like this a platform.
nailer 10y ago
> For the price of 200 extra MiB of disk space and an entire Chromium process in RAM and on your CPU, you get a less capable GUI that saves you from having to type the -ss and -t flags yourself. Cool. I remember when Handbrake first came out, and 'make video go on iPod' went from some long winder research into ffmpeg flags to clicking a button that says 'output for iPod' [1]. This sounds similarly timesaving. [1]. yes, iPod. Showing my age.
- q3k 10y ago
  >[1]. yes, iPod. Showing my age. That was, what, 9 years ago? I realize it's an eternity in the average JS framework lifecycle timeframe, but come on.
- deleted 10y ago
  [deleted]
burai 10y ago
Well, that was a waste of time, the article is more a rant than anything else. I can understand that some piece of technology will not like everybody, but not spending any time giving proper alternatives. Not to mention that the header seems click bait since it's an opinion article, not an actual security risk.
calebm 10y ago
Just because a particular technology is not the "right" tool for every job doesn't make it harmful...
api 10y ago
The only viable alternative is Qt, and it is almost as big and offers a less familiar programming model. Native is only an option if you want to rebuild your app UI from scratch a minimum of twice and never support Linux or other less common desktops. UI development has always been in fragmentation hell.
NelsonMinar 10y ago
Stupid essay is stupid, but I'm glad it pointed me to lossless-cut because that tool is great! The author completely misses the point of Chromium in berating lossless-cut for being "a graphical UI for two ffmpeg flags". Yes, exactly, it's a GUI that lets you cut video to the precise frame you want to. That exactly solves a problem I've had for a long time; I've been using a horrible ffmpeg command line alias (along with preview in VLC) for a year now. He's a little right about "It doesn’t even use ffmpeg to decode the video preview in the app"; that would be useful for supporting weird formats that Chromium doesn't. But for common formats lossless-cut is great. It's at https://github.com/mifi/lossless-cut https://github.com/mifi/lossless-cut
yoavm 10y ago
While I agree with his general idea that Electron is usually not the best tool for the job, I think he's overestimating JS as the reason that people choose Electron. It's not because of JS, it's because of HTML and CSS, which aren't that bad comparing to other tools we have (especially since Flexbox). I think most people would love to write desktop apps using HTML and CSS, while using anything other than JS to do the logic. We're just... not there yet.
jeremiep 10y ago
I can't help but feel as if the author can't make the distinction between a platform and the software written for it. People have been misusing platforms ever since they existed. Its not because someone used Electron to build a console that Electron is bad in and of itself, it just means someone used the wrong tool for that specific job - or maybe that fitted all their requirements in which cause the author is just dismissing the work with no clue about its context. I also can't help but feel as if the author is a beginner developer lacking a huge amount of context and experience. Saying "Electron enables lazy developers to write garbage" displays a huge misconception about software development in the very first place - garbage will be written no matter the language or platform. Alls the article did was remind me that those who can, do, and those who can't, blog.
- nycatelos 10y ago
  And those who really can't post snarky comments on HN.
bmpafa 10y ago
This article, like many similar to it, makes the (imo flawed) assumption that a dev tool ought to be evaluated on only a few variables--e.g., code quality, performance, package size. If writing software is about making users' lives easier, happier, or better, though, I think we ought to optimize for that and that alone. I say let the market and communities of users decide which software they want to use. I use Nylas b/c I like the UX better than Ubuntu's Evolution, despite its flaws. I use Caret (electron markdown editor) because I wanted a cross-platform tool and I have > 4 gigs of ram. Hell, millions still use the Facebook Android app, despite the fact that it sucks down battery juice like your crazy uncle sucks down Miller Genuine Drafts before lecturing you on how terrible millennials are (happy Thanksgiving, btw). Of course, it's important we know the trade-offs of the decisions we make, so we need critical pieces like this. But to be as prescriptive as this article is to miss the forest for the trees. Love it or not, JS is a point of entry for a hell of a lot more ppl than C++ is, so expanding its reach into new arenas is not only net-good, but I'd argue also inevitable. That said, the article does skirt an issue I've thought about a little, and I'm interested to hear others' takes. If software collectively moves more towards higher-end systems, e.g., with SPAs and electron apps and all their cpu-intensive renders, are we further limiting a great web UX to those with the money to afford the latest laptops? We spend a lot of time thinking about accessibility standards for our products (A11Y, etc.), but when should we begin to think about accessibility from a socioeconomic perspective? Or are performant computers now so accessible that we needn't worry?
- rootlocus 10y ago
  > If writing software is about making users' lives easier, happier, or better, though, I think we ought to optimize for that and that alone. That's (imo) your flawed assumption. And no, just choosing electron won't make your users happier. > Love it or not, JS is a point of entry for a hell of a lot more ppl than C++ is C++ is not the only alternative. And considering the staggering amount of frameworks and tools one must learn to get started with JS other alternatives are actually easier. Unfortunately, not as cool. > That said, the article does skirt an issue I've thought about a little, and I'm interested to hear others' takes. Is this a joke? I had to google what skirt means: "attempt to ignore; avoid dealing with." That's the exact opposite of what the article does. Let me quote it for you: About electron: "One of the slowest, least memory efficient [...]" About terminal: "They’ve taken one of the most lightweight and essential tools on your computer and bloated it by orders of magnitude. " About lossless-cut: "For the price of 200 extra MiB of disk space and an entire Chromium process in RAM and on your CPU [..]" The conclusion that "people will require more money to buy more hardware to run bloated software" is not something only you thought about, it's only one step away from what the article says. And it's actually hilarious (read: infuriating) that you don't see the problem with that way of thinking. NASA put people on the moon with computers less powerful than a mobile phone. The article criticizes people who write bloated software, but you argue it's fine, because users are happy. Then you go on wondering if it's a problem that users won't afford the latest laptops to run bloated software. WAT?
qwertyuiop924 10y ago
sigh First off, JS is a perfectly usable language. In some respects, it's even great: of the "big three" scripting languages (Python/Ruby/JS), it's the only one that got Lambdas right, and also got closures right (unlike, say, Python). It has sometimes-quirky syntax, and some odd semantics, but they don't bite as often as you'd think. Second off, I would say that this article is right about the bulk of Electron: It's a pretty massive thing to lug around with your app, and not ideal in any sense. However, if you want to build a UI very fast, there is nothing better than HTML/CSS for it. Except maybe TK. Speaking of TK, I would actually advocate TK over Electron: it's easy to use, has bindings to pretty much every language out there, and with TTK, it doesn't look like crap. Finally, "considered harmful" essays rarely do any good, and frequently do harm. So yes, while I usually like Drew's writing (at least a little: he's good, but far from the best), I wish he had spent the time he spent writing this doing more work on SCAS. Seriously. If SCAS was actually done, and documented, and usable, that would be great. There is a freaking vacuum of good assemblers for the platform: another one would be nice.
- MereInterest 10y ago
  Now I'm curious. What would you say is wrong with python closures? Asking because they feel natural to me, and I haven't run into anything irritating about them. (As opposed to lambdas, which are really annoying and restricted in Python.)
  - qwertyuiop924 10y ago
    It's not as bad as I thought, but Python doesn't actually have lexical scope, not really. But the LEGB rules mean that it should still work as you expect.
    - TJSomething 10y ago
      It does if you're using Python 3, which has the nonlocal keyword for lexical scope.
      - 10y ago
deleted 10y ago
[deleted]
lopatin 10y ago
This guy is doing his best to make sure we can't have nice things. > We use [JS] because we have no choice (people who know more than just JavaScript know this). The object model is whack and the loose typing is whack and the DOM is super whack. Moot point. I use React + TypeScript. Good types and barely ever work with the DOM. If you don't like TypeScript, your favorite programming language probably compiles to JS anyways. > The reason people choose Electron is because they are too lazy to learn the right tools for the job. This is the worst quality a developer can have. I agree that bundling a copy of chromium for a todo list app or clipboard manager seems wasteful. But that's an edge case, most people build actual applications. If I'm building a non trivial cross platform app, I'll be orders of magnitude faster on the web stack. I'm not lazy, I just don't want to waste months of my time learning arcane APIs because anything else wouldn't line up with the author's point of view about what the "right" tool is.
jasonthevillain 10y ago
Calling people lazy should also be considered harmful. Please stop doing this. Time is finite, and not all of it should be spent programming.
evilnode 10y ago
I've been fighting with this for a while now. I think the only good reason to use something like Electron is if you need to get a cross-platform POC up and running quickly. I am currently trying to make a GUI to compose and render Terraform assets in a similar manner to AWS CloudFormation's visual designer, and I've spent an eternity trying to devise the best way to do this (this is mainly driven out of boredom more than anything else...Terraform works just fine as is). As much as I don't want to use Javascript and the cancer that is it's dependency management, the web stack is proving to be the path of least resistance thus far. Although I still don't understand why you need to download half of the known internet to install gulp and babel locally. I'm a GUI novice. Is there any cross-platform software that generates a true native UI on target platforms?
- rootlocus 10y ago
  > I'm a GUI novice. Is there any cross-platform software that generates a true native UI on target platforms? wxWidgets does
- z3t4 10y ago
  you dont need babel et al with electron because all your users will use the same "browser"
mherrmann 10y ago
I recently had to decide on a GUI technology for a file manager I'm developing [1]. Electron is sexy, but unfortunately takes way too long to start for my purposes. I ended up with PyQt: Pros: + Fast startup speed + I can use Python (and its vast ecosystem) + Qt has good ready-made components for eg. displaying a list of files (which is exactly what I need) Cons: - Compiling Qt (which I have to do for various reasons) takes time and is a pain - Bundling and deploying a Qt-based app (times 3 - OS X, Windows, Linux) is a pain - I have to deal with auto-updating myself (which I believe Electron supports out of the box) - times 3. - I would prefer to lay out the UI in well-understood HTML/CSS. Qt's components and its CSS-equivalent behave in very weird ways sometimes. I still sometimes wish I could use Electron but as OP says, we're supposed to pick the right tools. I explain my reasoning for picking PyQt over Electron (and other alternatives) in a blog post [2]. 1: https://fman.io https://fman.io 2: https://fman.io/blog/picking-technologies-for-a-desktop-app-in-2016/ https://fman.io/blog/picking-technologies-for-a-desktop-app-...
- jeremiep 10y ago
  A file manager would not be a good use-case for Electron. Especially if you don't intend to run it in the browser (which really would make no sense.) For the very reason you outlined - startup times. The average use-cases of file managers are being opened and closed very often. Electron is rather aimed at long-running applications you don't usually restart, like Atom and VSCode. Microsoft could've ported VS to other platforms, yet they chose Electron. I'm sure they spend quite a while analyzing the requirements and looking at alternatives as well before settling down. The end result is very lightweight compared to VS and does almost everything users require. VS still starts a lot slower than VSCode for one.
  - santaclaus 10y ago
    > Microsoft could've ported VS to other platforms Aren't they doing exactly this? [1] [1] https://news.ycombinator.com/item?id=12948043 https://news.ycombinator.com/item?id=12948043
    - 10y ago
butz 10y ago
Web browsers should have integrated functionality to run some websites as standalone apps (anyone remember Prism?). That way we wouldn't need to install yet another copy of browser with each app.
heisenbit 10y ago
The fact that electron is easy enough to write trivial apps while at the same time powerful enough to give us VS Code is in my book SPLENDID. If the trival app is too big for a trival app - who cares. The fact is there is now a serious contender in the cross-platform space that so far has been mainly occupied by Java. Java cross-platform is neither easy nor lightweight. And from what I have seen so far getting started with Electron looks a lot easier.
always_good 10y ago
SirCmpwn, you'll understand more about trade-offs when you finally have commercial success with one of your projects. It's too easy to lambast Electron and "lazy developers" when you've never had business concerns trump technical ones because none of your work ever tried to run that gauntlet. I had to chuckle to myself when I saw that your GitHub bio is: > I make unoriginal projects with better code than > the thing they rip off. I'm available for hire.
roryisok 10y ago
I have a windows store js/html app which I plan to re-release on electron. It features a rich text editor and a few other features. I want to release on Linux and mac os. Should I go away and learn qt/gtk/wx? Restart the whole project in Java? The idea that I might choose electron for ease/speed of development rather than use a leaner platform is being shit all over as a "business" decision. Not a "I don't have enough free time to learn two new languages and ui systems code three new apps" decision.
danblick 10y ago
For me the title evokes "Considered harmful essays considered harmful", which suggests that perhaps "benefits and disadvantages of Electron" would have been a better essay. http://meyerweb.com/eric/comment/chech.html http://meyerweb.com/eric/comment/chech.html
mixedbit 10y ago
The argument that the only advantage of Electron is cross platform portability is not true. Electron tries to duplicate what is already a main stream approach for deploying backend services. The only reliable and sane way do have a stable backend is to explicitly control and isolate all dependencies of the backend services by using virtual environments, Docker or virtual machines. Most people no longer think that it is a good idea to run multiple services on the same server, globally 'pip|npm|bundle install' packages that one of these services needs and hope for the best. Electron tries to do just that on the desktop. It packages all the dependencies that the application needs together with the application and installs them in an isolated app folder (not affecting any other app). It enables easy automatic updates of the whole environment without worrying that the update will break other apps or will not work because some user happens not to have some system library. Sure, this is much earlier stage than with backend services. Ideally Electron could ensure that identical dependencies that are shared between different apps are not installed multiple times, the way Docker does it. Even without such sharing I think that benefits of the Electron approach justify additional MBs on disk.
- mwcampbell 10y ago
  We've been doing self-contained app distributions, with all third-party dependencies bundled, for well over a decade, especially on Windows. But Electron does make it quite easy to package an app that way.
theSoenke 10y ago
The problem is there is no really alternative. Or what alternatives exist to write good looking, cross platform desktop applications with reasonable effort? I don't think there really is one. Another think is the huge amount of dependencies typical electron apps have (or in general node applications). 500-1000 packages is not unusual. Thats ridiculous for a simple desktop application
IshKebab 10y ago
Honestly I think this is a symptom of the lack of really good GUI toolkits that let you define the UI in an easy-to-use and powerful language. There's Qt & QML, but that's about it, and to be honest QML is still pretty immature (try doing a custom control with text, or any kind of text editor in QML). I really hope Rust or Go get great native GUI toolkits soon with nice declarative layout languages, but until that happens it is hard to get too angry at people using the wrong tool for the job because the right tools just aren't that great.
rpeden 10y ago
I'm a bit late to the party, but there are active React Native ports for both OSX and Windows. Using them could be a good solution for targeting OSX and Windows and reusing logic from your web React app without having to deal with the overhead of Electron.
agounaris 10y ago
We need to stop reading such posts. "Everything sucks because I say so". Technology is really fair. At the end we WILL use what matters the most and has the overall best tradeoffs. I don't like it when people use the expression "best tool for the job". Like you used every other available tool out there and you found the best one...no you haven't.
vorotato 10y ago
Considered Harmful essays considered harmful. https://news.ycombinator.com/item?id=9744916 https://news.ycombinator.com/item?id=9744916

159 points by kragniz 10y ago

If electron apps had a smarter way to manage chrome core as a dependency, the file size would be peanuts. Every apps is download on the same bundled core. Once this happens you won't have 100mb sizes. An intelligent installer could check core, if not installed download and install otherwise use what's on the system.

Longhanks 10y ago
What if there was a centralized way of accessing HTML + CSS + JS applications? Instead of installing apps, you could just... "download" the necessary files to execute them? Perhaps even on demand from centralized.. "servers"?
- detaro 10y ago
  I really don't want APIs to freely access the filesystem, other processes etc in my browser. And my applications to work offline. I haven't seen many examples of people using Electron to make applications that really should be web apps instead, but more for packaging web apps with native enhancements. Often I'd prefer a "proper" native app, pushing even more features in the browser IHMO is not the answer.
  - tscs37 10y ago
    >I really don't want APIs to freely access the filesystem, other processes etc in my browser. And my applications to work offline. Ctrl+S -> Save whole webpage alternatively get the Webpages source code.
- josho 10y ago
  > What if there was a centralized way of accessing HTML + CSS + JS applications There is. The major OSs provide APIs to access the platform browser. The downside is you need a platform specific shim to set this up using native code. So, developers need to step outside of their JS worldview for a few days to avoid that 200mb app size penalty. If you are building a platform agnostic app then I understand the value of Electron to avoid that work across each platform. But, it seems several of those Electron apps aren't even platform agnostic, so why not build the platform specific shim and be a better citizen on my hardware. edit: I'm daft
  - mnx 10y ago
    He was ironically talking about the web.
- nmca 10y ago
  Aha, he missed the joke...
jasonjayr 10y ago
For YEARS I remember having to chase down the VBRUN{100|200|300}.dll runtimes for the Visual Basic runtimes. Now that internet is everywhere, couldn't Electron: 1) Setup a common bootstrap mechanism so it's version agnostic 2) Check for the declared version of the app 3) If online (and allowed by system policy) check if there are security issues, or updates for the needed version 4) Advise user where to download the update, or (again, if allowed by policy) allow the user the proceed with the installation? With some magic to allow a 'side-by-side' distribution of the Electron runtime, on good-ol' durable media, wouldn't this go far to minimize the size of the distributions of these Electron apps? You could have a system with one (or more if nessecary) versions of the runtime, and multiple apps using that runtime (with isolated profiles, of course ...)
RandomOpinion 10y ago
>If electron apps had a smarter way to manage chrome core as a dependency, the file size would be peanuts. Every apps is download on the same bundled core. Once this happens you won't have 100mb sizes. An intelligent installer could check core, if not installed download and install otherwise use what's on the system. Oooh, we could give this core a snazzy name like "Flash" or "Silverlight" or something too. Once again, history repeats itself.
ssivark 10y ago
Isn't that what they call a web browser? For visiting websites and using web apps.

K0nserv 10y ago

I think the points raised are solid, but at this point it seems like Electron is the best worst solution for cross platform UI. Having worked with Qt I never wanna do that again. There's also a much more significant portion of developers who can work on Electron based apps. Part of picking the best tool for the job involves considering maintainability and ease of development after all.

santaclaus 10y ago
> Having worked with Qt I never wanna do that again. I've had to work on PyQt5 at work, and was pleasantly surprised out how easy it was to hack up a full app.
witty_username 10y ago
What are your problems with Qt? I was using PyQt, and I found it nice (Qt's integration is good).
- K0nserv 10y ago
  I was using C++ Qt. Just found it really unintuitive and difficult to use compared to web technologies and native macOS development.
  - witty_username 10y ago
    Could you give an example of something that was unintuitive or difficult to use?
- freeone3000 10y ago
  C++ Qt, I've found, is an entire separate beast. It goes out of its way to not rely on the STL, so that std::string and QString are separate, non-convertible classes. QList and std::list<> are the same, same for QMap and so on and so forth. So data communication is already a pain. We then have further issues with function invocation. Slots and sockets are simple with python, because functions are first-class in python. In C++, they are very much not, so slot-socket binding looks like: connect(sender, SIGNAL (valueChanged(QString,QString)), receiver, SLOT (updateValue(QString)) ); This is less than ideal.

deleted 10y ago

[deleted]

jules 10y ago

This article makes a good point, but what's the alternative? There is no good cross-platform GUI solution. Qt, GTK, JavaFx, wxWidgets, none of them are very good. Electron at least has the advantage of being fully cross-platform and not having to learn a whole new universe if you're already familiar with the web.

qwertyuiop924 10y ago
>There is no good cross-platform GUI solution. TTK. That is all.
deleted 10y ago
[deleted]
deleted 10y ago
[deleted]
lambda 10y ago
For cross-platform apps, Qt is the best I've used. But it does have its warts, and it is big, it will probably bloat your app by about as much as Electron does. But yeah, there's no one clear winner, which means that Electron is not a uniquely bad choice. Sure, it might be a little heavyweight for a really small simple app, and if you're not aiming for something cross platform your native widget toolkit might be a better idea.

dexwiz 10y ago

Electron, and to a great extent the cross platform fetish, is a perversion of DRY. They don't want to write the same code for two platforms. But its usually not the same code. Its the same logic implemented on two different platforms. Developers are so into code sharing, write once run everywhere, that they don't stop and ask if they should. In every case you are paying a price for abstraction, like running Electron or using a WebGL canvas instead of a native graphics API. The article highlights cases where they price was paid, but the app was still platform specific.

TeMPOraL 10y ago
Well, it's the same logic - so almost by definition it should be platform-independent. People are too lazy to introduce proper abstraction between what the application does and what it shows on screen, and suddenly porting is hell. Either way, Electron sucks because it ships a whole goddamn browser to give you just portability; you have to still pile on a ton of JS and CSS hacks to get a decent-looking SPA UI out of it, which you'd get for free with any proper GUI runtime. All that waste because people want to write JavaScript (which I understand - I have my favourite language I'd love to write more too) and this was the most brute-force way to allow it. Embed a system webview if you must, don't ship the goddamn browser!
sdegutis 10y ago
Cross platform is a perfectly fine goal. Why should a developer care need to write `open()` on one system and `OpenFile()` on another, when all they really mean is "open this file" with the exact same semantics? That said, I think electron is overkill from a technical standpoint, and ultimately is probably too harsh on hardware, but I've given up caring about that in the short term, because there are bigger problems with how our stupid computers are implemented.
jeremiep 10y ago
This makes no sense and completely disregards context. There are perfectly valid use cases for Electron, and they have absolutely nothing to do with what you said. There are also insane amounts of cross-platform native code written on platform abstractions layers. > Developers are so into code sharing, write once run everywhere, that they don't stop and ask if they should. Isn't that the very purpose of Qt or GTK which the article is promoting instead of Electron?

niftich 10y ago

This had me for the first half, where the author walks you through the 'case study' applications that offer minimal functionality despite shipping with an entire browser inside. But then the essay turns into a rant. It's 2016, people, the ship has sailed on pretending JS isn't a real programming language. Phrasing the argument the way he does just betrays his smug elitism. The fact is, for many types of applications, Electron is a really good fit: for example, shipping a single-page webapp as a desktop app, a need that surfaces often in today's world, despite his derision of this concept. An Electron-wrapped SPA is safer than going to the same website in a multi-tabbed browser and co-mingling your disparate cookies in the same jar, not to mention more convenient for the users, because they can treat it like any other desktop application -- with hardware access, and subject to the OS' native task management. For other apps, Electron allows the world's most popular layout system (HTML+CSS) to be used with one of the world's most popular programming languages. This is a huge boon for re-using knowledge, and perhaps does lead to some amateurish projects. Similar criticisms were leveled towards Visual Basic, where drag-and-drop composing and a good IDE enabled people to quickly crank out a GUI app from an idea.

ivan_gammel 10y ago
>Electron allows the world's most popular layout system (HTML+CSS) to be used with one of the world's most popular programming languages Just wanted to name the most obvious alternative: embedded browser component like QtWebKit, which allows to code most of the application logic on the language of your choice. Embedded browsers are the way people have been doing it since circa 2000 (by then, Windows was dominating platform and you could use embedded IE for rendering - the typical app size was much smaller than 200 Mb btw). I remember earning some money on a side project around that time - the CD catalog of bathroom equipment, which I implemented by borrowing huge part of my customer's website and embedding it in CBuilder app with few improvements for richer UX.
- mateuszf 10y ago
  But then you can't share the same code between your web application and desktop application. As a company you would have to pay two separate teams to develop each - developer time is expensive. Yes - electron apps are slower and eat more ram - but someone else is paying for that.

striking 10y ago

See, I totally agree with this essay. But what are the alternatives? Getting started with Qt/GTK isn't nearly as easy, for example. Maybe someone should write an intro to native GUI programming for JS devs.

ld00d 10y ago
What's wrong with JavaFX? I don't ever see it recommended, but a lot of us can do Java, and from my experience, it's way better than swing or awt.
- TeMPOraL 10y ago
  I'd say nothing. If you're working on JVM, it's the best choice.
- niftich 10y ago
  JavaFX is fairly decent, and I agree that it's more pleasant than Swing or AWT. It's a fairly good choice for places where you can mandate or ensure that Java will be present on the client (e.g. internal line-of-business apps), but also in places where you don't need to have some ancient version to support some ancient application instead -- which cuts down on the pool a bit. Unfortunately, most users know Java from years ago and never understood the difference between an applet or desktop application, and in the minds of some users it's still falsely stereotyped as slow or insecure. In most shops I know, Java is being extensively used on the back-end, but almost no custom Java apps with GUIs. Most shops (and people) who could do Java on the frontend have gone to learn Mono or WinForms or WPF instead, which gives you results that feel nicer to most users.
- antihero 10y ago
  Purely out of interest, because I might have used one without even realising it, but could you link some desktop applications written in Java that haven't been sluggish as hell or a bit broken feeling?
  - ld00d 10y ago

k__ 10y ago

OT: what's the difference between Electron and Electrode?

Shengbo 10y ago
Electron is a cross-platform desktop framework based on a web stack. http://electron.atom.io/ http://electron.atom.io/
- k__ 10y ago
  How does it compare to https://github.com/electrode-io https://github.com/electrode-io
  - detaro 10y ago
    Electrode seems to be for "normal" web sites/web apps, Electron is for packaging HTML+JS as desktop apps.
    - k__ 10y ago
      Okay, thanks.
  - Shengbo 10y ago
    Sorry, I assumed you were already familiar with electrode. As detaro says, it's for web apps, not desktop ones. Afaik its mostly boilerplate for node+react.
    - k__ 10y ago
      I see, thank you :)

bhouston 10y ago

There are a lot of shitty half working apps, and there always will be.

vvanders 10y ago

As some of who's had to support Qt, wxWidgets and other crazy x-platform UIs I find electron refreshing. Heck, I've got Rust talking to node.js in it. Elm for the front-end and Rust for the processing, it's a surprisingly pleasant development experience.

nmca 10y ago
Hey, is this open source? Sounds very cool. If not, can you point me towards any open source apps that are using a similar approach?
- vvanders 10y ago
  Not yet but it will be once it's a little further along. Rust -> Node -> Rust is pretty simple, just expose a c api and wrap it with node-ffi. Then I have the main thread piping messages over to the relevant windows straight into Elm ports. Nice bit is you can pass callbacks into Rust that calls js via c function pointers. Saves a ton of time marshaling data and is more efficient.

mikewhy 10y ago

Another example of "'____ considered harmful' considered harmful".

pluma 10y ago
Eric Meyer put it best, I think. Time for a repost: https://news.ycombinator.com/item?id=13031883 https://news.ycombinator.com/item?id=13031883

traviswingo 10y ago

I can understand the author's frustration with popular tools being very simple and somewhat overkill underneath, but I almost take it as a sense of frustration with himself. Electron was built to ship products as soon as possible. Most of the time, no one gives a flying fuck if the tech stack is the "right" choice and as efficient as it can be. I'd be willing to bet my net worth your users don't care at all how you built it, just that it does what they want it to do. In the end, for most companies, it's more about shipping product that sells than spending 5x more time writing it in C# because "you're an engineer so you should act like an engineer." That's not how the world works. And until you figure that out, you'll constantly be left behind by others who made compromises to capitalize on the market. Early optimization is the root of all evil.

StavrosK 10y ago
> I'd be willing to bet my net worth your users don't care at all how you built it, just that it does what they want it to do. That's exactly right, except "what I want it to do" is not use up all my RAM.
- traviswingo 10y ago
  Yeah...I could do without the RAM munchers.
ethbro 10y ago
This is both true, but also makes me weep for the state of software development. (Specifically, performance and security)
- traviswingo 10y ago
  I concur in that performance and security are very important in building software. I would, however, opt for a less performant version of a product if that means releasing it a couple months earlier than the alternative. I think it's possible to build very well performing applications on a tool like Electron, and once the market has proven that your product is in heavy demand, then you can re-approach it and decide to go native or revamp it using some lower level tools.

sergiotapia 10y ago

I look at Electron apps the same way I used to look at Adobe Air apps. Any League of Legends player knows how bad the launcher is - 80% the fault of Adobe Air. Sure it was easier to build, but your users suffer for it. Electron apps are pretty terrible performance wise, and you can immediately tell it's an Electron app. - Atom - Slack - GitKraken All of these apps have 'tells'.

chacham15 10y ago
And yet the League of Legends client was rewritten from AIR to HTML+JS on top of Chromium...
csydas 10y ago
While I agree with you that the old League launcher was just trash, I am mildly impressed how long it has lasted and worked for Riot. As much fun as it is to make fun of Riot's spaghetti code, they did a decent job with the Air Client, far more than I would have expected before I knew it was Air.
jeremiep 10y ago
Electron apps have exactly the same performance as web apps, which is what its aimed at. Badly performing code can be written in any language; you'd be surprised at how much mediocre C++ code is running on your desktop. You're also running insane amounts of mediocre C# applications. Comparing Electron to AIR makes no sense, they're radically different runtimes with radically different ecosystems. AIR stands alone while Electron reuses the web stack already used by millions of developers. I find it rather elitist to dismiss Electron apps as "easier" to build or having users suffer. Thats completely false and grossly overlooks the context in which these apps were built. This is the kind of comment you'd expect from a beginner without much experience wanting everything to be in his favourite language.
oldsj 10y ago
Yea but look at VSCode, definitely an exception to this. The feel of code vs atom is night and day to me.
- 10y ago

baybal2 10y ago

what is electron?

witty_username 10y ago
Downvoted; this question can easily be answered via a search engine.
- deleted 10y ago
  [deleted]
- FullMtlAlcoholc 10y ago
  Downvoted. It's generally considered rude to expend more effort being snarky than answering a simple question. To the parent: Electron is a framework for building cross-platform desktop apps with HTML CSS and JavaScript in an embedded chrome browsers/node.js environment. More info here: http://electron.atom.io http://electron.atom.io
  - witty_username 10y ago
    How would I say my message without being snarky?
    - FullMtlAlcoholc 10y ago
      If all I can add to a discussion is "Just google it", I just won't respond. For better or for worse, people aren't going to respond by saying 'By golly, you're right! I'm so lazy, but from now on, I will google stuff first instead of asking questions." They're just going to say basically "What an asshole, fuck this guy. Maybe he wants an answer that is curated and summarized by a human, not a litany of links where you don't know what to focus on. For example, when I asked what dependency injection is, some kind stranger responded "It's a million dollar term for a 5 cent concept. Pass objects as arguments to functions instead of instantiating them inside." Of course, this is a limited definition, but it was put into layman's terms and it answered my question. From that answer, I was able to really learn what it was instead of being stuck on phase 1 of understanding. When you're online, it's much easier to come off as a dick than it is in person so what I try to do is imagine someone coming up to me earnestly and genuinely asking the same question and respond thusly. Accordingly, when I know I'm asking a simple question, I add self-deprecation to the beginning. Example: "I have the technical and programming acumen of a bag of rocks, so excuse my elementary question, but..."

baby 10y ago

Yeah no. Electron is fine to write desktop apps. I've seen native app with more ugly UIs and being laggy, etc... For many apps Electron is fine and will perform as well, or even better than native apps (just because, developers you know).

adamnemecek 10y ago

I dislike JS just as much as the next guy but the only real contender on the list is Qt. Which you need to license for commercial development. Furthermore, even though I like to think that I'm ok in C++, I would really think twice before using it on my next project these days. The JS performance issues should go away for the most part when wasm is standard. Also a lot of people write some compile to JS language, not JS, so I think that most of the points of this blog will be rendered moot in the near future.

falcolas 10y ago
If you're doing commercial development, why is a license (and the attendant support) a big deal? Its cost in relation to that of your developers is neglegable. Or is the cost of the license really that prohibitive for a well supported and performant piece of software? [EDIT]: I found the pricing after a bit of creative googling: Startups is about $1,000 a year, non-startups are about $3,500 a year. Even without the discount, that's roughly equivalent to a month of one developer's time. IMO, not a terrible deal, for something you can freely license and use for cross platform development.
witty_username 10y ago
Qt is LGPL, you don't need to share your application code; you only need to share Qt's code (which only matters if you modify Qt). (not legal advice; I'm not completely sure about this) > The LGPL allows you to keep the source code of your application private as long as it is “work that uses” the library. Dynamic linking is usually recommended here.

jmlucjav 10y ago

I have been wondering...does Slack freeze for like a couple of minutes a couple of days a day for someone else? I am on win10, on pretty hefty machines. No idea if it's because Electron or something else, but it's really annoying. I could not find any trace of issues in the event viewer etc.

r618 10y ago
Yes it does for me, too / win 10, too /; I _think_ it is connected to @mention of my nick

seanwilson 10y ago

> For the love of God, learn something else. Learn how to use GTK or Qt. Maybe Xwt is more up your alley. How about GNOME’s Vala thing? Learn another programming language. Learn Python or C/C++ or C#. All of this takes time. If you want to launch an app on multiple platforms, Electron is a very time efficient way to do this. Obviously native apps for every platform would be ideal but not everyone has the resources for that. > Let me be clear about this: JavaScript sucks. It’s not the worst, but it’s also not by any means good. ES6 is a really great step forward and I’m thrilled about how much easier it’s going to be to write JavaScript, but it’s still JavaScript underneath the syntactic sugar. Use something like Typescript or Flow then. The above is like saying C++ sucks because assembly is a bad language to code in.

stevebmark 10y ago

"If you want to make a quick little app, instead of using something convenient that you know, you should learn a REAL language like C" Why is this garbage on the front page? Stop giving condescending people like this a platform.

nailer 10y ago

> For the price of 200 extra MiB of disk space and an entire Chromium process in RAM and on your CPU, you get a less capable GUI that saves you from having to type the -ss and -t flags yourself. Cool. I remember when Handbrake first came out, and 'make video go on iPod' went from some long winder research into ffmpeg flags to clicking a button that says 'output for iPod' [1]. This sounds similarly timesaving. [1]. yes, iPod. Showing my age.

q3k 10y ago
>[1]. yes, iPod. Showing my age. That was, what, 9 years ago? I realize it's an eternity in the average JS framework lifecycle timeframe, but come on.
deleted 10y ago
[deleted]

burai 10y ago

Well, that was a waste of time, the article is more a rant than anything else. I can understand that some piece of technology will not like everybody, but not spending any time giving proper alternatives. Not to mention that the header seems click bait since it's an opinion article, not an actual security risk.

calebm 10y ago

Just because a particular technology is not the "right" tool for every job doesn't make it harmful...

api 10y ago

The only viable alternative is Qt, and it is almost as big and offers a less familiar programming model. Native is only an option if you want to rebuild your app UI from scratch a minimum of twice and never support Linux or other less common desktops. UI development has always been in fragmentation hell.

NelsonMinar 10y ago

Stupid essay is stupid, but I'm glad it pointed me to lossless-cut because that tool is great! The author completely misses the point of Chromium in berating lossless-cut for being "a graphical UI for two ffmpeg flags". Yes, exactly, it's a GUI that lets you cut video to the precise frame you want to. That exactly solves a problem I've had for a long time; I've been using a horrible ffmpeg command line alias (along with preview in VLC) for a year now. He's a little right about "It doesn’t even use ffmpeg to decode the video preview in the app"; that would be useful for supporting weird formats that Chromium doesn't. But for common formats lossless-cut is great. It's at https://github.com/mifi/lossless-cut https://github.com/mifi/lossless-cut

yoavm 10y ago

While I agree with his general idea that Electron is usually not the best tool for the job, I think he's overestimating JS as the reason that people choose Electron. It's not because of JS, it's because of HTML and CSS, which aren't that bad comparing to other tools we have (especially since Flexbox). I think most people would love to write desktop apps using HTML and CSS, while using anything other than JS to do the logic. We're just... not there yet.

jeremiep 10y ago

I can't help but feel as if the author can't make the distinction between a platform and the software written for it. People have been misusing platforms ever since they existed. Its not because someone used Electron to build a console that Electron is bad in and of itself, it just means someone used the wrong tool for that specific job - or maybe that fitted all their requirements in which cause the author is just dismissing the work with no clue about its context. I also can't help but feel as if the author is a beginner developer lacking a huge amount of context and experience. Saying "Electron enables lazy developers to write garbage" displays a huge misconception about software development in the very first place - garbage will be written no matter the language or platform. Alls the article did was remind me that those who can, do, and those who can't, blog.

nycatelos 10y ago
And those who really can't post snarky comments on HN.

bmpafa 10y ago

This article, like many similar to it, makes the (imo flawed) assumption that a dev tool ought to be evaluated on only a few variables--e.g., code quality, performance, package size. If writing software is about making users' lives easier, happier, or better, though, I think we ought to optimize for that and that alone. I say let the market and communities of users decide which software they want to use. I use Nylas b/c I like the UX better than Ubuntu's Evolution, despite its flaws. I use Caret (electron markdown editor) because I wanted a cross-platform tool and I have > 4 gigs of ram. Hell, millions still use the Facebook Android app, despite the fact that it sucks down battery juice like your crazy uncle sucks down Miller Genuine Drafts before lecturing you on how terrible millennials are (happy Thanksgiving, btw). Of course, it's important we know the trade-offs of the decisions we make, so we need critical pieces like this. But to be as prescriptive as this article is to miss the forest for the trees. Love it or not, JS is a point of entry for a hell of a lot more ppl than C++ is, so expanding its reach into new arenas is not only net-good, but I'd argue also inevitable. That said, the article does skirt an issue I've thought about a little, and I'm interested to hear others' takes. If software collectively moves more towards higher-end systems, e.g., with SPAs and electron apps and all their cpu-intensive renders, are we further limiting a great web UX to those with the money to afford the latest laptops? We spend a lot of time thinking about accessibility standards for our products (A11Y, etc.), but when should we begin to think about accessibility from a socioeconomic perspective? Or are performant computers now so accessible that we needn't worry?

rootlocus 10y ago
> If writing software is about making users' lives easier, happier, or better, though, I think we ought to optimize for that and that alone. That's (imo) your flawed assumption. And no, just choosing electron won't make your users happier. > Love it or not, JS is a point of entry for a hell of a lot more ppl than C++ is C++ is not the only alternative. And considering the staggering amount of frameworks and tools one must learn to get started with JS other alternatives are actually easier. Unfortunately, not as cool. > That said, the article does skirt an issue I've thought about a little, and I'm interested to hear others' takes. Is this a joke? I had to google what skirt means: "attempt to ignore; avoid dealing with." That's the exact opposite of what the article does. Let me quote it for you: About electron: "One of the slowest, least memory efficient [...]" About terminal: "They’ve taken one of the most lightweight and essential tools on your computer and bloated it by orders of magnitude. " About lossless-cut: "For the price of 200 extra MiB of disk space and an entire Chromium process in RAM and on your CPU [..]" The conclusion that "people will require more money to buy more hardware to run bloated software" is not something only you thought about, it's only one step away from what the article says. And it's actually hilarious (read: infuriating) that you don't see the problem with that way of thinking. NASA put people on the moon with computers less powerful than a mobile phone. The article criticizes people who write bloated software, but you argue it's fine, because users are happy. Then you go on wondering if it's a problem that users won't afford the latest laptops to run bloated software. WAT?

qwertyuiop924 10y ago

sigh First off, JS is a perfectly usable language. In some respects, it's even great: of the "big three" scripting languages (Python/Ruby/JS), it's the only one that got Lambdas right, and also got closures right (unlike, say, Python). It has sometimes-quirky syntax, and some odd semantics, but they don't bite as often as you'd think. Second off, I would say that this article is right about the bulk of Electron: It's a pretty massive thing to lug around with your app, and not ideal in any sense. However, if you want to build a UI very fast, there is nothing better than HTML/CSS for it. Except maybe TK. Speaking of TK, I would actually advocate TK over Electron: it's easy to use, has bindings to pretty much every language out there, and with TTK, it doesn't look like crap. Finally, "considered harmful" essays rarely do any good, and frequently do harm. So yes, while I usually like Drew's writing (at least a little: he's good, but far from the best), I wish he had spent the time he spent writing this doing more work on SCAS. Seriously. If SCAS was actually done, and documented, and usable, that would be great. There is a freaking vacuum of good assemblers for the platform: another one would be nice.

MereInterest 10y ago
Now I'm curious. What would you say is wrong with python closures? Asking because they feel natural to me, and I haven't run into anything irritating about them. (As opposed to lambdas, which are really annoying and restricted in Python.)
- qwertyuiop924 10y ago
  It's not as bad as I thought, but Python doesn't actually have lexical scope, not really. But the LEGB rules mean that it should still work as you expect.
  - TJSomething 10y ago
    It does if you're using Python 3, which has the nonlocal keyword for lexical scope.
    - 10y ago

deleted 10y ago

[deleted]

lopatin 10y ago

This guy is doing his best to make sure we can't have nice things. > We use [JS] because we have no choice (people who know more than just JavaScript know this). The object model is whack and the loose typing is whack and the DOM is super whack. Moot point. I use React + TypeScript. Good types and barely ever work with the DOM. If you don't like TypeScript, your favorite programming language probably compiles to JS anyways. > The reason people choose Electron is because they are too lazy to learn the right tools for the job. This is the worst quality a developer can have. I agree that bundling a copy of chromium for a todo list app or clipboard manager seems wasteful. But that's an edge case, most people build actual applications. If I'm building a non trivial cross platform app, I'll be orders of magnitude faster on the web stack. I'm not lazy, I just don't want to waste months of my time learning arcane APIs because anything else wouldn't line up with the author's point of view about what the "right" tool is.

jasonthevillain 10y ago

Calling people lazy should also be considered harmful. Please stop doing this. Time is finite, and not all of it should be spent programming.

evilnode 10y ago

I've been fighting with this for a while now. I think the only good reason to use something like Electron is if you need to get a cross-platform POC up and running quickly. I am currently trying to make a GUI to compose and render Terraform assets in a similar manner to AWS CloudFormation's visual designer, and I've spent an eternity trying to devise the best way to do this (this is mainly driven out of boredom more than anything else...Terraform works just fine as is). As much as I don't want to use Javascript and the cancer that is it's dependency management, the web stack is proving to be the path of least resistance thus far. Although I still don't understand why you need to download half of the known internet to install gulp and babel locally. I'm a GUI novice. Is there any cross-platform software that generates a true native UI on target platforms?

rootlocus 10y ago
> I'm a GUI novice. Is there any cross-platform software that generates a true native UI on target platforms? wxWidgets does
z3t4 10y ago
you dont need babel et al with electron because all your users will use the same "browser"

mherrmann 10y ago

I recently had to decide on a GUI technology for a file manager I'm developing [1]. Electron is sexy, but unfortunately takes way too long to start for my purposes. I ended up with PyQt: Pros: + Fast startup speed + I can use Python (and its vast ecosystem) + Qt has good ready-made components for eg. displaying a list of files (which is exactly what I need) Cons: - Compiling Qt (which I have to do for various reasons) takes time and is a pain - Bundling and deploying a Qt-based app (times 3 - OS X, Windows, Linux) is a pain - I have to deal with auto-updating myself (which I believe Electron supports out of the box) - times 3. - I would prefer to lay out the UI in well-understood HTML/CSS. Qt's components and its CSS-equivalent behave in very weird ways sometimes. I still sometimes wish I could use Electron but as OP says, we're supposed to pick the right tools. I explain my reasoning for picking PyQt over Electron (and other alternatives) in a blog post [2]. 1: https://fman.io https://fman.io 2: https://fman.io/blog/picking-technologies-for-a-desktop-app-in-2016/ https://fman.io/blog/picking-technologies-for-a-desktop-app-...

jeremiep 10y ago
A file manager would not be a good use-case for Electron. Especially if you don't intend to run it in the browser (which really would make no sense.) For the very reason you outlined - startup times. The average use-cases of file managers are being opened and closed very often. Electron is rather aimed at long-running applications you don't usually restart, like Atom and VSCode. Microsoft could've ported VS to other platforms, yet they chose Electron. I'm sure they spend quite a while analyzing the requirements and looking at alternatives as well before settling down. The end result is very lightweight compared to VS and does almost everything users require. VS still starts a lot slower than VSCode for one.
- santaclaus 10y ago
  > Microsoft could've ported VS to other platforms Aren't they doing exactly this? [1] [1] https://news.ycombinator.com/item?id=12948043 https://news.ycombinator.com/item?id=12948043
  - 10y ago

butz 10y ago

Web browsers should have integrated functionality to run some websites as standalone apps (anyone remember Prism?). That way we wouldn't need to install yet another copy of browser with each app.

heisenbit 10y ago

The fact that electron is easy enough to write trivial apps while at the same time powerful enough to give us VS Code is in my book SPLENDID. If the trival app is too big for a trival app - who cares. The fact is there is now a serious contender in the cross-platform space that so far has been mainly occupied by Java. Java cross-platform is neither easy nor lightweight. And from what I have seen so far getting started with Electron looks a lot easier.

always_good 10y ago

SirCmpwn, you'll understand more about trade-offs when you finally have commercial success with one of your projects. It's too easy to lambast Electron and "lazy developers" when you've never had business concerns trump technical ones because none of your work ever tried to run that gauntlet. I had to chuckle to myself when I saw that your GitHub bio is: > I make unoriginal projects with better code than > the thing they rip off. I'm available for hire.

roryisok 10y ago

I have a windows store js/html app which I plan to re-release on electron. It features a rich text editor and a few other features. I want to release on Linux and mac os. Should I go away and learn qt/gtk/wx? Restart the whole project in Java? The idea that I might choose electron for ease/speed of development rather than use a leaner platform is being shit all over as a "business" decision. Not a "I don't have enough free time to learn two new languages and ui systems code three new apps" decision.

danblick 10y ago

For me the title evokes "Considered harmful essays considered harmful", which suggests that perhaps "benefits and disadvantages of Electron" would have been a better essay. http://meyerweb.com/eric/comment/chech.html http://meyerweb.com/eric/comment/chech.html

mixedbit 10y ago

The argument that the only advantage of Electron is cross platform portability is not true. Electron tries to duplicate what is already a main stream approach for deploying backend services. The only reliable and sane way do have a stable backend is to explicitly control and isolate all dependencies of the backend services by using virtual environments, Docker or virtual machines. Most people no longer think that it is a good idea to run multiple services on the same server, globally 'pip|npm|bundle install' packages that one of these services needs and hope for the best. Electron tries to do just that on the desktop. It packages all the dependencies that the application needs together with the application and installs them in an isolated app folder (not affecting any other app). It enables easy automatic updates of the whole environment without worrying that the update will break other apps or will not work because some user happens not to have some system library. Sure, this is much earlier stage than with backend services. Ideally Electron could ensure that identical dependencies that are shared between different apps are not installed multiple times, the way Docker does it. Even without such sharing I think that benefits of the Electron approach justify additional MBs on disk.

mwcampbell 10y ago
We've been doing self-contained app distributions, with all third-party dependencies bundled, for well over a decade, especially on Windows. But Electron does make it quite easy to package an app that way.

theSoenke 10y ago

The problem is there is no really alternative. Or what alternatives exist to write good looking, cross platform desktop applications with reasonable effort? I don't think there really is one. Another think is the huge amount of dependencies typical electron apps have (or in general node applications). 500-1000 packages is not unusual. Thats ridiculous for a simple desktop application

IshKebab 10y ago

Honestly I think this is a symptom of the lack of really good GUI toolkits that let you define the UI in an easy-to-use and powerful language. There's Qt & QML, but that's about it, and to be honest QML is still pretty immature (try doing a custom control with text, or any kind of text editor in QML). I really hope Rust or Go get great native GUI toolkits soon with nice declarative layout languages, but until that happens it is hard to get too angry at people using the wrong tool for the job because the right tools just aren't that great.

rpeden 10y ago

I'm a bit late to the party, but there are active React Native ports for both OSX and Windows. Using them could be a good solution for targeting OSX and Windows and reusing logic from your web React app without having to deal with the overhead of Electron.

agounaris 10y ago

We need to stop reading such posts. "Everything sucks because I say so". Technology is really fair. At the end we WILL use what matters the most and has the overall best tradeoffs. I don't like it when people use the expression "best tool for the job". Like you used every other available tool out there and you found the best one...no you haven't.

vorotato 10y ago

Considered Harmful essays considered harmful. https://news.ycombinator.com/item?id=9744916 https://news.ycombinator.com/item?id=9744916