Your comment here broke the HN guideline against calling names in arguments. Please don't do that; it degrades discussion.

I'd like to suggest an edit to two kinds of programmers: There are programmers that care about the quality, elegance, and beauty of their code, and there are programmers who just want to make the most people happy as fast as possible. Fine dining vs fast food.

> programmers that care about the quality, elegance, and beauty of their code

this seems less like fine dining, and more like a fancy kitchen. this is much more about the chef (though there are possibly secondary effects for diners).

There's a difference between writing maintainable code and premature optimization. Experience is knowing the difference between you can and you should.

It is easy to talk about premature optimization in a world like ours; the hardware industry spits products twice as fast and generous in regards to memory every three years or so, to keep up with software designed by programmers who think likewise. You just replace your two-year old laptop with 4GB of RAM---which became unusable all of a sudden because now it keeps hitting virtual memory, which is I/O expensive---for one with 8GB of RAM.

If you consider hardware is a commodity and the cost of opportunity for replacing hardware instead of optimizing software is worth it, then formulate it better.

One may object by saying that the burden on hardware resources is higher because we consume more data, which is partially right. Although I don't intend to give a thorough objection here, please consider those two points:

- The payload fraction is larger in multimedia applications, for sure, but I can't see a reason why the "propellant mass fraction" equivalent in software should be bigger than it was, for example, 10 years ago. If we consider text-only data as an example, we notice that the propellant mass fraction increased as well.

- Higher level languages undeniably consume more resources by orders of magnitude; hardware frequencies must keep up by orders of magnitude as well.

The desktop is a dying platform, and if you're on it you can probably afford the overhead. From a global perspective if you're after accessability you'd be targeting the web and android. Both of which lend themselves nicely to react/react-native. And if you already have this architecture you can package it for desktop basically for free and integrate with the needed platform features that way, along with an upgrade strategy if you use react-native for OSX/Win.

Just checked the all recent the crash reports saved on my Mac. Slack has crashed more than anything!

This is especially surprising because I'm currently writing a custom crash reporter and part of that was experimenting with the builtin crash reporter by crashing a test app.

Just to be clear Slack is ahead of everything, even my artificially induced crashes..

I regret that I have but one upvote to give.

Funny how much of HN is happy to see people dismantle social contracts or break the law to "create value" in startups, always justified with the idea "people want a thing", but shit bricks if someone wants to spend more time worrying about the UX of an app than micromanaging bytes of memory.

"Dorks who care about programming, and programmers who care about creating deliverable value."

I'd rather have 95% of the code on my machines written by those from the former camp.

And if you think about it, the 5% of it is the stuff that comes & goes. Slack? Big now, but will anyone remember it in 5 years after the next big thing?

So which camp is generating the true "value"?

Did you post this from a browser or using CURL?

Ladies and gentlemen of the jury, I rest my case.

And what was organizing your memory regions as you posted that? Some piece of javascript written by some hipster second week out of a hacker bootcamp or a properly designed malloc implementation?

Not everything is what's visible on the surface.

You're countering by arguing that JS is a well engineered tool created by highly experienced engineers? I guess we'll just have to agree to violently agree.

It seems like you think you're making a game-ending point here.

I don't think developers have anything to do here. There are two kinds of companies: those which don't care for quality, security, performance, good/evil and those which are bankrupt, because they were constrained by those ideas while their competitors were not.

Ironically, on my system it seems to be the Electron/Chrome apps that crash or run like crap more than native applications.

I completely agree with the content of your message, just wish you had used a word less derogatory than 'dorks'

I'm having a hard time thinking of a word that's less derogatory. What do you have in mind?

In this context, how about 'programmer'?

That leads to a very strange sentence since 'programmer' is already used. More importantly 'programmer' doesn't work well as "thing you don't want to be". Instead you've left that category of word entirely. "Dork" is about as minimally-derogatory as you can get without losing the meaning entirely. And it doesn't feed any kind of discrimination.

Ahh I understand your point now. For the record I meant 'less derogatory or not at all derogatory'.

You don't actually need to use derogatory words at all to win the argument. In fact, your more likely to change a person's mind if you avoid personal attacks like 'dork' and 'neckbeard bullshit'.

I know you're right. Being level headed is something I need to work on.

One problem, you cant optimize at all with electron, you are stuck with shoving a complete web browser solution into your program to make a GUI.

You are stuck with a massive amount of dependencies (html/css parser, javascript VM...) to various massive projects for what, easy cross platform support? Sure cross platform GUI's have been a problem, but any developer can agree that dependency to this level within professional code is a great way to cause a massive amount of headache from required library changes, bugs and memory leaks that you have NO control over due to it not being your code, required security updates that require code refactoring for no fault of your own, etc.

