Fork me on GitHub
#cljs-dev
<
2017-01-27
>
dnolen01:01:16

I cannot believe it ...

dnolen01:01:04

unconfirmed whether it works, but it actually compiled

dnolen01:01:17

and all the dependencies that were used were correctly found

dnolen01:01:02

a little bit hackish at the moment - but very promising

dnolen01:01:58

React from node_modules

dnolen02:01:45

but this confirms my suspicion that trying to integrate with CommonJS NPM modules is kind of dead end

dnolen02:01:51

most exports are dynamic

dnolen02:01:11

so compiling 3rd party CommonJS is a crapshoot

dnolen02:01:23

ES6 just seems way more promising here

dnolen02:01:28

static import & export

dnolen02:01:21

however there’s still some value for people who want to use NPM as their distribution mechanism

dnolen02:01:41

instead of JARs where the JS files they write are Closure CommonJS friendly

dnolen02:01:49

and Node.js friendly at the same time

dnolen02:01:44

hrm or maybe not … I don’t know yet - there maybe something about how we evaluate goog.require under Node.js that is wrong.

superstructor02:01:59

tested latest master (367e2f) against a 20K line reagent/re-frame app and all works fine slightly_smiling_face Noticed initial build time on :simple optimisations increased avg 34 seconds (80->114s) and rebuilding on changes increased avg 10 seconds (~20->30s). @dnolen

dnolen02:01:40

@superstructor I don’t know about :simple since that’s Closure time

dnolen02:01:51

but rebuilding on changes is interesting, will need to hear more information

superstructor02:01:14

should I try optimisations :none and time it again ?

dnolen02:01:17

is time reported by the ClojureScript compiler or something else?

dnolen02:01:25

if something else it’s really not super useful

dnolen02:01:36

since it’s not something I’ll really consider looking at

dnolen02:01:41

it needs to be ClojureScript time only

dnolen02:01:13

ok the node_modules thing works - just a problem with how we bootstrap Node.js

dnolen02:01:59

so that needs some thought but it seeems surmountable

superstructor02:01:56

@dnolen time reported by :compiler-stats true and I think the final “elapsed time” is part of our boot-clj tasks; e.g.

Compiling ClojureScript...
• js/app.js
WARNING: :preloads should only be specified with :none optimizations
Compile sources, elapsed time: 545.27221 msecs
Compile sources, elapsed time: 153.117463 msecs
Optimizing with Google Closure Compiler, elapsed time: 11372.209861 msecs
Optimizing 490 sources, elapsed time: 28017.807772 msecs
Writing target dir(s)...
Elapsed time: 30.921 sec

dnolen02:01:33

@superstructor like I said anything in Google Closure time is not something we can do too much about

dnolen02:01:33

it’s also nearly impossible to swap out Google Closure since they make breaking changes and we are often pinned to a particular one since we integrate so tightly

dnolen02:01:58

@superstructor I’d be more interested in :none time

superstructor02:01:27

@dnolen ok thanks I’ll do some tests on :none time and see if there is a substantial difference between versions.

dnolen03:01:09

if you use Node.js you should definitely give it a spin

dnolen03:01:39

prep stuff for node_modules support

dnolen03:01:06

I just advanced compiled a project that uses node_modules

dnolen03:01:04

and React works

superstructor03:01:03

@dnolen so on :none the compile sources phase actually appears to be slightly faster (if anything) going from 293 -> master. Just the Google Closure optimisation phase on :simple and above that appears to have slowed down, so I understand thats not in scope of CLJS. Thanks :thumbsup:

dnolen03:01:54

so this stuff really just works

dnolen03:01:25

but externs are definitely going to be an issue - but funny cljsjs kind of solves that problem

dnolen03:01:30

you can include those deps just for the externs

dnolen03:01:40

using Facebooks own optimized dependencies

dnolen03:01:46

53K gzipped for React + React DOM Server

dnolen03:01:42

