Hacker News Reader

Comment by onion2k | Hacker News Reader

Here are two utterly trivial examples of some JS;

    for (let x=0; x < 10000; x++) {
        if (x===0) console.log(x);
    }

versus

    for (let x=0; x < 10000; x++) {
        if (x===0) {
           console.log(x);
           break;
        }
    }

The second one is more code but much more efficient. Having a smaller amount of code doesn't translate in to having faster or more efficient code.

This is the basis of most optimization work - you're optimizing code to do the minimum amount of work, and very often that means writing more code. A moderately complex React/Vue/Svelte app will be much more energy efficient than a naive vanilla JS alternative because most frameworks to clever and hard things to reduce the amount of work that's done in order to increase performance, and a side effect of that is using less energy.

View on HN

> A moderately complex React/Vue/Svelte app will be much more energy efficient than a naive vanilla JS alternative because most frameworks to clever and hard things to reduce the amount of work that's done in order to increase performance, and a side effect of that is using less energy.

I would debate this, the black box abstraction provided by react, et al. would probably wipe out any performance benefit.

It's all in how you write the code. I've (as an end user) muddled through tons of slow react apps, and used some highly performance vanilla js (or just "framework-less") apps.

React is not an abstraction, and to be honest the fact you are calling it that kind of makes it easy to dismiss your post here.

But you are right that it's mostly all down to how you write the code. But I'll gladly argue that it's a lot easier to write bad, inefficient UI code with vanilla JS than with React.

You don't really get to see the alternative because generally, react makes things so much easier and efficient that it opens a lot of doors and allows companies to go crazy with features and bloat. By being the beast it is, it puts a lot of power in the hands of developers, but equivalent UIs without react will most likely be 3 magnitudes worse. Keyword: equivalent.

Similarly, asymptotic complexity is not always an adequate approximation of energy consumption.

More code leads to more cache misses. More code leads to more energy consumed transmitting that data over the internet, and wireless radios are energy-expensive. More code leads to more time parsing, compiling, optimizing, and then JITing code, which can utterly dominate actual runtime energy cost if the program is not long-lived - which describes a lot of webpages.

Finally, very few webpages actually need to even be a "moderately complex React/Vue/Svelte app" - the essential complexity to the task being done is low, and webdevs add extra, unnecessary features for very poor reasons (showing off?). Take https://nabeelqu.co/understanding for example - 1.17M downloaded for 21K of text and two small images (one of which didn't load anyway). There's a 276K JavaScript file in there, among others - and the primary purpose of this page is to display a static document. Or, take any modern newspaper website you want - bloated with images, tracking, and JavaScript providing near-useless (and probably near-unused) features with a data-size:content-size ratio of over 100. If something is moderately complex, it would be much better as a native app in the majority of situations, which comes with significant performance improvements.

If you write it from scratch you could just get straight to the point with

    console.log(0);

It's an incredibly trivial example. With real world code you can't always do that. I hoped that would be obvious.

It was pretty obvious...

With the code above, an optimizing compiler might actually produce this line.

But the simplest thing to do would be return after logging 0 rather than loop thousands of times for no reason. By that I mean, the second example in my eyes is simpler.

The simplest code as you point out is often faster than the shortest.

Reply on news.ycombinator.com