i am not even sure we should define async
it may be hard (it is) because it cannot be matched to one thing
the question is: is it useful to define async? or event loop? there must be tons of concepts i have no idea in the realm of physical chips that make true parallelism possible
i am totally fine with "user finger" and "quickies", job queues and blocking or non-blocking APIs
the finger symbolizes touch events and even mouse clicks and keyboard or general user initiated events, which i have to match to quickies which are very tiny (execution time) blocking(!) jobs that will be queued by the browser
to reach my goals, i prefer non-blocking APIs because i can discard some time consuming jobs to underlying systems and i jsut write a quicky for what i want (store data in indexed db) and what will happen if it succeeds or fails etc (different quickies)
sync, async do not really help me, of course i have to understand when others talk about it or i see or use (or my preferred AI coder) async, but it just means non-blocking API
but again, the async programming model is actually writing very much blocking quickies where the non-blocking nature is the small, atomic nature (execution-time-wise) of the blocking jobs I try to match to chaotic, non-deterministic events, triggered by fingers or browsers or whatever
I actually dont care, just hope that the browser code uses great concurrent models with cpp or rust or whatever and the device has multiple executions units (os threads) and the os scheduler does a great job, managing things whether there are more execution units or just 1 available
async for me a not well defined concept and even if it was somehow defined, i am not sure it would be useful to me
useful concepts are events, the blocking nature of jobs i write in js, what my functions see (closure i guess), what runs as a job if i use APIs and what runs as a different job after the events the browser triggers (ready, error whatever)
even the name callback was extremely confusing because i really thought back then that the code somehow stops there and waits for a callback... no, it runs to the end of that section and you really have to understand what other things run when it "calls back" and what that code sees
to be honest, i think it is a mess and genius at the same time... but understanding "async" or rather the model was really difficult because i just dont think this means anything
it is actually very simple to understand with different concepts like event, blocking job, job queue, non-blocking API
what i also find important to know what we are doing and what others do like browser code, os etc... it is a bit like a cpp code declares a concurrent model with a thrad but the os will decide... in js, we use non-blocking api which implicitly declares a probably concurrent model the browser or node or whatever should use and i am sure they always do
the most important thing is to keep your jobs quick, probably under 30-50ms and non-blocking API are great because your job just declares the intent and done, and languages like cpp, rust will declare the os that they want the actual task done concurrently so even if the os has one real physical thread, the UI will be responsive since the OS will switch between UI code execution and "real task" execution like some networking or database or whatever
but all an "async" programmer has to do is to create a great UX model and match events to quickies