Improve implementation of example JobQueues

[jedel1043]

Fixes #3531.

I'm surprised tokio uses so few dependencies, but I'm not complaining.

[github-actions]

Test262 conformance changes

Test result	main count	PR count	difference
Total	50,254	50,254	0
Passed	44,995	44,995	0
Ignored	1,740	1,740	0
Failed	3,519	3,519	0
Panics	0	0	0
Conformance	89.54%	89.54%	0.00%

[hansl]

Aside: Should we put this code (and maybe others) to a boa_job_queues or similar so it's easier to replicate?

[jedel1043]

@hansl based off of this reddit post, I'm not sure if people really like when libraries scatter an usage example into multiple files 😅

[hansl]

I understood this post for being "stop making examples thousands of lines long with implementations I might not need", not "stop abstracting reusable parts and using them in examples".

In my ideal world, I'd rather have this: https://github.com/bytecodealliance/wasmtime/blob/main/examples/gcd.rs than having to implement a job queue just for an example, which becomes bloated (multiple files, hundreds of lines, etc). If anything this PR adds exactly what the Reddit post was expressing as frustration.

Reusable pieces should be moved to the engine or a separate crate, and used in examples to show how simple adding Boa to your project is. Which is really what we want people to take away; add Boa, get JS running in 20 lines of code! Easy.

[hansl]

The discussion above is not blocking to the code going in.

[jedel1043]

@hansl Ahh, I interpreted your comment as abstracting the job queue implementation for only the examples. I suppose you mean maintaining a crate of job queues for ease of use? I can see the utility in that. I would even put the implementations on boa_runtime, since I think it's pretty obvious that runtimes would want to run on a fully-fledged event loop.

[jedel1043]

I wouldn't use that in the futures examples though, because people still would want to know how to implement their own event loop. We can add a separate example on how to use the runtime.

[hansl]

I suppose you mean maintaining a crate of job queues for ease of use?

Correct.

people still would want to know how to implement their own event loop

I would reply that they can always read the code and doc (assuming it's well written, of course).

[jedel1043]

I would reply that they can always read the code and doc (assuming it's well written, of course).

I don't like assuming people will read the code base for questions they have, because most of the time they (unfortunately) don't 😅. Most users would open the examples folder, see that the "event_loop" example doesn't have an event loop, and either close the page or ask a question on how to do it.

[nekevss]

Looks good to me.

The examples look good. Was there any thought about putting together a blog post around the examples at some point to publish on the site. Could be a good post.

[jedel1043]

Gonna put it on draft for a moment to add an example on how to use run_jobs_async, since there were some people asking how to execute the engine inside #[tokio::main]

[jedel1043]

Should be good to review now.