Hacker News Reader

Comment by niftich | Hacker News Reader

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.

View on HN

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

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.

Should you be sharing that code? Should there be any business logic in the UI, or should it be pushed back into services that can be shared across both?

Maybe not all the code, but you can share lot of the UI behaviour, which is usually quite complicated. This kind of sharing allows you to to have a very similar experience in both places too.

Valid argument, but only in case if that web app exists. But if it exists and you want to share the code, there's no point in using Electron or building a desktop app at all: you can just create a shortcut on the desktop or even turn it into offline web app in Chrome.

not really, there can be lots of reuse of code between the two apps without them being exactly the same. Reuse of major parts of your codebase have been a business case for many years, without requiring that you reuse all that codebase.

> Yes - electron apps are slower and eat more ram - but someone else is paying for that.

I hope you're being facetious here. If you develop any kind of desktop application and truly believe this, honestly this is disappointing to read.

well if the developers or company don't actually use the app then their users are the ones paying for the ram, aren't they?

Doing something quick and dirty in electron takes N hours. Doing a 'proper' cross platform native app the right way takes N+P hours. If people are willing to pay for those extra P hours then I'd be more than happy to do things the 'right' way. However almost nobody is.

I've spent a lot of time on team web-apps-suck, and in many ways I'm still a casual fan. But the truth is I can go from zero to good enough much faster with web apps than anything else, and unfortunately most people only want to pay for good enough.

> Doing something quick and dirty in electron takes N hours. Doing a 'proper' cross platform native app the right way takes N+P hours.

Source?

Really, I'm not at all convinced that whipping up an Electron app is inherently quicker than whipping up a native app. Especially when we have robust, mature RAD tools for native toolkits, and things like Qt Quick, WPF, and Java FX let you go the whole "write your GUI in some markup language" route, if that's your bag.

>Yes - electron apps are slower and eat more ram - but someone else is paying for that.

Not that there aren't a lot of posts here defending Electron that basically say the same thing but don't you feel embarrassed in the slightest for saying that?

Yes, there's a lot of things we, as coders, can do to make our lives more convenient by treating bandwidth, RAM, and CPU wastage as an externality that can be shoved off onto the end-user to pay for. That doesn't mean we should.

I'm playing devils advocate here. It doesn't mean this is my way of thinking.

I'm fairly certain electron could easily be modified to be installed once and used as the launcher for its applications. I'm also fairly certain we'll see this in the future.

Therefore all claims that electron bloats 200Mb are just temporary. Its still a relatively young technology with huge potential (which also means huge potential for misuse!)

I spent 5+ years writing native GUI apps in half a dozen frameworks, I hope to never do so again unless the project's requirements ask for it, which I don't see happening for most use-cases out there.

Besides, almost nobody writes true native applications anymore - its all C# now which is ironic as its also extremely bloated with huge pools of average developers at best.

Even if the app is smaller on drive, it still takes ~200mb in ram for even the smallest apps.

Dropbox itself takes 200Mb and its a simple python app. Google drive takes 300Mb. VSCode takes about 100Mb of ram with a project opened right now. Even my Emacs takes 250Mb and I literally live inside it.

All of them have at least 2Gb of virtual memory being mapped to them. Yet I still have 9Gb of free ram.

If you want to go against bloat, you might just as well uninstall every single software from your computer, including its OS.

Literally? I demand a photo of you inside emacs

Each of those apps does a lot more than the most common use for electron: "online messengers"

Also, you're arguing in typical FYGM fashion. Not a good look.

I was merely comparing an Electron app (VSCode, not at all an "online messenger") to average apps running on the desktop because your original comment implied "200Mb for the smallest apps" which isn't true.

You could've said that clearly instead of making people guess what you're talking about.

No idea why VSCode is being sparing for you, but i've seen plenty of electron-based online messengers use that much just by running.

Meanwhile my webserver that serves 8 websites (some static sites, some sophisticated web apps) sites at 80 MB used RAM. For everything. You can't make this up.

Your web server also doesn't run X11 or any window managers nor any gui apps.

That's true, but I don't see anything in that list that needs to use multiple hundreds of MB of RAM. To witness, we had GUI apps in 1995. They look a bit nicer these days, but not multiple-100-MB nicer. :)

Emacs is far older than 1995 and still eating 250Mb :)

