[boskonyc]

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.

[abiox]

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

[smokeyj]

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

[tmcb]

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.

[smokeyj]

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.