Fork me on GitHub
#cljs-dev
<
2017-04-26
>
oahner21:04:00

(.doesNotExist js/document) generates a warning with *warn-on-infer* while (js/document.doesNotExist) doesn't

oahner21:04:17

the latter isn't converted to a dot form at some point?

oahner21:04:04

ah, nvm, it's not

richiardiandrea21:04:32

Don't want to trigger a flame here, but I am reading this: http://exploringjs.com/es6/ch_modules.html#static-module-structure and I was wondering if it could be beneficial to emit ES6 modules (and if not, why...if somebody has some little time to explain) in ClojureScript.

thheller21:04:08

@richiardiandrea what would do you hope to gain by doing so?

richiardiandrea21:04:46

it says modules' static analysis can speed up things (not tested, just wondering)

richiardiandrea21:04:22

but I am now reading this which actually disproves my thought: http://mrale.ph/blog/2012/09/23/grokking-v8-closures-for-fun.html

thheller21:04:42

closure has always had static imports for the reasons they mention

anmonteiro21:04:20

Google Closure

thheller21:04:48

yeah we generate closure compliant code, so its all static

thheller21:04:33

closure js is just annoying to write by hand, which is why nobody is doing that

thheller21:04:44

but ES6 still hasn't addressed the code loading issues

thheller21:04:12

"foo/x" vs "./foo/x" vs "/foo/x" etc

thheller21:04:12

outputting ES6 would make some ES6 interop things easier though, so there is some benefit to that

thheller21:04:43

the current strategy is to pull everything down to ES3 which may not work out in the long run

richiardiandrea21:04:00

gotcha, thanks for explaining that, so if I understand right you'd use goog.provide and goog.require in order to get what then has become ES6 modules

thheller21:04:33

goog.provide equals exports. goog.require equals import

richiardiandrea21:04:51

awesome thanks a lot for taking the time for the clarification

thheller21:04:07

closure even supports some hacks like import { assoc } from "goog:cljs.core" but that requires compiling the ES6 code with closure

richiardiandrea21:04:43

oh nice, that's good to know

richiardiandrea21:04:37

we are evaluating languages and one of the things that I am often asked is about the verbose and hard to read output we have in cljs

richiardiandrea21:04:47

I am of course pushing it

richiardiandrea21:04:58

because I don't care about the JS output 😄

thheller21:04:59

you really don't need to ever read it though

richiardiandrea21:04:23

just want to support the thought with something concrete 😄

darwin21:04:00

more precisely: you really don’t need to ever read generated code unless you do hurtrealbad

thheller21:04:42

there haven't been any "real" code generation issues for years

oahner21:04:43

externs inference significantly reduces the need to poke at the generated code

richiardiandrea21:04:44

@darwin I think that's exactly the concern, when you eventually need to, and your code needs a hot patch and some JS dev on the other side of the world will open that .js file there

richiardiandrea21:04:42

but of course, it is part of the tradeoffs you have to evaluate when choosing your language

thheller21:04:44

yes externs can cause troubles

darwin21:04:32

@richiardiandrea exactly, let’s not fool ourselves, there are costs to generated code (I’m personally willing to pay the price tough)

darwin21:04:48

the benefits are much greater for me

thheller21:04:33

I never tried it but I think if you run the generated JS through prettier it shouldn't look all that bad

richiardiandrea21:04:04

but yeah the benefits for me have always won the battle

thheller21:04:48

those code examples wouldn't look much different in CLJS

oahner22:04:51

the JS output would tho

oahner22:04:24

altho the closure optimized result is awesome

thheller22:04:09

the optimized output always looks like gibberish but if you compare the :none compiled code it looks quite alright

thheller22:04:38

but optimized bucklescript will look like gibberish as well