And there was a time when "Emacs" expanded to "eight megabytes and constantly swapping". :)

>VSCode takes about 100Mb of ram with a project opened right now.

I call bullshit on that one.

I currently have VS Code running with 7 files open, and it's using 83Mb. Like a browser, I imagine the RAM goes up with each tab, so it all depends on how many files you have open.

Well I just closed all files, disabled all extensions, restarted it and it's consuming 508MB.

>I'm fairly certain electron could easily be modified to be installed once and used as the launcher for its applications.

That's fine, we can return to this topic when it will become a mature launcher app. The thing is that today it's not in that state yet.

>Besides, almost nobody writes true native applications anymore

True native applications are not just the applications written using some native API and platform-specific low level language. Native app is the app that comfortably exists within the operating system environment, follows the UI guidelines and integrates with native UX and performance enhancing functions of the OS. For example, some universal Windows app written on C# is native on Windows.

Didn't Chrome already used to have that feature where you could install an application and it would put an icon on your desktop and open it in a browser window without tab/url bar?

Qt now just embeds an outdated version of blink and v8. Not really a better solution.

I think the author really has some valid points and he warns you about the rant part.

Valid points are:

  * Electron is often too much for the purpose
  * it does not look native and the devs don't care
  * often there are better tools

His points about JS being not a good programming language, meh, the language wars are probably never over #SmalltalkIsStillTheBest

> it does not look native and the devs don't care

this is not valid. no need to limit our use case to devs, either. at worst, users don't care. at best, users prefer it. see Spotify, Discord, Skype, Sublime, Chrome, Steam... should i keep going?

whenever i open an app that uses entirely native controls i just expect the author didn't want to invest any time into making their app look good.

I agree. I never thought about it before, but I have to say that the vast majority of the apps I like the usability in do not look or feel native.

I don't know if there are any studies into what "users" want, but I'm with you. I prefer a UX that fits the app best, not the OS. Especially because in my experience I'm using the same app across multiple OSs and I'd like the same layout in each (within reason)

> at worst, users don't care

Well, if you'll accept a single data point, I dislike using them. If there's a native alternative I will always go for that. If there is not, then sometimes this tips the decision to not install.

Native with minimal custom styled accents can be good looking, polished, and professional, and it doesn't throw platform conventions and features out the window to boot. Native looks bad only when the developer doesn't care.

I really don't think its such a great idea to reinvent the UI wheel, throwing the decades of research and refinement represented by native UI toolkits under the bus for the sake of branding and aesthetics, unless you have a good reason — a really good reason, like having to create brand new UI for a task that prior hadn't been performed on computers before.

I also see electron apps as stopgap measure, not a solution, and this feeling is reinforced every time I open up Activity Monitor and see Slack or Spotify sucking up upwards of half a gig of memory while sitting there doing nothing.

> I really don't think its such a great idea to reinvent the UI wheel, throwing the decades of research and refinement represented by native UI toolkits under the bus for the sake of branding and aesthetics, unless you have a good reason

It's a romantic thought, but that boat sailed a long time ago. Users got used to the web that had a very inconsistent UI between websites and on the website over time; before bootstrap, you would be hardpressed to find 2 websites with the same button styling. The last time the web used unstyled OS-controls was the 90s (with that default grey background - blech).

Yeah I agree with you. This is very true in the Windows world, if an app uses entirely native widgets it looks very meh.

However, on Linux and Mac it's a little different. On Mac you'll see many apps compromise their branded style to look more Mac-like in style. Meanwhile on Linux most people use apps entirely fitted for their desktop environment, and then it's branded apps that look out of place. Windows attempted to make it's desktop more this way and failed with Windows 8.

> This is very true in the Windows world, if an app uses entirely native widgets it looks very meh.

Yes an no. Windows is very versatile when it comes to design. However, if you just drag-n-drop elements in Visual Studio[1] or Qt, you get that "ugly" windows app. You'll notice plenty of Microsoft's own designs (as part of the OS, or as external apps) that look very well and fit in with the rest of the OS. There are also a few gems from 3rd parties.

> On Mac you'll see many apps compromise their branded style to look more Mac-like in style.

I agree with this, but I also believe it's an "optical illusion" in the sense that the GUI isn't very Mac itself, but it just borrows some design conventions used by the OS to make it easier for the user to understand the application.