advanced compiling ClojureScript from node_modules, including a good chunk of cljs core via the usage of a persistent vector and the println stuff - 66K gzipped

dnolen03:01:09

exciting times ahead, exciting times

mfikes03:01:49

Almost fits on a Commodore 64!

anmonteiro04:01:34

curious why you had to remove cljs.nodejs/process and cljs.nodejs/require

anmonteiro04:01:48

that may be a breaking change for people on Node

dnolen05:01:17

@anmonteiro yes it will be a breaking change

dnolen05:01:47

basically the problem is that Google Closure stuff has to globally required

dnolen05:01:04

when we globally require we need to disable goofy JS detection of the Node environment

dnolen05:01:14

we do this by erasing module and exports

anmonteiro05:01:26

oh right. I know what you're talking about

anmonteiro05:01:29

I do the same in Lumo

anmonteiro05:01:52

@dnolen btw, I just discovered why Lumo isn't building. Got one more patch before tomorrow's release. Attaching it now

dnolen05:01:54

I don’t want to break what people are doing with Node.js too much, so people need to try it

dnolen05:01:00

just want to see what the balance is

dnolen05:01:23

if it turns out these changes are too aggressive we’ll make some kind of compromise

dnolen05:01:39

but so far I’m thinking that being able to consume Node.js deps without losing your mind is a huge win

mfikes05:01:50

A TL;DR view of CLJS-1909 is that is strangely reaches into macro-land, and then accidentally back out into runtime.

anmonteiro05:01:20

@dnolen right. fortunately these breaking changes are fairly easy to spot

anmonteiro05:01:55

Right. As @mfikes said it's an edge case that only occurs in self-host

dnolen05:01:57

the other cool thing is that when the Nodes JS stuff resolution lands for ES6

mfikes05:01:58

António’s CLJS-1909 patch sidesteps the issue

dnolen05:01:01

there’s nothing for us to do

anmonteiro05:01:09

which is why it was hard to figure out

dnolen05:01:41

I’ve banging my head all week on how people could write ES6 modules

dnolen05:01:50

like import as React from “react”

dnolen05:01:55

but now the answer is obvious

dnolen05:01:57

it will just work

anmonteiro05:01:06

this is a game changer. I'm really excited to try it out

anmonteiro05:01:23

hopefully I'll have some time over the weekend

dnolen05:01:49

yes I think so

dnolen05:01:06

between this & externs inference our integration story improved by at least an order of magnitude

anmonteiro05:01:39

yes, you've been hard at work

mfikes05:01:45

Sounds like some well-received blog posts are in order on the subjects 🙂

mfikes05:01:43

Never enough time 🙂

dnolen05:01:51

it’s going to take a while to really understand what the best way forward is

dnolen05:01:04

but at least we know it’s A) possible B) likely practical

anmonteiro05:01:57

but I wouldn't recommend putting it in this release. Probably need to try it out again and report back

dnolen05:01:06

ok, thanks will take a look tomorrow

richiardiandrea05:01:44

Funny because at our Vancouver meetup today we where using nodejs/require a lot: https://github.com/paullucas/lumo-misc/blob/master/http.cljs

richiardiandrea05:01:56

I guess it won't be possible anymore

anmonteiro05:01:02

the use case in question is consuming e.g. React

dnolen05:01:24

@richiardiandrea that thing was annoying anyway

dnolen05:01:31

from the very few months of ClojureScript

dnolen05:01:44

everything about how we interact with Node.js kinda stinks

anmonteiro05:01:50

they have a dev bundle which doesn't strip away some checks when compiling with :advanced

richiardiandrea05:01:58

You know, actually yes 👍

dnolen05:01:22

@richiardiandrea I’d like the Node.js integration to be a lot simpler

dnolen05:01:33

if we’re going to break a few minor things, it’s a good time to consider how to make it better

richiardiandrea05:01:03

At work we are going to probably write a big chunk of code using cljs on Node.js, so I am very excited about this, thanks

