Live data from Hacker News

Show HN: Speed up your site by running JavaScript when the browser is idle

npmjs.com

71–80 of 95 posts

Re: Show HN: Speed up your site by running JavaScript when the browser is idle

#71
post #60

There's lots of confusion what this is. Basically browser runs a giant eventloop. Whenever you call async function in javascript, it gets put into a queue, and called by the event loop (usually the next execution). This basically makes it so that the async call gets tagged with metadata that tells the event queue "Don't call me unless you have nothing else to call". So basically it keeps the async call at the end of…

In defense of the documentation, this is a convenience wrapper around “requestIdleCallback” which from MDN: “queues a function to be called during a browser's idle periods.”

https://developer.mozilla.org/en-US/docs/Web/API/Window/requ...

Re: Show HN: Speed up your site by running JavaScript when the browser is idle

#72
post #6

I have an idea: why not speed up your site by NOT running js at all?

But what if we want a site that's more interactive than a blog?

Who's 'we'? The user, or the web dev? Most javascript exists to scratch the itch of the webdev who made it, doing shit no user ever asked for.

Re: Show HN: Speed up your site by running JavaScript when the browser is idle

#74
post #6

I have an idea: why not speed up your site by NOT running js at all?

The docs are confusing.

This is really about how to make your UI more responsive by performing intensive tasks only when your browser isn’t doing any other tasks related to the javascript code.

In non JS applications, you typically would do this on any thread but the UI thread. But with Javascript, you have the option of doing tasks on the main thread, but only when all other tasks are not being executed. IE a priority queue.

Re: Show HN: Speed up your site by running JavaScript when the browser is idle

#75
post #69

Earlier quoted context omitted.

It's always Safari. I never figured out why.

The 3 biggest browser engines are Gecko, Webkit, and Blink. Gecko is the engine behind Firefox and is maintained by Mozilla, so it has a good number of open source contributors that help fix issues when they are found. It also has some issues occasionally but since it has only a ~3% usage these days you don't get as many complaints. Blink is used by Chromium (which includes Edge, Chrome, Opera, Brave, and Samsung bro…

> Apple has a conservative approach to Webkit and doesn't implement as many new features or standards as quickly as the other engines

This is far too generous. They intentionally withold features in an effort to push people towards their app store.

Re: Show HN: Speed up your site by running JavaScript when the browser is idle

#76
post #3

One of the extensions that suspends idle tabs can protect me from this?

Lot of people confused here -- the "running JavaScript when the browser is idle" part is a bit misleading.

It doesn't run stuff when you're the tab is backgrounded (browsers already heavily reduce what sites can do when not in focus[1]). Instead, it just lets you delay work until the page isn't doing anything else (such as rendering the page). For example, you might do this when updating a visualization on a page so that the other updates can complete first (e.g., update the input UI and redraw the visualization when that's done).

[1] https://blog.chromium.org/2020/11/tab-throttling-and-more-pe...

Re: Show HN: Speed up your site by running JavaScript when the browser is idle

#77

Earlier quoted context omitted.

But what if we want a site that's more interactive than a blog?

Who's 'we'? The user, or the web dev? Most javascript exists to scratch the itch of the webdev who made it, doing shit no user ever asked for.

Well, people who don't want to keep refreshing the page to see the site update. That's not just "[scratching] the itch of the webdev who made it".

Re: Show HN: Speed up your site by running JavaScript when the browser is idle

#78
post #46
post #40

Earlier quoted context omitted.

It's not about the computer being idle. It's about waiting for the main thread to be unblocked before doing stuff you would want to do anyway, but now you can schedule it for later to give priority to more urgent tasks. A very common optimization technique in all sorts of software and I don't see why it wouldn't be valid for a web application. Go read https://developer.mozilla.org/en-US/docs/Web/API/Background_... fo…

You still haven't answered the question. Your link has no example of use cases, though it has warnings about what not to do.

Example: In a map application you give priority to rendering the visible map tiles while deferring preloading the surrounding non-visible tiles until the CPU is free. So basically it only renders tiles outside the viewport in a cache if the CPU is not already busy rendering what you're currently looking at.

Any sort of thing that is not urgent and high priority, and where it's no big deal if it's not executed immediately will benefit from being run in requestIdleCallback.

Re: Show HN: Speed up your site by running JavaScript when the browser is idle

#79
post #24

Earlier quoted context omitted.

The point is to play nice. "I have this task the page needs to do, but I can wait a bit until more convenient". Not "browser is idle, let's mine some bitcoin" as you suggest.

Actually I wasn't thinking of bitcoin, but for example of needless auto refreshes and animations. Seriously, web devs need to learn to respect my battery and electricity bill more.

This is just a generic “old man shouting at clouds” complaint at this point. You’re not engaging with the material at all.

Re: Show HN: Speed up your site by running JavaScript when the browser is idle

#80
This whole thing is about performance, but what I'm not seeing any of is actual measurements. Is this actually useful enough to justify all the overhead of writing code in a catered way? Right now I highly doubt it. Is this beneficial at all? After all you're adding some extra overhead and delays which might or might not be made up for by the fact that things are chopped up. The whole of the work doesn't change, you're simply adding breaks in the middle.
Post reply on HN