People keep bringing this up because it is a bad solution to a large problem. Maybe the reason its being rehashed so much is because there is truth to what is being said.

I would try finding a graphics library such as opengl, and build a UI in the spirit of something like:

https://github.com/ocornut/imgui https://github.com/vurtun/nuklear

Your solution to memory leaks is using a lower-level language? I should probably stop reading there..

How do you make SSL connections? How do you parse JSON api's? How do you play audio, integrate with platform features (menu bars, dock dropping etc)? How do you create P2P WebRTC connections that capture camera and mic inputs? Let me guess, you have libraries for that.

People keep bringing this up because they're insecure about their role as programmers in a world where creating useful functionality is becoming easier and more accessable. People keep bringing this up because they don't comprehend what business requirements actually are and the cost of rolling your own technology and battle testing it.

I promise you. We're not all stupid. That's all I'm asking of people to consider before they start solving all the world's problems.

> Your solution to memory leaks is using a lower-level language? I should probably stop reading there..

Lower level than sandboxing into a js VM? yes. Writing everything in assembly, or in an unmanaged language? no. Adding unnecessary complexity to a program increases possibilities of bugs, which in this case, will be outside of your control. And this is a perfect example of unnecessary complexity.

> How do you make SSL connections? How do you parse JSON api's? How do you play audio, integrate with platform features (menu bars, dock dropping etc)? How do you create P2P WebRTC connections that capture camera and mic inputs? Let me guess, you have libraries for that.

Simple libraries that intend on doing the job and getting out of your way, yes. I wasn't aware you needed to embed a web browser to parse a json string, or to establish an SSL connection? There is a large difference between what a library is, and what electron aims to be... There will always be system apis that you will have to interface with, these are apples and oranges.

> People keep bringing this up because they're insecure about their role as programmers in a world where creating useful functionality is becoming easier and more accessable. People keep bringing this up because they don't comprehend what business requirements actually are and the cost of rolling your own technology and battle testing it.

Thank you for reminding me what the phrase "argumentum ad-hominem" means.

> I promise you. We're not all stupid. That's all I'm asking of people to consider before they start solving all the world's problems.

I can't speak for anyone else but I don't believe anyone who finds electron appealing is stupid. I am sure these people are more than capable programmers, and electron is a very appealing way for a web-based product to be able to quickly produce and distribute a desktop client. Most just desire for people to understand that most large-scale projects will dig their own graves in the promises of cross platform support and a fast production cycle, which has been a growing trend in software development for quite a few years now.

The basic premise for this entire blog post is that people who use electron don't know that lower level technologies exist.

FTA: It turns out modern operating systems already have nice, fast UI libraries. So use them you clod!

FTA: Also all you web devs: Go learn C or Rust or something.

So yes, this is in-fact an ad-hominem attack. There's a certain type of person who rehashes this old stupid argument. A few years ago they'd berate you for using a LAMP stack to set up your clients wordpress blog. A couple years ago they'd give you shit for using Node on the server and not being a "real" developer.

Point being, if the author of this blog post resonates with you - I can guarantee you with a high degree of certainty that I can fit your world view in a tiny little box.

Having trouble figuring out what "dork", "hipster", and "neckbeard" have in common other than the latter two terms both having become completely meaningless due to abuse and overuse.

Well said. Being able to write an application and have it work on multiple platforms without any major UI inconsistencies or UX idiosyncrasies is a major benefit.

You're joking, right? Electron apps are fully inconsistent with any environment they live in. Want right-click? Sorry. Platform-standard control elements or animations? Nope.

Reminds me of some of the worst excesses[1] of AAA Windows software - now available on Mac.

[1] http://2.bp.blogspot.com/-lFgnREt7Q_c/U2mqWkYYDiI/AAAAAAAAAJ...

Edit: I think it's ironic that Macs were criticized for years for having single-button mice but now developers are more than happy to ship apps with no right-click support at all.

Considering you just admitted to only ever using Slack I would think you would be the one joking, right?

Right click on electron?? What're you talking about?

I'll admit my experience with electron apps is limited to Slack - where right clicking. Gives you "Copy Link" and "Go To Link". Having said that, do you have an example of an electron app that's not a design misfit within MacOS and Windows?

I use Atom on a daily basis. Dead simple plugins and themes. Check out the git-time-machine-view plugin.

Of course it's not perfect. But as someone who's used it for the past year I can attest it's been a joy to use.

I think OP meant that the app is consistent across platforms -- e.g. Slack on Windows looks and works like Slack on MacOS.