dnolen05:01:50

well making Node.js target simpler is one thing

dnolen05:01:11

if you don’t need to target the browser require is fine

dnolen05:01:20

and I don’t want to break that - so people should test

dnolen05:01:26

js/require is what I mean

dnolen05:01:35

the other thing is that people use NPM for doing client side stuff

dnolen05:01:43

and we don’t have good integration with that

dnolen05:01:49

that’s the thing I’m actually working on

richiardiandrea05:01:04

Oh okay, will test that, got it

dnolen05:01:11

if you’re doing everything in Node.js for server side - life is pretty simple already

dnolen05:01:14

a lot less to worry

richiardiandrea05:01:30

We are about to, and actually estimating if it is a good choice, but because we are targeting AWS lamdba it is kind of the only choice if you want to keep using Clojure

dnolen05:01:51

well try master please, and report 🙂

richiardiandrea05:01:38

So I have to say that these new patches are actually solidifying my proposal (which I am kind of pushing) and could not come in a better moment 😀

anmonteiro05:01:10

@richiardiandrea could you run Lumo scripts on AWS for example?

anmonteiro05:01:43

I'm not suggesting you do, just asking because I'm unfamiliar with it and don't know if you can run third party binaries

richiardiandrea05:01:09

@anmonteiro on an EC2 instance yes, the code above was a little exercise during the meetup

richiardiandrea05:01:19

On lamdba you run js

anmonteiro05:01:20

I meant AWS Lambda

anmonteiro05:01:27

I know you can run on EC2, sorry

richiardiandrea05:01:41

I went to double check but no: > AWS Lambda supports code written in Node.js (JavaScript), Python, Java (Java 8 compatible), and C# (using the .NET Core runtime). Your code can include existing libraries, even native ones. Please read our documentation on using Node.js, Python, Java, and C#.

mfikes07:01:26

http://dev.clojure.org/jira/browse/CLJS-1911 is worth looking at closely before release

martinklepsch07:01:02

So cool to read up on all the progress done here. Looking forward to the day where we can say CLJS React apps are smaller than JS React apps hehe

martinklepsch08:01:46

Wondering how hard it would be to run yarn inside nashorn...

danielcompton08:01:27

@anmonteiro: AWS Lambda calls to one of python, js, java, but there's nothing stopping you from shelling out to Lumo

danielcompton08:01:06

You can provide a zip file of code/whatever when you deploy a lambda, so you would just bundle Lumo, assuming it has a static binary (or you compile it on an AMI that looks like the lambda environment).

danielcompton08:01:48

Things won't be quite as tightly integrated, we're calling python3 from python2 and it works ok. Obviously you pay for the overhead of calling out, and also you don't get to keep lumo running in between requests.

danielcompton08:01:02

But could be handy for some quick scripts

dnolen14:01:07

@martinklepsch technically they already are 🙂 based on my test yesterday React+ReactDOMServer is about 8K smaller by going through Google Closure

dnolen14:01:07

@anmonteiro yes I was are of require issue but I didn’t have a good answer for that - that patch looks fine to me

dnolen14:01:29

@martinklepsch stuff like Yarn unlikely to work because they haven’t thought about the “bootstrap” problem

dnolen14:01:49

I/O stuff etc., Babel ran in browser always so it’s easier to integrate

dnolen14:01:19

If Oracle had pursued Avatar (Node.js API for Nashorn) we’d be in a different spot

martinklepsch14:01:42

Ah I see. Somehow thought Nashorn would be exactly that, but it’s “just" JS

dnolen14:01:03

yes with actually very good bindings into Java

dnolen14:01:11

significantly fancier than Rhino

martinklepsch14:01:21

There seem to be some other things out there though… http://dynjs.org/ & http://nodyn.io/

dnolen14:01:59

@martinklepsch I looked at that before and I suspect it’s not good compared to Nashorn (wrt. to quality completeness of JS runtime)

martinklepsch14:01:59

