61–70 of 95 posts
Earlier quoted context omitted.
you are absolutely right. we should completely throw away the development of browser APIs over the years and develop sites with html 4.0
Incoming flood of edgelord comments saying they think that would be better
Earlier quoted context omitted.
If you do too much work at once on the main thread, the application will visibly freeze. Say you need to call a few rest apis that trigger changes to the DOM. If the user is actively interacting with your application, doing an operation like this, say every 5 seconds, could cause momentary lag that feels bad. What if you could wait to do the update until the main thread is free?
Making changes to the DOM seconds later is the part I don't get. Either it's part of interaction and therefore it's urgent, or it's... what?
Earlier quoted context omitted.
What kind of question is that? Games or applications like Figma obviously require more computing power than a static homepage.
Do they? To do what when the computer is idle ? Those are interactive applications, there's not that much work for them to do when you're not interacting with them.
https://github.com/pastelsky/network-idle-callback
Helpful for progressively hydrating features in a page, or loading assets for next interaction
Earlier quoted context omitted.
What kind of question is that? Games or applications like Figma obviously require more computing power than a static homepage.
Do they? To do what when the computer is idle ? Those are interactive applications, there's not that much work for them to do when you're not interacting with them.
On a related note – ‘networkIdleCallback’ : Preload assets and data whenever network is idle — https://github.com/pastelsky/network-idle-callback Helpful for progressively hydrating features in a page, or loading assets for next interaction
Earlier quoted context omitted.
If you do too much work at once on the main thread, the application will visibly freeze. Say you need to call a few rest apis that trigger changes to the DOM. If the user is actively interacting with your application, doing an operation like this, say every 5 seconds, could cause momentary lag that feels bad. What if you could wait to do the update until the main thread is free?
Making changes to the DOM seconds later is the part I don't get. Either it's part of interaction and therefore it's urgent, or it's... what?
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…
This comment was better than the docs, as usual.
As other comments have pointed out, this behavior is enabled by `requestIdleCallback`. MDN has a good example and looks like this is not supported by Safari - https://developer.mozilla.org/en-US/docs/Web/API/Background_...
It's always Safari. I never figured out why.
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 browsers). It has the biggest market share and probably the most people actively paid to work on it.
Webkit is currently only used by Safari and maintained by Apple alone. (Also all iOS browsers have to use webkit which is why iOS chrome has a lot of the same bugs as iOS safari etc). Apple has a conservative approach to Webkit and doesn't implement as many new features or standards as quickly as the other engines. It has the biggest non blink engine market share so it's usually the outlier when it comes to support issues.
Before 2013 Chromium was webkit based, but that year they made a fork and took their engine in a new direction so Webkit lost some of its previous maintainers.
Earlier quoted context omitted.
requestIdleCallback isn’t something that you need to protect yourself from. It just executes a function when there’s nothing else happening on your page essentially.
You mean my browser still doesn't use enough CPU? I don't want sites that aren't in focus to do anything.