[ng12]

> Maybe we're seeing a push back towards performance over purity?

No, because performance is generally not a huge concern on the front-end. I'm not applying ML strategies to hundreds of thousands of data points, I'm trying to render 10 elements instead of 9. Performance is so rarely a concern that I'd always err on the side cleaner code than hyper-performant code. This stuff isn't even worth thinking about.

[MiddleEndian]

>performance is generally not a huge concern on the front-end

Everyone who has ever used a web app already knows this unfortunately.

[ng12]

You're like the third person to make this snarky comment in this thread. I promise you the JavaScript runtime is not the bottleneck.

[EForEndeavour]

Javascript isn't just a frontend language though, is it?

> I'm not applying ML strategies to hundreds of thousands of data points

Maybe you aren't, but the folks over at tensorflow.js [1] certainly are, as well as Andrej Karpathy's ConvnetJS [2].

[1] https://www.tensorflow.org/js [2] https://cs.stanford.edu/people/karpathy/convnetjs/demo/class...

[ng12]

Which is why I specified I was talking about the front-end.

[EForEndeavour]

There's plenty of demand for and work on frontend JS performance as well, e.g, https://greensock.com/

[ng12]

You're being pedantic -- I'm not saying that there performance-critical JS code doesn't exist, I'm saying that the push for readability over performance isn't going anywhere.

[apk-d]

> This stuff isn't even worth thinking about.

If more front-end developers have this mindset, I'm beginning to understand how the web (and the desktop, via electron and such) has become the embarrassingly slow and unusable mess that it is nowadays.

[ng12]

I can promise you the JavaScript runtime is not the cause of whatever "slow and unusable mess" you've experienced.

[pdimitar]

True, but these things add up. It is definitely not a problem at one spot; make those spots 100 and the problem manifests itself very obviously.

I am a fan of expressive and readable code as well and have fully migrated to functional languages in the last 2-3 years. But I don't think in JS we have the luxury to ignore a 945x performance improvement on a very low-level building-block function. It's used in thousands of places.

So you know, I agree with your premise. As a compromise I'd make an utility that reads much better than `Array.push` but still uses it internally (if such a tool does not already exist).

[BubRoss]

Performance might not be a concern for you, but it is your users who should be deciding.

[ng12]

As if my users would ever notice. Some of them are still using IE9.