might be, either way, probably not “the pragmatic approach” just to get rid of the node dependency for development

dnolen15:01:00

I mean maybe it takes 2 minutes to eval Babel.js in that thing 🙂

dnolen15:01:43

I agree worth looking at, but my experience with non-spec compliant JS runtimes has been pretty bad

anmonteiro15:01:10

@dnolen: awesome. We can also just bind require to global.require outside the function, but in Mikes's patch it is right next to the problem so might be easier to reason about why it's needed

dnolen15:01:43

@anmonteiro I already did that on master

dnolen15:01:23

I believe this approach should cover us

dnolen15:01:39

the issue is that we never want to use require for loading Google Closure stuff

dnolen15:01:53

but we don’t want code that uses require directly to break

anmonteiro15:01:06

Ah right. On phone, sorry. Yes it's fine lile that, just saw it

anmonteiro15:01:40

@dnolen: consider also applying CLJS-1910 to get the bootstrap tests running again

dnolen15:01:09

@anmonteiro shouldn’t that work? with require fix?

anmonteiro15:01:35

It uses cljs.nodejs/require which you commented out

anmonteiro15:01:09

Not sure if the fix is to bring those back or to apply mikes's patch

dnolen15:01:28

yeah messing around with it now

dnolen15:01:51

I think we’ll just bring them back

dnolen15:01:53

ok now would be a good time to test master 🙂

dnolen15:01:23

going to work on an “advanced" part of the JavaScript modules http://clojurescript.org guide that shows how to consume node_module

anmonteiro15:01:41

Cool. I'll give it a spin in about an hour

dnolen15:01:42

hopefully it inspires people to think how make it easier - I don’t think it will be very hard

mfikes15:01:09

@dnolen I smoke-tested master and it looks OK to me. 👍

dnolen16:01:18

I’m deprecating the ClojureScript wiki, please direct all edits to the ClojureScript site, thanks https://github.com/clojure/clojurescript-site

dnolen16:01:04

also if you know how to use master, please do so on your projects

dnolen16:01:10

a massive set of changes is about to land

dnolen17:01:22

yeah will fix

anmonteiro17:01:23

bug there: remove opts, it's already threaded through

dnolen17:01:06

fixed master thanks

anmonteiro17:01:14

one other thing. one recent patch added timing info for every file that's compiled

anmonteiro17:01:54

in my computer it shows that compiling cljs.core$macros takes about 27 secs

anmonteiro17:01:00

is this to be expected?

anmonteiro17:01:16

it's by far where the compiler is wasting the greatest amount of time

anmonteiro17:01:27

apart from that, Lumo works great with latest master

anmonteiro17:01:53

builds successfully, every test passes, etc.

dnolen17:01:53

@anmonteiro I would expect that file to take some time

dnolen17:01:59

but I do wonder where that time is spent

dnolen17:01:14

I’ve long had a suspicion that there’s perf problem with reading .cljc files

anmonteiro17:01:26

27 seconds on a fairly good computer. takes about 40 on my 2.5-year old mac

dnolen17:01:28

but I haven’t had anytime to look into this

anmonteiro17:01:38

that would make sense

dnolen17:01:56

yeah om.next compilation also got a lot slower

dnolen17:01:00

when we switched to a single file

anmonteiro17:01:00

@dnolen that would also explain the thing I showed you at EuroClojure

dnolen17:01:13

so it’s something to look into

dnolen17:01:19

I suspect it’s simple

anmonteiro17:01:25

let's open a ticket so we don't forget

anmonteiro17:01:58

for every numerology fan out there

richiardiandrea17:01:36

lol you guys are funny 🙂

richiardiandrea17:01:04

I will need to update replumb now with all these changes 😄

richiardiandrea17:01:59

tested a "standard" boot project against master and no problems so far

martinklepsch17:01:56

(also used master for this project btw, no issues, but also very small project)

dnolen17:01:19

@martinklepsch it seems moderately useful though it should probably have a lot of caveats

