4 ms·
Hmm, that leads be to an interesting counter idea. Why should Firefox or any other dynamic software have the ability to be slow for what it archives? If compil
by qqii 7y ago
Hmm, that leads be to an interesting counter idea.
Why should Firefox or any other dynamic software have the ability to be slow for what it archives? If compilers should be fast, Web engines should be equally as fast. The Web should have never been designed such that a slow website (relative to the task) could be achieved. In the same way that you can only express memory safe code in rust and type safe code in haskell why not being only able to express "fast for what is interactive"?
- zbentley 7y ago> The Web should have never been designed such that a slow website (relative to the task) could be achieved That's already the case, your orders of magnitude are just off. Long-running AJAX or page loads are timed out at a pretty consistent point across browsers. Half-open/closed TCP connections are timed out at a pretty consistent point across operating systems. Busy-looping JS gets you a "page is not responding" block in a similar amount of time; same for nonresponsive native applications on many operating systems. Their definition of "slow" or "stuck" just tends to be "tens of seconds or minutes", not the threshold of perceived responsiveness you want in a website. Also, your parenthetical is a pretty tall-née-impossible order: > a slow website (relative to the task) How could the "task" be classified? Do you mean "task" as in "clicking a button and having a DOM update"? Or as in "this is a TODO application so it should have responsiveness threshold X"?