Hello, I'm not quite sure what you are saying here since I do not know boot or hoplon or durable-cells.
I can however suggest a "better" solution for Workers: Using Closure Modules. CLJS or boot do not implement them for :none at the moment but shadow-build does. I also have a few extra hints for web-worker support but first let me try to explain why you want to use modules. If you do a separate build for your worker and your main app you'll have to download 2 full builds. Meaning that your main.js file will contain an implementation of cljs.core and the worker.js will contain a different one. If you are on :none they will share some parts, but :advanced will share nothing. This is bad as you want to keep the scripts to download to a minimum. So how would the ideal solution look like: 1) base.js for all common code (eg. cljs.core) 2) app.js for all the app code 3) worker.js for all the worker related code 2+3 both share the base.js, you can add more workers trivially. IMHO the best way to organize this from a code perspective is to have a separate namespace for each worker as well as the app, where the app should not depend on the worker or vice versa. Since this is only one build now, you only need to worry about one compile as well. I have a demo repo here: https://github.com/thheller/worker-example First we have the code: https://github.com/thheller/worker-example/tree/master/src/cljs/demo/app.cljs https://github.com/thheller/worker-example/tree/master/src/cljs/demo/worker1.cljs Each is a self contained namespace that just does some trivial stuff. The :none output is a bit confusing but lets look at the :advanced output: https://github.com/thheller/worker-example/blob/advanced/demo/js/demo.js https://github.com/thheller/worker-example/blob/advanced/demo/js/worker1.js Each is only the very minimum of code, the worker1.js will automatically load the base.js which means it shares all of the code in base.js with the page itself. There will be not additional download as the browser has already downloaded it when loading the page (since it included base.js and demo.js). The :none build basically does the same thing just in a closure compliant way. No duplicate file downloads will happen. Everything is compiled using shadow-build, I can go into further detail on how if anyone is interested. I just wanted to make the point that web workers should *ALWAYS* be used via closure modules, it is just the most efficient way to organise the code and output. Just my 2 cents, /thomas On Friday, February 19, 2016 at 4:54:59 PM UTC+1, William la Forge wrote: > > Compiling with optimizations none is no doubt quite handy, especially in > conjunction with source maps, as a traceback will take you to the line of > code causing the problems, and with the same variable names used in your > original clojurescript code. But this is not currently possible for .jc > files used by web workers as the unoptimized .js file contains a reference > to js/window--and window does not exist in a web worker. > > > You should still be able to use optimizations none with your main > javascript code, but you will need to compile your main code and your web > worker code separately so that you can use different optimizations as > appropriate. And you can do this so long as your not using shared workers. > The question then is, how to compile the .js files separately. > > The duracell <https://github.com/aatree/aademos/tree/master/duracell> demo > uses a web worker AND is itself compiled with optimizations none. There are > two things done to accomplish this: > > 1. Duracell itself has no web worker code. Though it uses a library, > durable-cells <https://github.com/aatree/durable-cells>, which > includes a web worker. > 2. In the duracell build.boot > <https://github.com/aatree/aademos/blob/master/duracell/build.boot> file, > the dev task uses pandeiro/boot-http > <https://github.com/pandeiro/boot-http> rather than the simpler > tailrecursion/boot-jetty <https://github.com/tailrecursion/boot-jetty>. > The advantage to using boot-http is that it supports the loading of static > files from library jar files. In this case, that means the main code in > aaworker can create a web worker using durable-cell's dcells.js file. > > So how does the durable-cells library create the dcells.js file? Again, > there are two things done to accomplish this: > > 1. In the durable-cells build.boot > <https://github.com/aatree/durable-cells/blob/master/build.boot> file, > the dev task includes (cljs :optimizations :simple). This invokes the > compiler with an appropriate level of optimizations. > 2. But we still need to define the .js file. This is done in the > dcells.cljs.edn > > <https://github.com/aatree/durable-cells/blob/master/src/worker/dcells.cljs.edn> > file. > See Multiple Builds > <https://github.com/adzerk-oss/boot-cljs/wiki/Usage#multiple-builds> for > more information on cljs.edn files. > > From > https://github.com/aatree/aaworker/wiki/Compiling-with-Optimizations-None > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