dnolen17:01:31

more than anything it may show that some libraries have DCE problems

darwin18:01:44

got some regressions in my tests, git bisect identified this commit: https://github.com/clojure/clojurescript/commit/101d7d9e03e90518e6769781dd33fbe6387d2d44 it is probably my fault, FYI, investigating it now

darwin18:01:38

I think it will be worth noting in release notes that sequable? changed and people might want to review its usage

darwin18:01:46

also DCE stopped working in in my cljs-devtools tests -> going for another bisect hunt

darwin19:01:30

confirmed, validated it by hand, just to be sure

darwin19:01:35

44d5e56b is last one which works

dnolen19:01:37

@darwin unless you’re inferring externs I don’t see how that’s possible

dnolen19:01:44

compiler output didn’t change in that commit

dnolen19:01:55

re: seqable? - noted

darwin19:01:03

I’m not inferring externs there, it is really strange, don’t understand that commit (yet), just reporting what I’m seeing 🙂

dnolen19:01:19

sure, but I’m skeptical about the conclusion w/o more information

darwin19:01:24

maybe it broke normal inferring?

darwin19:01:46

my DCE tests rely on ^boolean inferring for :closure-defines

dnolen19:01:19

also doesn’t sound likely

darwin19:01:50

so far, I was able to narrow it to this line: https://github.com/clojure/clojurescript/commit/0560106fe8576fd7029d86e61be09cd1f246bfe0#diff-97c50fd669986fb95db3957c1bab83baR769 added some debug printing, it definitely affects my existing code which has no externs inferring printing !!! sym -> pre, outputs stuff like this: https://gist.github.com/darwin/4832baf286287d94c32a32443fa8b60f

darwin19:01:50

so it looks to me that newly code emitted due to (new) existence of :tag prevents DCE

darwin19:01:05

(in my case)

darwin19:01:17

I could try to print generated source before it gets passed to closure compiler and maybe compare it to old version if that would be helpful

dnolen20:01:43

@darwin I do not understand why your problem even matters

dnolen20:01:53

you need to explain why :tag is preventing DCE

dnolen20:01:06

if you’re doing something funny then it’s not something we care about anyway

dnolen20:01:25

I only care if DCE is affected for normal code

darwin20:01:02

well, DCE worked in 1.9.293, I upgraded to master, it broke, the test project it dead simple, I don’t see obvious error on my side

darwin20:01:29

this is not super important, some people rely on cljs-devtools to be elided by DCE in advanced builds, this will stop working for them

darwin20:01:07

I personally don’t include clsj-devtools in advanced builds (via a separate cljsbuild profile configuration)

dnolen20:01:08

this is what I mean this is a non-problem

darwin20:01:55

ok, fine with me, just came here to report regressions

dnolen20:01:21

right but I only care about DCE in general

dnolen20:01:23

not in your project

dnolen20:01:34

so if you can explain how this would affect DCE for everyone

dnolen20:01:36

then I’m interested

dnolen20:01:43

so far I do not understand how that could be possible

dnolen20:01:49

but maybe you know something I don’t 🙂

darwin20:01:42

at this point I don’t understand compiler internals enough to really answer it, sorry 🙂

darwin20:01:00

let’s see how the new release affects DCE for other people

darwin20:01:31

we have a potential candidate commit/line for further investigation

dnolen20:01:01

ok sounds good

thheller20:01:31

@dnolen just saw you doing some work with processes. I think you forgot about clojure.java.shell/sh which does what you are implementing basically

thheller20:01:53

buffering streams, exit codes, etc

dnolen20:01:15

@thheller yeah I’m just not familiar with that ns, and it’s not really important now, I have something working

dnolen20:01:22

@darwin I just tried the trivial console.log hello world smoke test - DCE seems OK here

darwin20:01:48

dnolen: ok, I also tested cljs-oops which has multiple projects testing DCE and all worked, but none of them is testing a code which should get elided by :closure-defines via false goog.DEBUG, which is probably the case which stopped working

