I'll answer my own question tomorrow, but i can't remember what core async's behavior in the browser is under the hood. Is it all done against the main thread or are web works, or some other form of thread involved. If not, why not! it seems like browsers are finding ways for userland to do multithreaded work but in limited way. Does that seem right? I suppose i'm not asking about core async in particular here, but more of a general, question about how browsers seem to be changing and how i should be keeping up with those changes.

no. 😛 everything happens in the one and only main thread, no workers. moving stuff into the worker is non trivial since they can't share memory with the main thread and as such would have to serialize/deserialize everything back and forth pretty much killing every performance gain in the process

browsers aren't changing in this regard at all

I'm gonna do that thing people hate. Why aren't they changing, why wouldn't we want multithreading on the browser to?

because retrofitting multi-threading into a JS runtime such as the browser is pretty much impossible

gotcha. What about webassembly?

WASM might get some sort of threading at some point but doesn't as of now

roger.

i suppose i need to read about Service Workers again, as i believe thats what was driving my question. I recall them being very limited, but would in time become more general.

same thing as a regular web worker really, just that it can intercept requests done by the main thread (and other workers) and has a different lifecycle

they are indeed very limited. even more so than regular workers I'd say since they are even more resource constrained

due to their request intercept and lifecycle they can do more than regular workers but IMHO this is pretty much all they should ever be doing

doing more is just asking for trouble 😛

I feel like the docs on service workers told me one thing, and i heard another. > A service worker is a script that your browser runs in the background,

that is the lifecylce I'm refering to yes. you install it and it runs, independent of the page you are on

> Developers mimic 'concurrency' by using techniques like setTimeout(), setInterval(), XMLHttpRequest, and event handlers. Yes, all of these features run asynchronously, but non-blocking doesn't necessarily mean concurrency. Asynchronous events are processed after the current executing script has yielded. The good news is that HTML5 gives us something better than these hacks! from ~ https://www.html5rocks.com/en/tutorials/workers/basics/ Is the difference between concurrency and asynchronous in this context that we the developer can't control what work is being done on the main thread? e.g stop task A now do task B. I'm not used to comapring the words directly and its revealing that i don't understand one or the other.

https://joearms.github.io/published/2013-04-05-concurrent-and-parallel-programming.html

> but non-blocking doesn't necessarily mean concurrency

this doesn't make sense IMHO 😛

you should probably refer to something more current than July 26th, 2010 when reading about this stuff. this might still be accurate but a lot has happened since 😛

Well thats a link off the top link about service workers. So i guess i'm in good company if i'm confused.

service workers didn't exist in 2010 so you won't find anything about them there. this is just all about generic web workers

https://developer.mozilla.org/en-US/docs/Web/API/Service_Worker_API

i always either go to mozilla or what ever google is calling themselves. Ah, ty for the link.

the main downside of service workers in general is that they are again single threaded. if you do something in them that actually requires CPU time they will block for that time. if a request comes in while that work is happening it has to wait, possibly affecting the UX waiting longer for a request when it maybe didn't need to

Yea. They seem to be a way to schedule work for later, not run it in parallel. I think the use of the term "run in the background" confused me because i assume the "forground" is the main thread. Thanks for the insight as always, i'm going to fall asleep in my chair now. ill look into this a bit more tomorrow.

they are used for coordination of (possibly) all network access so slowing them down in any other way is bad

Is there any way to get the macros for cljs.test in self hosted (bootstrapped) clojurescript?

It seems like there's only cljs.core$macros.

And it looks like I can't just analyze test.cljc from the clojurescript repo myself because it looks like it relies on clojure.template, which is does not appear to be provided by clojurescript. (Unless I'm missing something.)

https://github.com/clojure/clojure/blob/master/src/clj/clojure/template.clj

i think i've seen this used for clojure.test/are? Not sure if there are any other usages. Surprised me the first time i saw it

@dpsutton Hmm... I see. I guess that file looks like its technically valid clojurescript.

So I should analyze that, and then analyze cljs.test?

i don't know how clj macros interact with the analyzer to be honest

From what I can tell, it puts stuff in a :macros namespace.

Which is similar to the :defs in some ways.

But this is just based off of experimentation.

Oh, also it also seems to bind to mod_name$macros in the environment.

Anyway, I'll give it a shot, thanks.

@dpsutton Yup, looks like plopping those files into https://visr.pl and running them Just worked. So thanks. 🙂