Is there a reason why clj->js uses doseq to build up #js arrays instead of reduce which is faster ?

@superstructor probably historical reasons. if you see reduce is faster, please create a ticket with benchmarks

if we verify it's faster I'm sure it'll be considered

Apparently I should discuss CLJS-1986 (es6 generators) here

i wanted them for a build tool i'm writing in cljs. async/await will be supported in node soon and this is a stepping stone towards that

given that google closure supports transpiling them to es3, i'm not sure what the problem is

@jjl one issue is that while in development most people are using :none which does not go through closure

i considered that. i think most people develop against a modern browser

so it will break if their browser doesn't support it

also you need to actually use that feature

I have to run everything I do in IE10

which doesn't have await

neither does node yet (except on master). this is generators (function*, yield)

its also a dependency issue .. a library I may want to use may use it

nod. my use case was for node. i don't think it's such a compelling feature in the browser

this is for macchiato btw

people tend to use things they read about .. so if someone reads that CLJS does support await they will start using it

if we follow that reasoning, we never get any new things

and maybe miss the browser support issue

FWIW I think core.async is 10x better than await

i think forcing core.async upon users isn't a good thing in a library

it may look like it does the same thing but the core.async channels are so powerful

well forcing generators isn't any different?

forcing generators doesn't require you to ship another whole library

maybe once it supported everywhere ... until then you'd require the user to always use Closure even in development

if they used that feature, yes

like I said .. even if you put warning labels on things .. people will use it

"if your project (or a dependency thereof) uses this feature, you need to add this to your compiler options"

actually i think being able to tell closure what version of es to compile for would be nice

you can already do that part

oh there's an option for it?

neat

:language-in :language-out

okay, so if the user has that and :optimizations :simple in dev, they would be able to use this feature with this patch and still run it on ie10

so i suppose the next question is "how expensive is simple optimisation?"

any optimization other than :none breaks live reloading

ah

is that an intractable problem?

sort of .. with :simple or even :whitespace you just get one file

so you always reload everything instead of just one file

I'm sure that will cause a bunch of problems

hrm. i wonder if we can make closure not do that

well I suppose you could create a new compiler mode

than would process every compiled CLJS file with closure

in a 'do nothing except transpile' mode

yeah, that is basically what the js-modules stuff does

except processing other the .js not the generated js from .cljs of course

okay. that seems like something i could probably do

but FWIW I think it would be far more valuable to have everyone use core.async instead of adopting the many different async patterns there are in JS land

YMMV of course

but given that the JS world will still do its thing we have do adopt it anyways in some form

this is my concern

I don't know .. not my call to make

i want to play with them

you could probably do what you are doing in a library

i definitely don't want cljs to get left behind new features because despite being so futuristic we stick to generating code that is N major versions behind

i think that would be difficult

(in fact i don't believe it's possible)

you'd be surprised whats possible with a few with-redefs 😉

correction; i don't believe it's possible without making me not want to use that library

I have a completely different (ns ...) handling than the default CLJS in shadow-build

what does yours do?

stricter parsing, less side effects

doesn't matter .. the end result is the same. Just an example of whats possible 😉

sure, but i'm not feeling like maintaining a fork just to get features i can have in javascript

not a fork, but yes everyone wanting to use that would need to use your hack

or even maintaining a set of ugly hax

so it is dirty 😉

maybe you should try your patch in a fork

and create some compelling examples why its a good idea to have generators

my compelling reason is "we're gonna have es7 soon, why can't we have things javascript can have?"

also my main alternative is node fibers and ewwwww

well .. we have something better already ... that is supported everywhere

will node rewrite everything to promises instead of callbacks?

there are wrappers in js already. it'll take time for node to migrate all the libs

so what is missing is a wrapper in CLJS to core.async? 😉

i dunno, you seem pretty obsessed with only having one option to choose from

have you used core.async? beyond the basics? I mean transducers in channels, alt!, etc?

no, i've only done the basics. but it's totally overkill for what i need

what do you need? other than what (<! something) gives you?

pretty much that. i do not want to use core async.

Personally, I'd love to see async/yield/await support in cljs. I primarily use Promises for async stuff.

yeah might be useful. I don't know. I'm working with about 50/50 CLJ/CLJS and haven't used a single promise, so I'm obviously biased towards core.async.

@dnolen https://github.com/clojure/clojurescript/blob/2171ae9859a2e982497764a04de10916aae68307/src/main/cljs/cljs/core.cljs#L1272-L1293 I got curious on this piece of code. I saw your comment like "TODO: we should remove this", what was the plan about that?

@jjl on second though: you may only yield in generator functions right? that will be problematic with some constructs in CLJS as they introduce inner functions for scoping reasons

this currently only applies to the method of a function (i.e. one arity)

and yes, you will have to restrict yourself somewhat

it is possible we could do some tracking but then it's not such a small patch

@jjl we need to step back, what actually problem is this solving for most users - why do they need a JS feature

any other discussion is completely secondary to that

no rationale, it’s not going to happen - “I want to use it for something I’m doing in Node.js” is not a rationale

Hi I played around with the new js-modules support, pretty awesome stuff. But I seem to hit a bug when I add this library: https://github.com/styled-components/styled-components I would think this is probably an issue with the google-closure-compiler instead of the clojurescript compiler? I am trying to figure out where it's best to put this bugreport...