dnolen20:01:47

the type of goog.DEBUG

thheller20:01:59

just saying (sh "node" "args" "go" "here") => {:exit Int, :out String, :err String}

dnolen20:01:09

@darwin and that’s even though you’ve hinted boolean?

dnolen20:01:00

@darwin js/goog.DEBUG is bad

dnolen20:01:04

I need more information

dnolen20:01:22

the one I care about is ^boolean goog.DEBUG

darwin20:01:40

ok, I will test them one-by-one and get back to you

dnolen20:01:00

basically what happens is now is js is a kind of taint

dnolen20:01:15

so you don’t want to use unless really need it

dnolen20:01:29

we automatically handle goog

darwin20:01:41

do I need to require it somehow?

dnolen20:01:49

you don’t need to require it

dnolen20:01:53

it should be a special case

darwin20:01:46

confirmed, only js/goog.DEBUG is causing DCE to stop working, goog/DEBUG is fine

dnolen20:01:36

@darwin thanks for looking into that and bearing with me 🙂

darwin20:01:33

no problem 🙂 I’m glad we got it resolved

favila20:01:27

(aget obj (goog.reflect/objectProperty "string_prop_name" obj)) allows prop-munging of property names, but can still access by string

favila20:01:13

goog.reflect/cache lets you use an object as a side-effect-free cache without preventing DCE

darwin20:01:12

btw. this mandatory ^boolean thing reminds me this ticket, which fixes it (and hopefully more): http://dev.clojure.org/jira/browse/CLJS-1615

darwin20:01:56

also the tests there would catch the regression 🙂

dnolen20:01:15

@darwin I tried that exact same thing >4 years ago

dnolen20:01:25

I think I saw a non-trivial bump in code size

darwin21:01:38

ok, that’s a fair point, let’s hope for closure compiler to get smarter about our truth_ function

dnolen21:01:38

unless I hear something ClojureScript 1.9.454 is about to be a thign

Roman Liutikov22:01:12

tested on a project, compiles fine with advanced optimizations output bundle got larger for ~0.5KB, changed from 797460 bytes to 797965 bytes

Roman Liutikov22:01:17

I’m also getting compiler warnings Use of undeclared Var private.project/js which is really just this calls (js/Date.). There 7 calls, but I’m getting only 3 warnings, don’t know if it’s helpful

dnolen22:01:08

that doesn’t mean anything to me right now

dnolen22:01:16

need a lot more information

Roman Liutikov22:01:17

nevermind, it’s gone

thheller23:01:54

@dnolen I know it is marked experimental but I'm really skeptical about the whole node_modules stuff. There are a bunch of sort of non-official things in the js build world that this completely ignores.

dnolen23:01:15

@thheller what’s there to be skeptical about

thheller23:01:15

do you really intent to fully support all these things>

dnolen23:01:30

this something that other people already use directly w/ Google Closure Compiler

thheller23:01:31

one really simple issue: react vs react.min

thheller23:01:41

what you get off node_modules is the dev build

thheller23:01:52

you need to run it through webpack or alternates

dnolen23:01:55

you can use Babel transforms

thheller23:01:57

with process.env set

dnolen23:01:03

you don’t need webpack for that

dnolen23:01:21

all these things are boring details that people can sort out for themselves 🙂

dnolen23:01:26

the point is now they can

dnolen23:01:40

and ClojureScript doesn’t really care one way or the other

thheller23:01:49

well that is my point

thheller23:01:52

it SHOULD care

dnolen23:01:01

but I do not care 🙂

thheller23:01:03

well the user should care

thheller23:01:17

ie. shipping dev react into production is not a good thing

dnolen23:01:17

they just want to use something - now they can

dnolen23:01:38

what I mean somebody else can figure out all that stuff

dnolen23:01:44

i.e. Webpack for ClojureScript

dnolen23:01:57

