6 ms·
Stop including megabytes of javascript in every page, and composing pages from 100s of requests to microservices. In short, keep things simple.
by eplanit 6y ago
Stop including megabytes of javascript in every page, and composing pages from 100s of requests to microservices. In short, keep things simple.
- onion2k 6y agoHere 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.
- uberswe 6y agoIf you write it from scratch you could just get straight to the point with console.log(0);
- onion2k 6y agoIt's an incredibly trivial example. With real world code you can't always do that. I hoped that would be obvious.
- jagged-chisel 6y agoWith the code above, an optimizing compiler might actually produce this line.
- julianlam 6y ago> 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.
- scrollaway 6y agoReact 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.
- fouric 6y agoSimilarly, 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 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.
- dangerface 6y agoBut 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.
- yetihehe 6y agoMaybe don't make autoplaying videos? Those must use up bandwidth, maybe more than javascript. They also use power to decompress on client side.
- Shared404 6y agoI find it disappointing that so many sites pull down so much JS that a video maybe uses more bandwith.
- acdha 6y agoIt’s a fascinating failure as an industry - there is a ton of infrastructure around media optimization but our attitude about adding JS dependencies has been “there’s always room for one more”. I’ve seen more than a few cases where someone loaded an image optimization library where the JavaScript used more transfer, CPU, and memory than the original images, as if this wasn’t one of the easiest things to measure.
- zaro 6y agoBut what should we do when things are actually complex? There is a lot of negativity here on HN on the same things you mentioned, but I fail to see any viable alternatives. Like what? Replace the MB of JS with plain Html and forms? It's not going to be simpler to code, and it's definitely not going to be simpler for the users. Or maybe use a native desktop app? Then it's even more complicated for the users, and coding it leads you in world of cross platform pain. And the closest thing there was to not using MB of Javascript and have decent UX was Java and applets/jlnp, but it somehow didn't manage to be widely adopted.
- franzwong 6y agoDeveloper can stop using webpack to bundle 3rd party libraries. Let browser cache it.
- ratww 6y ago+1. If you're only targeting evergreen browsers you can already use syntax like `import Library from './library.js'`, plus lots of modern ES6 features. For IE11 just load polyfills and let the 2-10% of IE11 users pay the tax, instead of making all your users in modern browsers download giant bundles.
- fgkramer 6y agoCross origin browser cache is a no-go for Safari (and hopefully other browsers will follow suit), 3rd party scripts from a CDN are not cached across different domains. The only way to properly cache things longterm is with webpack records, but not many people can bear with the added complexity of maintaining them in their pipelines.
- blackflame7000 6y agoShot in the dark here, but perhaps you could try leaving the functionality the same and just try taking out all that code that tracks every pixel the user looks at, for how long, and how they can better market porn to that user...seems like that stuff could be taken out...
- kavi87 6y agoThat's not a solution; making simple stuff is harder than doing complicated stuff, and it costs much, MUCH more.
- josephg 6y agoThis is a dangerous question but - why is that the case? Why is simple software so much more difficult to write?
- croon 6y agoAnyone can write a sequential .py file with redundant if/else statements. It takes more than 1 hour to learn how to refactor that into concice functions or objects. It takes more than 100 hours to learn how to golf that into 30 bytes.
- ratww 6y ago"Simple software" does not mean "golfed". Quite the opposite, actually. What the grandparent is suggesting is using simpler architectures, not necessarily smaller (in the code-golf sense) code.
- croon 6y agoFair point, but at least part of golfing is cutting out anything redundant (although much more than that, which can get into obfuscation territory). Code I'm impressed with is generally when it gets the job done in the most concise/simple (while readable) manner. That is by rule done by the most experienced programmers. To paraphrase Pascal: > I would have written a shorter letter, but I did not have the time.