Where are you encountering the bug?

I get the following warnings when compiling:

WARNING: JSC_JS_MODULE_LOAD_WARNING. Failed to load module "supports-color" at /home/mitchel/Development/styled-om-components/node_modules/styled-components/lib/vendor/postcss/css-syntax-error.js line 9 : 4
WARNING: JSC_JS_MODULE_LOAD_WARNING. Failed to load module "supports-color" at /home/mitchel/Development/styled-om-components/node_modules/styled-components/lib/vendor/postcss/css-syntax-error.js line 9 : 21

And this pretty much seems to break the rest of the stuff that styled-components need

And when I open it in the browser I get errors like this:

Uncaught ReferenceError: module$$home$mitchel$Development$styled_om_components$node_modules$styled_components$lib$vendor$postcss$container is not defined
    at at-rule.js:6
rule.js:4 Uncaught ReferenceError: module$$home$mitchel$Development$styled_om_components$node_modules$styled_components$lib$vendor$postcss$container is not defined
    at rule.js:4
comment.js:5 Uncaught ReferenceError: module$$home$mitchel$Development$styled_om_components$node_modules$styled_components$lib$vendor$postcss$node is not defined
    at comment.js:5
declaration.js:5 Uncaught ReferenceError: module$$home$mitchel$Development$styled_om_components$node_modules$styled_components$lib$vendor$postcss$node is not defined
    at declaration.js:5
parser.js:9 Uncaught ReferenceError: module$$home$mitchel$Development$styled_om_components$node_modules$styled_components$lib$vendor$postcss$root is not defined
    at parser.js:9
parse.js:5 Uncaught ReferenceError: module$$home$mitchel$Development$styled_om_components$node_modules$styled_components$lib$vendor$postcss$input is not defined
    at parse.js:5
root.js:6 Uncaught ReferenceError: module$$home$mitchel$Development$styled_om_components$node_modules$styled_components$lib$vendor$postcss$container is not defined
    at root.js:6
input.js:4 Uncaught ReferenceError: module$$home$mitchel$Development$styled_om_components$node_modules$styled_components$lib$vendor$postcss$css_syntax_error is not defined

You're using the new :npm-dpes compiler option right?

Yes

And I am running from master

It looks like a failure running cljs.closure/node-inputs try requiring styled-components manually (see here https://clojurescript.org/guides/javascript-modules for guide)

You'll need to replace cljs.build.api/node-inputs with cljs.closure/node-inputs

node-inputs will process all your node module dependencies in foreign-libsto pass to ClojureScript

This is necessary to see if this a clojurescript or closure bug?

Yep we want to see if the supports-color module is getting passed in when ClojureScript is importing node modules

Sure I'll try it out do I need to follow the Node Modules Chapter?

You'll want to have this JavaScript file

var Styled = require('styled-components');

module.exports = {
    Styled: Styled
};

and then run this Clojure code

(require '[cljs.closure :as cc])
(require '[ :as io])

(def entry {:file (.getAbsolutePath (io/file "path/to/npm_stuff.js"))
                   :provides ["libs.npm-stuff"]
                    :module-type :commonjs}])

(def foreign-libs
  (into [entry] (cc/node-inputs [entry]))

Then check foreign-libs (it'll be a large vector of files to pass into ClojureScript) for the supports-color module

I've got to get to work I hope this helps

Thank you I am trying it out and will report back

That is weird it seems to do the correct thing:

{:file
  "/home/mitchel/Development/hello-cjs/node_modules/supports-color/browser.js",
  :module-type :commonjs,
  :provides ["supports-color"]}

But when I try this:

(b/build
 (b/inputs "src")
 {:main 'hello-cjs.core
  :output-to "main.js"
  :output-dir "out"
  :externs ["process.js"]
  :foreign-libs foreign-libs
  :optimizations :none
  :closure-warnings {:non-standard-jsdoc :off
                     :global-this :off}})

'use strict';
module.exports = false;

Which seems fine to me

@mitchelkuijpers CLJS does respect the browser field

Yeah I noticed ^^ @anmonteiro the output above proofs it

Is the problem requiring styled-components?

I'll try it out once I get to work

The problem is that once I try to load it in the browser it wont load styled components because it cannot load that module and then everything fails

It's probably too soon to judge whether it's a Closure or CLJS bug

Do you want me to push a minimal reproducible case?

We need to figure out why you're getting the warning in the first place

btw I also put this in the compiler options:

:language-in :ecmascript5

Then you will only get the 2 above warnings

@mitchelkuijpers what version of supports-color is that trying to require?

You can check it by going to your node_modules folder and inspecting the pckage.json

3.2.3

@anmonteiro

Hrm I may have a hunch, need to confirm in front of a computer

Cool, if you need anything from me let me know

@mitchelkuijpers trying it right now

can you tell me the styled-components version?

Yes 1.4.4 @anmonteiro

thanks

@mitchelkuijpers so the problem seems to be with 'use strict’;

Woa that's weird, was that your hunch?

nope

actually..

hrm I might have spoken too early

I just realized I’m probably not running the right version of Closure

Whoops, I have just tried it without use strict and it still breaks

@mitchelkuijpers can’t figure it out right now, and also can’t afford to spend any more time on it today

No problem, thank you for trying @anmonteiro