now you can build that because ClojureScript provides all the various bits

thheller23:01:01

so basically your only goal is to let people call into babel or others via js-transforms?

dnolen23:01:12

people can do whatever they want

thheller23:01:13

and no further?

dnolen23:01:20

I don’t know and I don’t want to know

dnolen23:01:23

it’s like REPLs

dnolen23:01:27

who cares how people use these things

dnolen23:01:40

as long as it helps them solve the problem they want to solve

thheller23:01:27

well .. I also care a lot about the final result being optimal not just "solved"

dnolen23:01:49

I think you misunderstand what the goal here is

dnolen23:01:55

I’m not interesting in “optimal” anything

dnolen23:01:06

only enabling the community to sort it out for themselves

dnolen23:01:21

dealing with the wider JS ecosystem is not purely a technological one with a simple answer

dnolen23:01:38

it’s primarily a social one that’s going to require a lot of effort from many parties

dnolen23:01:54

the changes to ClojureScript are just about letting others do that work with less friction

thheller23:01:04

ok I guess that is a worthy goal

thheller23:01:15

just a bit skeptical about all this being in core vs a library

dnolen23:01:45

sometimes you have to do the skunkwork to show that it can be done & practical

dnolen23:01:02

if somebody gets inspired by this stuff and does something 10X better - we accomplished our goals

dnolen23:01:27

Figwheel is a pretty good example of that IMO

dnolen23:01:43

and I suspect what ClojureScript does arounds JS modules can easily be trumped

thheller23:01:56

yes that is great but you also still have people using or whatever that ns is called

anmonteiro23:01:14

@dnolen hah, looks like the ClojureScript release missed this by a couple days: https://github.com/google/closure-compiler/pull/2130#issuecomment-275801425

thheller23:01:16

so there is a risk of collecting too much dust

anmonteiro23:01:32

> This has been submitted internally & will appear in github on our daily export.

dnolen23:01:35

@thheller removing stuff is a completely different conversation

dnolen23:01:48

we’re not going to do that - zero value

dnolen23:01:14

@anmonteiro yep I’ve been following that one very cloesly

dnolen23:01:25

@anmonteiro but no idea when that will get into a release

dnolen23:01:29

and when it does nothing for us to do really

anmonteiro23:01:40

hopefully will be in the February release

dnolen23:01:12

@thheller far as I can tell the most successful things in technology are pretty darn dusty

dnolen23:01:18

HTML, JavaScript, CSS, Java

dnolen23:01:22

it’s not a compelling argument

thheller23:01:17

yeah I guess

dnolen23:01:33

@anmonteiro fingers crossed, soon as that’s in we can fix the ugly ES6 example

dnolen23:01:42

having to avoid import for the deps is pretty ugly

juhoteperi23:01:13

I think it optimal case Closure should be able to optimize JS modules as well or better as Webpack

thheller23:01:08

:verbose true])

dnolen23:01:16

@juhoteperi it’s already better

dnolen23:01:35

in the guide example you will build React with all the invariants stuff

dnolen23:01:41

and the output is like 8K smaller

juhoteperi23:01:54

Closure can already remove code where if condition is always false, etc, so it should be probably possible to define process.ENV as constant or something

dnolen23:01:55

so somebody should looking into eliding that stuff and measuring

dnolen23:01:13

@juhoteperi yes, in fact you could probably hack it with goog.define in CLJS

dnolen23:01:55

so many things to try 🙂

dnolen23:01:20

@juhoteperi I don’t know if you saw earlier but you were right about the package.json stuff

dnolen23:01:32

fortunately Google Closure does the right thing internally

dnolen23:01:47

but we needed module-deps to compute what to pass to Closure

dnolen23:01:26

that’s something we could probably replace with some Clojure but I’m lazy

juhoteperi23:01:27

One thing that I hit when trying this a month or two ago, was that Closure "scoped" modules by path, packages under node_modules could only require each other and not packages from foobar/node_modules