Hard to say what you are doing without seeing the config. Your config is
doing this, neither lein or shadow-cljs will do this on their own.
I typically recommend keeping things separate since that make things much
easier to understand and debug.
shadow-cljs release app && lein ring uberjar
You are passing a CLJS map into the js/google.maps.Map. call. Convert it
via (clj->js {:center ...}) first or use the #js literal.
On Wednesday, June 24, 2020 at 8:35:14 AM UTC+2, Casey Sparrow wrote:
>
> I have the following function that loads the google maps api:
>
> ```
> (defn
020 at 8:33:16 PM UTC+2, Scott Klarenbach wrote:
>
> I'm super happy and impressed with shadow-cljs, it has radically improved
> my workflow and deployments, and exposed the npm universe without
> ballooning my js files...so, thanks very much to Thomas Heller,
>
> I'm havin
I'm assuming you are trying a .js file that has
import React from "react";
This would try to access the default export of react. Since react only
ships CommonJS it has no default export. CommonJS and ESM interop is in a
weird spot currently and a bit ugly.
import * as React from "react";
Hey,
first of all :stable-names has nothing to do with this. It only attempts to
keep the names stable between compiles, meaning that it will try to re-use
the same shortened name on a recompile. It'll still shorten though.
The issue you need to google is externs and externs inference.
See
Thanks for the detailed answer. Does it somewhat mean that splitting code
> into smaller namespaces can achieve faster compilation thanks to
> parallelization ?
>
>
> On Fri, Jan 17, 2020 at 10:43 AM Thomas Heller > wrote:
>
>> It depends on the namespaces used. In g
It depends on the namespaces used. In general a CLJS namespaces can only be
compiled once all its dependencies have been compiled. So if those
dependendencies can be compiled in parallel they will use multiple threads
from a pool, which should keep all cores busy. In my experience a good
You cannot really inject a shadow-cljs dev build into any arbitrary page.
It is not designed for that and will potentially conflict with the page
itself in bad ways.
You can set :devtools {:devtools-url "https://your.host:23456"} to
overwrite where the socket is trying to connect to. The
That still does not allow you to do anything you couldn't do via the ns
form directly. require outside ns is a misleading topic and is still
completely static. It was just added to allow compiling scripts that don't
have a ns form. You still can't do conditionals or run any other code
What you are trying to do in include-if-present is not possible in CLJS.
require is completely static and you can't do dynamic require outside the
REPL.
On Friday, February 8, 2019 at 9:43:03 AM UTC+1, Henry Widd wrote:
>
> I'm trying to write some code (to run at compilation time) that will
To me that still sounds like you are missing a (cljs.loader/set-loaded!
:components1) call in my-app.components.common.components1. Each module
must call set-loaded! at some point. In shadow-cljs this is taken care of
automatically but CLJS otherwise requires that you do this manually. If you
In standard CLJS you must add a manual call to let the runtime know that
your module finished loading.
(cljs.loader/set-loaded! :a)
Somewhere near the "end" of your modules. Only with this call will the
runtime continue loading the code.
https://clojurescript.org/guides/code-splitting
--
You didn't show your config but did you correctly configure that :a depends
on :b? eg. :depends-on #{:b}? That can't be inferred so you must manually
configure it.
On Friday, February 1, 2019 at 1:11:20 PM UTC+1, Khalid Jebbari wrote:
>
> In case it wasn't clear, the javascript file for
On Friday, February 1, 2019 at 5:54:13 AM UTC+1, Khalid Jebbari wrote:
>
> Can it make bundles smaller ?
>
Yes in theory, but only by a very small fraction. The cljs.core/str macro
may emit less code in certain situations for example but after :advanced
optimizations the difference will be
Did you look into using Code Splitting aka :modules to reduce the size of
the initial download?
Did you check where your 170KB actually come from? Including things like
cljs.pprint can add quite a bit and isn't commonly used in production
builds but can't be DCE'd (yet), similarly other
>
>
> The three second compile time is with :compile-dependents false,
> :optimizations :none and :parallel-build true. I would love to know if that
> is atypical and what I might have set up wrong.
>
>
It sounds slow but it really depends on what you are doing in the code.
Typically using a
You can use `cljs.util/debug-prn` if you need to print during macro
expansion.
Whether or not this should be called a bug I don't know.
On Monday, August 13, 2018 at 8:41:05 AM UTC+2, Philos Kim wrote:
>
> I wrote a macro in ClojureScript and wanted to test the macro by using
> println
ations
> there)
>
> On Friday, May 25, 2018 at 11:22:26 AM UTC-5, Thomas Heller wrote:
>>
>> Yes, core.async is not great for this but it was also not meant for this.
>> The big abstraction there are channels or CSP. There are "zero" channels
ergonomics matter!
>
> On Friday, May 25, 2018 at 3:28:49 AM UTC-5, Thomas Heller wrote:
>>
>>
>>> not quite! core.async doesn't allow you to cancel a go-block (to my
>>> knowledge), which JS allows. I added a section on this:
>>>
>&
>
>
> not quite! core.async doesn't allow you to cancel a go-block (to my
> knowledge), which JS allows. I added a section on this:
>
>
> https://beta.observablehq.com/@shaunlebron/proposal-generators-and-async-functions-in-clojurescript#coreasync
>
>
This is incorrect. Closing a channel can be
I'm generally in favor of "embracing the host" but both generators and
async/await would probably require substantial rewrites of core parts of
the compiler. It it not just about adding a small *** or *async* keyword
somewhere. The compiler will generally emit anonymous functions at various
Clojure follows the principle of "Garbage in, Garbage out" for a lot of
internal functions. Meaning you are responsible for ensuring that you only
use valid data when calling those functions as the validation itself
carries overhead which the core fns should not have.
:a/0 fails because the
I answered a similar question a while ago:
https://groups.google.com/d/msg/clojurescript/Gk1XA0aIxJM/Ixu45z-wkEoJ
On Friday, February 23, 2018 at 7:06:43 PM UTC+1, Khalid Jebbari wrote:
>
> Hello,
>
> Say I have 2 namespaces in CLJS/CLJC, A and B. A requires B explicitly.
>
> I want to produce a
You can use it with Java9 today if you add a little flag to the command line
Instead of calling
java -cp cljs.jar:src clojure.main build.clj
you call
java --add-modules java.xml.bind -cp cljs.jar:src clojure.main build.clj
That should fix it. The Java9 fix was already applied to ClojureScript
This is a Java9 error. It was fixed recently but has not been released yet.
You can either add "--add-modules java.xml.bind" to the java cmd arguments
or downgrade to Java 8.
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this
IMHO :foreign-libs do too many things these days and its not clear what to
use when or how. This feature is alpha so I expect that everything will be
sorted out properly in the future. I fully expect the "flaws" to be
addressed.
:foreign-libs used to refer to "foreign JS" that was not
The Closure Compiler is fully capable of this. It appears that something is
broken, don't know what.
In shadow-cljs [1] I handle JS dependencies quite differently so not only
does this work there it is also much simpler (IMHO).
I made a demo showcasing all of the JS interop here:
I implemented a new solution for dealing with JS dependencies in a browser
context.
In short it trades a few potential byte savings for greater compatibility
with the npm ecosystem.
I wrote about it here:
https://code.thheller.com/blog/shadow-cljs/2017/09/15/js-dependencies-going-forward.html
*“Seamless interaction with NPM” not so seamless*
This has been exactly my experience as well which is why I wrote an
entirely new implementation for JS dependencies.
The detailed article can be found here
https://code.thheller.com/blog/shadow-cljs/2017/09/15/js-dependencies-going-forward.html
The usual CLJS tools do not support this but shadow-cljs [1] does.
Closure has a variable and property map feature that will save the names it
used on one compile which can then be imported on the next compile.
shadow-cljs does this automatically and as long as you don't remove the map
files
You can easily achieve this by creating a CLJS namespace that self-requires
the macros. Having dedicated .macros namespaces is generally not
recommended.
pixi/something.cljs
(ns pixi.something
(:require-macros [pixi.something]))
pixi/something.clj
(ns pixi.something)
(defmacro foo [..] ..)
> Yes. Currently optimization is something we are doing when compiling
> clojurescript, but perhaps *ideally* optimization could be done after
> bundling when all the javascript is available. However, I realize this
> may not actually work very well in practice since most modern js
>
Hey,
I understand what you want to achieve and I definitely want to make the
whole thing easier but some issues don't have an easy solution.
TL;DR: It's complicated.
First we need to split compilation and bundling.
CLJS->JS compilation just takes one .cljs file and compiles it to .js. To
do
.
├── build.clj
├── cljs.jar
└── src
└── hello_world
└── core.cljs
Forgot the build.clj.
On Friday, June 16, 2017 at 9:05:14 PM UTC+2, Thomas Heller wrote:
>
> ├── cljs.jar
> └── src
> └── hello_world
> └── core.cljs
>
>
> This is the structure yo
├── cljs.jar
└── src
└── hello_world
└── core.cljs
This is the structure you should have. Its a bit confusing since you have
src\hello_world\src.
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message
C:\Users\Michael\Documents\src\hello_world>java -cp "cljs.jar;src" clojure.main
node.clj
Don't run java in the hello world directory. Run it in C:\Users\Michael\
Documents
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this
I made a quick video showing how you'd use what we have talked about here
with "create-react-app".
https://www.youtube.com/watch?v=BLDX5Twt2zk
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed
The shadow-cljs compiler already does the correct thing when it comes to macros
and recompiles all affected CLJS files.
It does however know nothing about JS files that may be affected as well so it
would not reload those. I don't know if the webpack HMR will reload dependent
files?
Does it
Quick Update: Just renamed the repo/artifact to thheller/shadow-cljs. Got tired
of having to differentiate between shadow-devtools and shadow-cljs.
Release coming later today.
Github should take care of redirecting all the old links.
This is the new home:
On Wednesday, May 17, 2017 at 3:51:14 AM UTC+2, Jiyin Yiyong wrote:
> I don't like the way of writing `x.assoc(null, 'foo', 'bar')` by myself. Also
> I don't people would accept that.
>
I wouldn't as well, but that was an example to show that you can use CLJS code
directly without modifying
On Tuesday, May 16, 2017 at 8:27:44 PM UTC+2, Thomas Heller wrote:
> If I understand correctly the short answer is: no.
>
I should add: You can use shadow-cljs in your coffeescript project if you just
want to use cljs.core or some other CLJS package. You do not need to write CLJS
yo
└── package.json
> ```
>
>
> if it's in this way, `target/` can be released on npm as a module and others
> surely may use `require('package_name/demo/main.js')` to load the package
> built from ClojureScript.
>
>
>
>
>
>
> On Wed, May 17
I wrote a short introduction here:
https://github.com/thheller/shadow-devtools/wiki/ClojureScript-for-JS-Devs
Looking for any kind of feedback.
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you are subscribed
Too tired to make a proper announcement but I just pushed the first preview
version of the shadow-cljs npm package.
https://www.npmjs.com/package/shadow-cljs
npm install -g shadow-cljs
shadow-cljs --once
node
var x = require("shadow-cljs/cljs.core");
x.enable_console_print_BANG_(); // oops
>
> I think it should be possible to use closure-compiler-js [1] with this
> project to do DCE if needed.
>
In a way you can and you can't. The same way :npm-deps has issues.
The Closure Compiler (JS or JVM version, doesn't matter) is not yet capable of
compiling everything in the npm
Also removed all traces of lein, the examples now just use an uberjar of
shadow-devtools.
Certainly not the final solution I have in mind but getting closer.
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message because you
I just did a quick test for React Native.
https://github.com/thheller/npm-module-example/tree/master/examples/react-native-example
Since it is the first time I started react-native I really have no idea what is
going. It works but is extremely slow to start. I don't know why, just wanted
to
On Monday, May 15, 2017 at 8:30:26 AM UTC+2, Shaun LeBron wrote:
> > The example still uses leiningen by I may drop that and create something
> > standalone.
>
> I'd like to show you around my "cljs/tool" some time for your standalone
> thing. I'm a year into building it to wrap a good UX
Yes, currently it is just shadow-devtools via lein. Could also run it through
boot, no problem.
I want to package it all up so you can "npm install shadow-npm".
Need to figure out how to best do that first though. Should probably also chose
a better name.
--
Note that posts from new members
Just added another example that shows how you'd use CLJS in a create-react-app
setup.
https://github.com/thheller/npm-module-example/tree/master/examples/create-react-app
--
Note that posts from new members are moderated - please be patient with your
first post.
---
You received this message
I started a new topic [1] for the implementation.
You can find an example here:
https://github.com/thheller/npm-module-example
I'd be very interested in feedback from people that actually use webpack
already.
[1] https://groups.google.com/forum/?fromgroups#!topic/clojurescript/AGXku7Ous0Y
--
Hello,
I wrote a few lines of code that should hopefully make it easier to get started
with CLJS for people coming from the JS world.
I created a demo here:
https://github.com/thheller/npm-module-example
The gist is that you gain: var foo = require("shadow-npm/demo.foo");
Where "shadow-npm"
> I'll probably write the simple version today and see how things work out.
So the simple version sort of works.
http://thheller.com/webpack-cljs-preview/index.html
http://thheller.com/webpack-cljs-preview/bundle.js
This was generated by "webpack -d" and
index.js:
---
var foo =
On Saturday, May 13, 2017 at 3:47:01 AM UTC+2, Jiyin Yiyong wrote:
> Cool Hope one day it's in Lumo too XD
Not by me but the features could certainly be ported.
I spent quite a bit of time yesterday fighting through webpack sources trying
to come up with an efficient way of doing things.
> However I think it's not we current have for all ClojureScript users, since
> it's implemented by yourself based on lein
That is incorrect. It is a pure Clojure library with no dependency on
leiningen. I just happen to use leiningen and do not know enough about boot to
create proper
ng time caching and code
> splitting with only several lines of code, with assets(images, fronts)
> bundling out of box. Hard to imagine we sell those people ClojureScript
> without competitive features.
>
>
> It would still be awesome if you can share about code splitting and
I'm way too biased towards the Closure Compiler and giving that up is simply
not an option for me. I am however very interested in making things simpler for
everyone.
https://github.com/thheller/shadow-devtools/wiki/ClojureScript-for-node.js-libraries
This is an example of how I intend to do
IMHO the webpack ecosystem and CLJS can live happily side by side, why is it
important that they know about each other? Good JS interop ensures that both
sides can interact well.
What would you expect from a loader that you'd be willing to give up the
Closure Compiler?
On Thursday, May 11,
That is done by reagent when it interprets the vector created by
datetime-picker.
Not a CLJS feature.
On Thursday, April 27, 2017 at 10:04:35 AM UTC+2, Jochen wrote:
> Hi…
>
> for a few days I am evaluating clojurescript/reagent et.Al.. I just got
> integrated all the bits and pieces like
On Tuesday, April 4, 2017 at 6:09:52 PM UTC+2, Shaun LeBron wrote:
> typo: use "dev" instead of "release" for the full blown dev experience:
> rlwrap lein run -m shadow.cljs.devtools.cli/dev script
Thanks Shaun, a typo indeed.
I wrote some more things down in the wiki:
This thing I wrote is getting to a point where it might be useful to someone
else. It might make your CLJS life a bit easier.
I have been using my own CLJS tooling (shadow-build) for over 3 years now, it
had some of lein-figwheel's features that I never talked about but frankly
lein-figwheel
On Thursday, March 16, 2017 at 6:55:44 PM UTC+1, rgde...@gmail.com wrote:
> Thanks for pointing me to your library and to the other thread, I'll take a
> look!
>
> In general, I disagree that a string-based solution is strictly worse than a
> map-based solution, since using strings can help the
On Thursday, February 16, 2017 at 6:40:41 PM UTC+1, Dustin Getz wrote:
> My expectation is the compiler, when it sees `(def foo #DbId [1 2])` will
> emit javascript equal to `(def foo (hypercrud.types/read-DbId [1 2])`
Your assumption is incorrect. I cannot answer your question since I have not
:verbose true
>:compiler-stats true}}
>
> and our lein profile is
>
> :ci {:env {:test-multiplier "0.5"} ; environ variable
> :jvm-opts ^:replace ["-Xms1024m" "-Xmx1024m" "-server" "-Xss2m"]
>
> I was una
Are you by any chance using anything other than {:optimizations :none} in your
dev build config? 12s seems a bit excessive if you are just doing CLJS
recompiles.
Ensure that your dev build does not use any production build settings. Your CI
server should probably run in production mode though
I actually spent a whole bunch of time thinking about the tradeoffs. The
project has not been in production for that long so my experience is a bit
limited. So for now things are heavy on the theory. I actually just had a fun
idea last night and wrote to the closure compiler guys just now.
On Monday, February 6, 2017 at 7:15:49 PM UTC+1, mynomoto wrote:
> Hello,
>
> After seeing this message, we extracted a library from work that uses garden
> and adds the style when the component is rendered (when using React). Code
> currently lives at
>
> Thanks got it. My mistake was mixing reagent's markup with yours. Would you
> say this is an alternative, similar to how shadow.markup relates to om.dom?
Yes. While I like the hiccup-ish reagent syntax it does present some
performance issues.
In reagent you first allocate a bunch of
> Cheers Thomas. When you have the likes of a containing element. How do you
> handle the wrap when defstyled returns a ReactElement?
>
> (defstyled container :div
> [_]
> {:display "flex"})
Not sure I understand the question? ReactElements can have children, which this
fully supports.
Just define them inside the element.
(defstyled h1 :h1
[_]
{:color "red"
"@media (max-width: 600px)"
{:color "green"}})
Or put the query inside a def, so you can re-use it.
FWIW I did a quick test to see if things worked with reagent. Turns out they do.
Basically works out of the box:
https://github.com/thheller/reagent-test
The dependency on Clojure 1.9 was not intentional and I would remove it if
anyone wants to use this with 1.8.
Anyways feel free to clone the
As I said I haven't used garden, can't say how much of a difference there is.
One thing I can't change is that selectors have to be strings, they are
keywords in garden. The maps of css properties should be portable though and
you shouldn't really need the selectors after?
As for re-using css
I looked at garden but never used it. It seems like a direct alternative to
SCSS/Less, but nothing more.
The intent of shadow.markup (sorry, couldn't think of a better name yet) is
that I basically never want to write a single selector ever again. There are
several cases where this is still
Hello,
I'm not sure how many of you are in this horrible situation where you have to
write CSS for your React Components. I typically have to write way more than
I'd like and always hated the way I wrote it. Until a few weeks ago.
I wrote this thing and so far I really like it. Too early to
You are correct, no defmethod is ever removed by Closure (and can't be really).
You can use :modules to spread them into multiple files, whether or not that is
useful depends on your project. Protocols are Closure-compatible and might be
an alternate solution if you are worried about code size.
I had a similar idea a while back which I called "compact" mode. It would just
concatenate all files into one big JS file that would be included in the page.
To my surprise this wasn't much faster. Turns out that loading a 6MB JS file
(:none) is not much faster than loading 50+ smaller files.
e core runtimes the same
> way I do jquery - deploy a :simple version once to the client, and rarely
> have to send again. Even in :advanced mode, a lot of redundant cljs/closure
> code is resent to the client each time any tiny part of my app.js changes.
>
> Thanks,
> Scott.
>
Hey,
I have done quite a few experiments over the years and these would be my
general recommendations.
TL;DR: Embrace :advanced fully, keep non-cljs/closure out of your build, mind
your dependencies, use closure modules to split code.
Most things really depend on your app and your general
Just guessing but
com.google.javascript.jscomp.VarCheck$RedeclarationCheckHandler.onRedeclaration(VarCheck.java:380)
This looks like you maybe have another extern somewhere that tries to declare
the coordorigin property. Might be on Object.prototype.coordorigin as this
would conflict with
You can have concurrency without parallelism.
core.async is "A Clojure library designed to provide facilities for async
programming and communication". Parallelism is just a bonus side-effect, but
not required or even the goal. Reducers for example have the goal of
parallelism over
The :context basically tells the compiler if the return value is required
(:statement vs. :expr). A :statement does not need to return something and "if"
in javascript does not return something.
If an "if" is compiled with :expr it generates (condition ? yes : no) instead
of "if" for
Hey,
the .cirru code looks quite foreign but I guess I can kinda see what is going
on. cljs$core$next is probably not what is slow here, next when working on a
lazy seq will realize the next entry. So while next is fast the actual work
that happens is "slow". Flame Graphs are generally better
https://github.com/clojure/clojurescript/wiki/Quick-Start
should be done at least once, regardless of whether you are using a template or
not. It helps clearing up a few things that need to be done in order to get a
working setup. Templates make you skip this step but it is important to
If you want you can try shadow-build. It supports modules all the way (ie.
:none). It has some figwheel-ish features (REPL, live-reload) but basically no
documentation, so a little patience is required. It is pretty simple, just very
different from other build tools.
See:
Technically there is nothing holding you back from using :advanced on node, IF
you supply all externs that is. And this is where the problem lies, you cannot
easily provide externs since the closure compiler doesn't understand "require"
properly.
CloSure assumes there is one global namespace
On Tuesday, December 8, 2015 at 12:25:24 AM UTC+1, ewen wrote:
> Would you also consider a patch to make the :main option to accept a
> collection of namespaces?
shadow-build is fine with that, expects it in fact. Not really sure why cljs
allows multiple :entries per :module but :main only
You can try shadow-build [1], one of my goals was to make switching between
dev/prod as simple as possible without requiring any code/html changes. It also
addresses some other things not related to modules but still helpful to make
dev/production builds as smooth as possible.
Docs are lacking
Hey,
my advice would be to use a post-process step instead of trying to making it go
through the closure compiler. Not only will that produce headaches but the
generated CLJS->JS also does not match the expected structure for UMD exports.
You'd need to tag the functions you want to have
This is very likely to break :advanced optimisations, did you test that yet?
Probably not what you are looking for but there is a "goog.ui.Textarea" [1,2]
in the closure library which does the auto-sizing as well. Should be pretty
straighforward to make a react-wrapper for it.
HTH,
/thomas
know is what
> is best for ClojureScript.
>
> Thanks in advance, Leon.
>
>
> On Friday, October 30, 2015 at 9:54:01 AM UTC+1, Thomas Heller wrote:
> > This is very likely to break :advanced optimisations, did you test that yet?
> >
> > Probably not what you
Are you using whitespace optimization during development? You should really be
using :none which usually means compilation times in milliseconds.
Do you have any information on the kind of hardware the compile runs on? The
numbers look horrible. Since you say heroku I imagine a VM in the Cloud
as I'm aware.
You'll probably need to change the server side response.
On Saturday, September 12, 2015 at 8:53:59 PM UTC+2, Hari Krishnan wrote:
> On Saturday, September 12, 2015 at 2:11:31 AM UTC-7, Thomas Heller wrote:
> > You are using an ajax request which does not follow the s
You are using an ajax request which does not follow the same rules as a normal
browser navigation requests. It will not follow redirects for example.
I don't know what ajax lib you are using but the general solution will be:
fire request
wait for response
check response code of request
if
Hmm I think you have those confused.
Take the equivalent from Java:
class MyClass {
}
MyClass x = new MyClass();
Class y = MyClass.class;
or JS:
var MyClass = function() { /* ctor */ };
var inst = new MyClass()
inst != MyClass
inst.prototype == MyClass
inst is an instance of MyClass
For a little JavaScript WTF and one reason why things are the way the are:
Number.prototype.whatAmI = function() { return typeof(this); };
var x = 1;
x.whatAmI();
"object"
typeof(x)
"number"
Fun times debugging that ...
Cheers,
/thomas
--
Note that posts from new members are moderated -
> The point I wanted to make is 'this' without 'new' will refer to the object
> the function is defined on be it 'window' or whatever object.
>
That is incorrect. "this" is the actual number, not window. new or not.
Behavior is probably different for other types. ;)
Number.prototype.addFive
Well, while we are on the topic perhaps we should mention the downside of using
Web Workers. For me it has been Data Transfer.
Since you can only transfer JSON type data between workers that usually meant
you had to pr-str/read-string to roundtrip CLJS data. If you only have very
small amounts
On Wednesday, August 26, 2015 at 1:29:38 PM UTC+2, Daniel Kersten wrote:
If you can use newer browser, you've got Transferrable Object to transfer
binary data with zero-copy.
True but I was talking about CLJS data which isn't binary.
Agreed, its probably a bit of work. I guess that
This has nothing to do with core.async or the go macro. If you block the CPU
you will block the UI. The browser does not support threads so neither can
core.async.
What the timeout achieves is that you give some control back to the browser so
instead of 1sec blocking you get 5x200ms blocking.
On Tuesday, August 25, 2015 at 10:59:53 AM UTC+2, Daniel Kersten wrote:
The browser does not support threads so neither can core.async.
To expand on that, core.async uses cooperative multitasking, which means you
have to give control back every so often so it can schedule other go blocks
1 - 100 of 174 matches
Mail list logo
