Hacker News new | past | comments | ask | show | jobs | submit login

I meant to dig more into requestAnimationFrame, thanks for the prompt. I should clarify, the problem is that you can crash a web page if you do any animation inside of a runaway loop but especially painting with console. I suppose this indirection might help you realize that before it happens though, and that's probably worth doing. Thanks for the code.



You're welcome. I avoid runaway loops like fire because the crashes tend to be problematic to debug. Consider the timeout thing from SO. Generally working with events in JS is easier than central run loops.


> Generally working with events in JS is easier than central run loops.

That's an interesting perspective I hadn't thought of before, I'll see if that can inspire some design pattern. Thanks for another good prompt!


You may want to read https://developer.mozilla.org/en-US/docs/Web/JavaScript/Even...

Note that it does not mention promises and async/await but it does include it. Promises are essentially syntactic sugar for a setTimeout calling success and failure methods. This also means that promise code will be executed in parallel but on one thread and one heap, so each promise will fight with all other for priority. This is generally fine for async stuff like fetching resources but it would completely destroy performance if it would do anything heavy, like, say unzipping zips with jszip.

Historically the event-driven model of JS enabled Node.js's API to be callback-driven. This lead to what is called "callback hell" and eventually to a proper introduction of promises and async/await to the language.


A good read, mdn is far and away the best resource I have found for web technologies. I'm excitedly looking into some p2p tech and the webrtc articles are useful.

From the article:

> "Run to completion"...

> A downside of this model is that if a message takes too long to complete, the web application is unable to process user interactions like click or scroll. The browser mitigates this with the "a script is taking too long to run" dialog. A good practice to follow is to make message processing short and if possible cut down one message into several messages.

Good advice. And this is what happens when you `while(1) {console.log("loop")}`. Though I've never see a "taking too long to run" dialog, I'm just eventually able to kill the process myself and sometimes it takes a few minutes while my fans spin.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: