Will putting limits on how much JavaScript is loaded by a website help prevent user resource abuse?

Yesterday, Craig Hockenberry, who is a Partner at The Iconfactory, reported a bug on WebKit, which focuses on adding a limit on how much JavaScript code a website can load to avoid resource abuse of user computers.

Hockenberry feels that though content blocking has helped in reducing the resource abuse and hence providing better performance and better battery life, there are few downsides of using content blockers. His bug report said, “it's hurting many smaller sites that rely on advertising to keep the lights on. More and more of these sites are pleading to disable content blockers.” This results in collateral damage to smaller sites.

As a solution to this, he suggested that we need to find a way to incentivize JavaScript developers who keep their codebase smaller and minimal. “Great code happens when developers are given resource constraints... Lack of computing resources inspires creativity”, he adds.

As an end result, he believes that we can allow sites to show as many advertisements as they want, but keeping the overall size under a fixed amount. He believes that we can also ask users for permission by adding a simple dialog box, for example, "The site example.com uses 5 MB of scripting. Allow it?”

This bug report triggered a discussion on Hacker News, and though few users agreed to his suggestion most were against it. Some developers mentioned that users usually do not read the dialogs and blindly click OK to get the dialog to go away. And, even if users read the dialog, they will not be knowing how much JavaScript code is too much. “There's no context to tell her whether 5MB is a lot, or how it compares to payloads delivered by similar sites. It just expects her to have a strong opinion on a subject that nobody who isn't a coder themselves would have an opinion about,” he added.

Other ways to prevent JavaScript code from slowing down browsers

Despite the disagreement, developers do agree that there is a need for user-friendly resource limitations in browsers and some suggested the other ways we can prevent JavaScript bloat. One of them said it is good to add resource-limiting tabs on CPU usage, number of HTTP requests and memory usage:

“CPU usage allows an initial burst, but after a few seconds dial down to max ~0.5% of CPU, with additional bursts allowed after any user interaction like click or keyboard)

Number of HTTP requests (again, initial bursts allowed and in response to user interaction, but radically delay/queue requests for the sites that try to load a new ad every second even after the page has been loaded for 10 minutes)

Memory usage (probably the hardest one to get right though)”

Another user adds, “With that said, I do hope we're able to figure out how to treat web "sites" and web "apps" differently - for the former, I want as little JS as possible since that just gets in the way of content, but for the latter, the JS is necessary to get the app running, and I don't mind if its a few megabytes in size.”

You can read the bug reported on WebKit Bugzilla.

D3.js 5.8.0, a JavaScript library for interactive data visualizations in browsers, is now out!

16 JavaScript frameworks developers should learn in 2019

npm JavaScript predictions for 2019: React, GraphQL, and TypeScript are three technologies to learn