> Meanwhile on Linux most people use apps entirely fitted for their desktop environment, and then it's branded apps that look out of place.

As a full-time (or at least 99%) Linux user, I tend to disagree with this. I know what you mean and you're sometimes right, but it's not really that black and white. a GTK app on Qt/Plasma won't look that nice unless you go out of your way to make it look nice (which is usually a lot of work), and open another GTK app and realise it looks broken, so you need to add more tweaks, and then you open the third app and give up. Same goes for KDE/Qt apps on Gnome.

> whenever i open an app that uses entirely native controls i just expect the author didn't want to invest any time into making their app look good.

So much of this! This is my exact sentiment, too! If you want your application to look different from the OS-provided GUI—which I think is a good thing—without investing much effort into implementing your own rendering/painting engine, the web is an excellent platform, not to mention there's much more you gain with it, too.

What bothers me is that the author focuses on a few bad points of electron, whilst there are also many benefits to using it.

Please explain why looking good necessarily means looking different from the native controls. Isn't consistency among apps on a given platform important?

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

Using the date as an argument is also poor form. JS is a terrible programming language (I'm not denying that it is a programming language though) regardless of how popular it is (although I think I might be going against the grain here on HN, many people here seem to enjoy node.js).

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

I feel it's unreasonable to turn a single web page into a desktop app by bundling an entire web browser with it.

> ...because they can treat it like any other desktop application -- with hardware access, and subject to the OS' native task management.

If you need direct hardware access it probably isn't well-suited to being a web app in the first place? Why use web technologies for it then?

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

HTML/CSS can be nice to have in such a situation, although a refusal to learn other GUI frameworks probably makes for a poor (native) developer.

The resource bloat and (usually) extreme disparity with the native user interface rarely makes it worthwhile for me to use an electron app. It feels like forcing a square peg into a round hole because the developer is seemingly unwilling to consider more appropriate technologies outside of their comfort zone. Yes, there are well-made electron apps (like VS Code mentioned in the article), but I, personally, would hate for it to become the norm.

JS is a terrible programming language

I can never see the point of comments like these. Not one person who reads that will have his mind changed.

HTML/CSS can be nice to have in such a situation, although a refusal to learn other GUI frameworks probably makes for a poor (native) developer.

No it doesn't. Either the developer benefits or doesn't benefit from "refusing". There's only so much time in the day. I'll refuse to to learn Qt or gtk+, unless there is some overwhelming benefit for me to learn it.

At this point it's like somebody saying "English is a terrible language". Yeah sure but what else are you going to use?

Ugh, why can't everyone just speak a real language, like Korean. Agglutinative languages are where it's at.

> I can never see the point of comments like these. Not one person who reads that will have his mind changed.

I wasn't expecting to change anyone's mind with that. There are more robust programming languages that don't have the same inconsistencies and idiosyncrasies and encourages better practices in general (even though it is true than you can write terrible code in any language).

> No it doesn't. Either the developer benefits or doesn't benefit from "refusing". There's only so much time in the day. I'll refuse to to learn Qt or gtk+, unless there is some overwhelming benefit for me to learn it.

That is true, but consider that the end product is not necessarily meant to be most convenient for the developer. Keeping the user in mind when making these decisions may make you consider more native and less resource-intensive alternatives. I have read in the past that Electron also posed some difficulties for screen readers, for example (although I'm not sure if that is still the case), which might not be something that impacts you as the developer, but which can make it harder for someone to make use of your software.

This means absolutely nothing. Otherwise everyone would be using Haskell, Coq or Agda. I'm willing to bet your favorite language has an insane amount of flaws as well (hint - they ALL do, otherwise we'd have converged to the "one true language" as an industry long, long ago.)

You can make an argument to say C++ is terrible, Java is, Ruby is, Python is, and it means absolutely nothing other than showing of your own insecurities. You can build great and mediocre things in any language and any platform. People do every day.

Also, if the developer is not one of the users of the software, you've already thrown a good chunk of quality out the window right there. You're simply not going to have the vision required to build the optimal user experience.

    > but consider that the end product is not
    > necessarily meant to be most convenient
    > for the developer.

Sorry, but life isn't fair. Everything including software involves trade-offs, and perhaps ones that you would not have made yourself.

For that reason, your post along with the blog post comes off as a tantrum. And if users really cared about these things, then surely you'd be able to swoop in and capitalize on it. But we both know that's not happening.

> Keeping the user in mind when making these decisions may make you consider more native and less resource-intensive alternatives

Usually the choice for the user is between "have an electron app in a month" and "have native app in a year", most users prefer to not wait, and when native app comes in a year, electron app will have much more polish, and run acceptably on new hardware.

The issue is not about 'protecting poor users'.

Most electron apps are quick experiments, to test out an idea without spending too much resources on it.

If idea is great, and performance is an issue, and there are enough users to get a team of highly skilled developers to work on it, they'll create native app, replace electron version (and then embed js vm to support plugins:).

>> JS is a terrible programming language

> I can never see the point of comments like these.

At minimum, I think the hope is that js-only programmers become aware that there are alternatives. And hear that the people who use those alternatives often find them better.

The arrogance in it, though, is that because people who like JS are "obviously" wrong, the reason must be that they don't know (enough) other programming languages or don't know them well enough.

I have used a number of different programming languages before JS, a couple of them more extensively and for a longer time than JS. I like JS. I understand its flaws. I also understand that all programming languages are terrible in their own unique ways -- I have accepted JavaScript's terribleness and a lot of it is addressed by ES2015 and beyond. I prefer JS's terribleness over that of other languages.

I like to make fun of PHP programmers the same way, but I understand that there are PHP programmers who are able to see beauty in PHP or have found their own perspective of PHP which makes it less terrible than the alternatives. I'm not one of them but I can relate to them. It's called empathy. OP lacks it.

First, X-only programmers are obviously wrong, whatever is the value of X.

That said, yes, somebody ought to love JS in a not blind way. Big numbers work that way. If that's you, I don't think those comments are for you. All languages have different flaws, every flaw relevance varies by context, and contexts are incredibly subjective. Yet, some contexts are much more common than others, and many people preach in support languages that are harming them because they don't know any better.

I did C, C++, Java, PHP, VBA and JS and can't tell why so many people have constant beef with JS. I mean especially after all major platforms have adopted ES2015.

For me, IO in JS is still kind of a hack. It still imposes an structure on my code that is different from the one I want.

IO in what? The browser? Node? If you mean node, what IO specifically? `http.createServer`? `fs.readFileSync`? `fs.createReadStream`? `fs.open`? `fs.readFile` with node callbacks? Promises? Streams? Observables?

Without context it sounds like you saw a bunch of nested callbacks in a Node.js example and judge the entire language based on that.

You'd be surprised how many people I've met that enjoy JavaScript. Nearly everyone I've met that hates JavaScript either didn't bother to learn it ("It's just a scripting language") or is just upset that they can't use their favourite programming language all the time (this is how we ended up with CoffeeScript, Sass and Haml and why everything in the Java world is eventually wrapped in XML).

I've seen enough different use cases and teams and programming languages to understand there's no point in being arrogant about language choice: if a team already knows a given language, it is most likely the right tool for the task, unless the benefits of replacing it are worth the overhead of properly switching to and gaining competence in another language.

> JS is a terrible programming language

[Citation needed]

Sorry, JavaScript may have gotten lucky being the lingua franca of the web, and it might not be perfect or even great, but it's "good enough" for most purposes these days.

If it were "terrible" you would expect at least one compile-to-JS [1] to have gained a non-trivial amount of traction by now. The supersets of JavaScript like Babel, TypeScript, and Flow are more popular than "not terrible" languages like ClojureScript, Elm, etc.

1. https://github.com/jashkenas/coffeescript/wiki/list-of-langu...

"a variable is not required to have its type declared nor are types associated with properties" (ECMAScript 2016 spec, 4.2)

Are you suggesting all dynamically typed languages are "terrible"?

The only languages I can think that share those properties are Perl (5, don't know about 6) and the retired Visual Basic.

There is more there than dynamic typing.

Not sure what I'm missing. Ruby? Python?

You are missing this part: nor are types associated with properties.

Ruby and Python do not fit it.

You can assign values of different types to the same property in those languages, no?

Types dictate¹ what properties are available.

1 - Or, in the case of Python, mostly dictate.

Cute. Smalltalk and LISP are terrible too huh?

Lisp is marginally better, because it tries less hard to work around type mismatches (so something like (+ 1 "") is an error). But it suffers from the same fundamental problem: no type checks until runtime.

It's fine to have some kind of option for data whose type isn't known until runtime. This stuff happens, and languages that insist there's no such thing make dealing with it more difficult. But this is the rarer case! Why optimise for it rather than for the more common one?

What Lisp are you developing with? Mature "industrial strength" Lisp compilers do perform type checks prior to run time.

Dynamic typing isn't optimization; dynamic typing without any static analysis is the utter lack of optimization.

> the developer is seemingly unwilling to consider more appropriate technologies outside of their comfort zone

The very same can be said about people looking down on Electron. Most of them can't write decent native apps to begin with.

I used all of win32, Qt, GTK, wx and Cocoa to name but a few. They all suck in one way or another. Suggesting people are poor native developers for refusing to learn these frameworks completely disregards the fact that most people using these frameworks are bad developers to begin with.

For the average application going native will easily triple your development time and costs for absolutely no noticeable performance difference.

> If you need direct hardware access it probably isn't well-suited to being a web app in the first place? Why use web technologies for it then?

What if the only difference between the web and desktop apps are that the desktop app can open local files while the web app downloads them? Are you going to write two apps in that case? This would be a mediocre economical choice at best as you're more than doubling the production costs for a difference nobody is going to care about.

> For the average application going native will easily triple your development time and costs for absolutely no noticeable performance difference.

Sublime text still smokes Atom and VSCode in the performance arena.

And yet they're still popular, so it can't be that significant of an issue.

Significant enough that it comes up anytime there is a discussion on HN.

> Significant enough that it comes up anytime there is a discussion on HN.

That is not a useful indicator. There's a reason that 'editor-wars' is a running joke.

> Significant enough that it comes up anytime there is a discussion on HN.

Because people don't know any better, shun anything that isn't their pet technology and generally sit on the wrong end of the Dunning-kruger effect.

And they're all mediocre when compared to Vim/Emacs (and these are both inferior to Spacemacs which actually combines these two.)

Why isn't everyone using Spacemacs then?

Visual Studio is much, much slower than all of them yet its still an incredibly popular IDE for some reason. It has endless flaws, one of them being its still 32-bit and often crashes on larger projects. (The last game I ported to the PSVita would hang VS for minutes sometimes, often ending with out-of-memory errors, we'd reboot VS between every profiling session.)

For a good chunk of users, features and ease of use are more important than performance (especially when most of the time it really, really doesn't matter for an editor.)

People use Visual Studio instead of Vim or GNU Emacs because there's much more marketing and advertising being done for Visual Studio.

> What if the only difference between the web and desktop apps are that the desktop app can open local files while the web app downloads them?

This was the exact problem I needed to solve that led to my first Electron app.

Needed to recursively crawl a directory and generate a report on all pdfs found and the total pages in each pdf.

It seemed silly to learn a new language and ui kit when I could glue together some wen technology over a weekend and make it happen.

http://designbymobi.us/how-i-built-my-first-desktop-app-in-3...

    > It feels like forcing a square peg into a round hole because the 
    > developer is seemingly unwilling to consider more appropriate
    > technologies outside of their comfort zone

Until I find out I'm immortal, the "right tool" is typically the one that lets me launch the fastest.

It just makes you feel good to dismiss other people as lazy or unwilling to venture outside their comfort zone, but that's more of a revelation about how you view others.

> JS is a terrible programming language

oh do us a favour, that's just YOUR opinion

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

From a systems perspective that is emminently rant worthy, it indicates the system has completely failed the developer who cannot easily express what they can in a single page web app as a real application in the system.

Yep, all the native toolkits failed, that's worthy of ranting about, but that is not what OP was doing.

The only native toolkit I've ever tried that I thought could compete with web is wpf. It was slow and cludgy but way ahead of its time, and the web is only now starting to approach its power.

I think WPF is nice but has actually fallen behind a bit on binding vs. some of the web toolkits like React/Redux, Angular 2, Ember.

It's been a while since I messed with it, but MVVM didn't work so well for some kinds of things, which seemed to be why for example selected items property is often not a dependency property of MS supplied widgets (so can't be participate in binding). For example see http://stackoverflow.com/questions/22868445/wpf-binding-sele... (from what I remember this accepted solution also has a subtle bug of double notification (or was it lack of notification on one side?)).

Perhaps WPF was the Electron of its time, in terms of being a resource hog. I remember how one particular WPF-based application hastened the obsolescence of my brother's laptop some years ago. [1]

[1]: https://news.ycombinator.com/item?id=8444494

I can't see how Cocoa failed at anything.

> I can't see how Cocoa failed at anything.

Will my Cocoa app run on Windows, Linux and the web?

(A well-designed web app built with Electron will).

Why should any company that wants their product to be widely available invest in Cocoa developers?

Why should it? It focuses on its platform and does it well.

I prefer native Mac apps to cross-platform ones. Serious companies should build native apps and keep UX guidelines of each platform in mind.

Building an app once for each platform is not economically viable for a lot of teams, 'serious' or otherwise.

Yes, but it's not Cocoa's problem.

It's Cocoa's problem because people stop using it for that reason. A toolkit no-one uses is a failure.

It's doing well - I currently have 2 Electron apps and dozens of Cocoa apps on my Mac. :)

We're talking about dev mindshare today. What you have installed is irrelevant.

I bet that 20-25% of desktop apps on Mac will use Electron in the next 5-7 years.

Not at all. It simply indicates the system has a radically different interface than the web. And that web APIs have evolved incredibly more than system ones when it comes to building quality UX.

Its no wonder all the best native applications ALL use proprietary toolkits. Adobe being a prime example. Such a toolkit is orders of magnitude easier to reproduce in HTML/CSS than it is in any of Qt/GTK/wx and others.

Thinking a web app can easily be expressed as a systems application grossly overlooks the complexity web apps have scaled to.

Make no mistake, system-platforms failed.

The point you're actually making is that the decision to build a desktop app with Electron is almost always a business decision and not a technical one. If you already have all this SPA code that you built, it's going to be cheaper to re-use it and provide the same UI to the end user that they already know from your SPA.

Forget for a second that the performance will be terrible because it's not native code. Forget for a second that a desktop application typically benefits from a more dense UI than a web application, and may benefit from such desktop-only UI features such as separate tooltip windows or OpenGL rendering (yes you can do that in a browser but come on it's not the same). The fact of the matter is that the beancounters typically care less about delivering the best possible UX and more about how their bottom line is going to be affected as they continue the corporate strategy of expending 20% of the effort to get 80% of the potential business benefit.

Electron was built for the beancounters. Not for the HN purists. Simple as that.

> Not for the HN purists.

Is that necessarily a bad thing? I'll throw a great counter-example to you, Mattermost. It's a great open source project that uses Electron to build a client app for just about every single platform.

Have you maintained a cross-platform app for Windows, OSX, and all the various flavor of linux? I have, it's hell. You have compiler differences, ui semantic differences and a litany of per-platform quirks.

Does Electron solve every single use case? No. However in the cases where it makes sense it's a great tool.

I also have, and would keep on using Java, Qt, wxWidgets than bothering with Electron, and I do have my share of web projects.

Also for all the kids out there, Electron is the second coming of the MSHTML ActiveX engine.

I didn't like it then, surely don't like it now.

>Electron is the second coming of the MSHTML ActiveX engine.

Really? I've always thought of it as the "blinders-on dev's XULRunner".

Well, MSHTML is older. :)

I disagree, the first case study app revealed flawed logic. lossless-cut is a _visual_ tool for trimming videos. Author derides it by comparing it to the underlying ffmpeg command but that misses the point entirely: I can't magically divine where the start and end is. I need to see the video to determine the times. This tool provides an easy way to see the video and step until I find the right start and end points. There are plenty of frontends to ffmpeg that do similar tasks, and I really wish the author explored some of them to see how they compare to the electron solution.

Essays like these, along with Thanksgiving conversations with older extended family, are what really make me question the wisdom of eternal life. What if all the people stuck in the past like this were with us forever?

Then we might not be doomed to make the same mistakes again every 40 or so years?

On the topic of tiny apps that shouldn't need electron, I found another one - catlight.io

This is a status bar icon that notifies you when your build is broken. Cool idea, but what the heck does it need electron for?

http://catlight.helprace.com/i15-why-is-setup-so-big

Electron is useful for some cases, but this is not one of them

Reply on news.ycombinator.com