Fork me on GitHub
#clojurescript
<
2016-12-28
>
emccue05:12:57

Out of curiosity, what would need to happen for use of CommonJS/ES6 dependencies to be able to be parsed by the Google closure compiler. (As in, where would work need to be done)

thheller10:12:53

the real hurdle is that many many JS libs do their own thing that is non-standard since there basically is no agreed standard

thheller10:12:08

ie. even if the above PR makes it in, it still won't be able to compile React

thheller10:12:51

many idioms used in the JS world just don't work in closure

thheller10:12:19

parsing them really isn't the problem

thheller10:12:26

so what needs to happen? personally I don't think it will ever happen

ejelome10:12:29

... so how do you make them one single js and minified file?

thheller10:12:39

@ejelome simple, use webpack/`babel` (or whatever is fashionable in JS) to do the JS eco-system. Use closure for closure/cljs, concat them together

thheller10:12:49

arguable things get a bit more complicated if you want interop between the two

ejelome10:12:06

so in that case, a separate minification process for all js libs, then a separate minification for cljs (via closure), then concatenate then minify them again or just concatenate?

thheller10:12:06

and not just one side using the other

thheller10:12:19

just concat, no more minify needed

thheller10:12:35

you might gain some bytes but only at some other cost

thheller10:12:46

closure is already optimized for many things

thheller10:12:52

ie. load time, gzip ratios, etc

thheller10:12:07

if you minify it more it just going to undo all that

ejelome10:12:26

I see, because we're also wondering how to turn both js and cljs files into one plus optimization

thheller10:12:03

yeah running "foreign" JS through closure is the stuff of nightmares

thheller10:12:08

just don't do it

thheller10:12:40

optimize closure/cljs using closure

thheller10:12:49

optimize the rest with the other tools

thheller10:12:10

that stuff is still evolving rapidly in the JS world

thheller10:12:38

doubtful they are going to settle on the constraints set by closure though

ejelome10:12:38

one thing that confuses me is the workflow of having external js libs then cljs, does this mean that a separate terminal is necessary to do babel/webpack work or no? because we cannot entrust those libs with the closure compiler right?

thheller10:12:02

yes, you'll probably want a separate process for the JS stuff. probably in its own terminal.

thheller10:12:17

you'll still need to write externs though

thheller10:12:33

so closure needs to know some of it if you want :advanced

thheller10:12:57

you can feed the output of the JS stuff into the CLJS workflow through :foreign-libs

thheller10:12:56

but don't take my word for all of it, some people are way more optimistic about all this stuff

thheller10:12:17

I know bhauman had ES6 working in figwheel with live-reloading and everything

thheller10:12:39

just a custom lib though not something like React

ejelome10:12:33

I should read a bit more about this :foreign-libs since what I usually do is put the external libs on top of the script tag before the compiled cljs file

juhoteperi10:12:06

@ejelome What kind of es6/npm libs do you need to use? Your own code? Existing libraries?

ejelome10:12:57

something like ajax libs, e.g. superagent

ejelome10:12:20

or what usually not bundled with reactjs

juhoteperi10:12:51

Superagent could be packaged in Cljsjs and then you would only need to have a Maven dependency on that to use it

ejelome10:12:47

so cljsjs is like a fork of the originals made to make these js libs compatible to closure?

ejelome10:12:08

or rewrite, or dunno what it's called

thheller10:12:14

cljsjs basically just bundles things together so they work as a :foreign-lib

juhoteperi10:12:21

Nope, it is a packaging effort to provide packages with externs and :foreign-libs configuration

juhoteperi10:12:58

The packages include deps.cljs file with extern and foreign-libs info which is automatically read by ClojureScript compiler

juhoteperi10:12:19

When possible the packages contain browser compatible JS file from original project. But in some cases Cljsjs packaging uses webpack/browserify to create JS for browser.

thheller10:12:02

but if you plan on using many CLJSJS packages you might be better off not using them at all

thheller10:12:21

and just keeping things on the JS side as I described

thheller10:12:45

so you just end up with 1 foreign lib (or just keep them completely separate as you are doing)

thheller10:12:54

even single CLJSJS packages are not optimal in many cases

juhoteperi10:12:32

Hmm, how could webpack (or other tools) optimize them any better when building one output from multiple libraries?

thheller10:12:17

@juhoteperi take material-ui as an example

thheller10:12:33

it is very likely that you are not going to use everything

thheller10:12:41

CLJSJS bundles everything

juhoteperi10:12:00

Ah okay. Yeah, you could use your own JS file to require the parts of material-ui you need?

thheller10:12:04

webpack can strip out the things you don't need if you configure it correctly

juhoteperi10:12:29

Material-ui is definitely a case where even module level dead-code-elimination is useful

juhoteperi10:12:50

But with many other libraries (React, Leaflet) that is not that useful

thheller10:12:38

yeah definitely. cljsjs is great, good enough for almost everything

thheller10:12:54

just not optimal in some cases

thheller10:12:15

it gets worse if you have 2 JS packages that share a common dependency

thheller10:12:33

CLJSJS will include the dependency twice

ejelome10:12:12

^ I meant the bundling including the deps

thheller10:12:37

yeah, that is why I recommend bundling things yourself and not relying on CLJSJS too much

ejelome10:12:39

so if 2 libs requires jQuery for example, you'll then get 2 bundled js file with 2 jqueries

thheller10:12:50

depends on the CLJSJS package

thheller10:12:08

but possible yes

thheller10:12:22

most likely they will just depend on cljsjs/jquery

thheller10:12:12

for obvious dependencies like jquery that should mostly not be a problem since the JS release artifact also probably won't bundle jquery

thheller10:12:14

small things like lodash.merge may be very likely to end up 1 or more times in your build

thheller10:12:30

depending on how much of the JS stuff you use of course

thheller10:12:41

basically the more "modular" a thing is the harder cljsjs gets

ejelome11:12:37

so in essence, it's more suitable for monolith libs, the one size fits all js libs, but not advisable for as you said, modular (a lib with many external dependencies)

ejelome11:12:44

great details @thheller :thumbsup:

ejelome11:12:58

thanks a bunch!

thheller11:12:58

I'm still searching for the optimal solution myself ... this stuff is complicated 😛

emccue13:12:51

Hmm, I don't know how well this would play, but might it be possible for a library (let's say lodash, though that one probably isn't that useful in ClojureScript) to do something like this. (ns site.something (:require foreign.lodash :refer [merge])) Then automatically parse those require statements (or something similar) and generate a bundle.js that just has import {merge} from 'lodash' Then like var webpack_hack = [merge] If we need to do something to make those not get deadcode eliminated/tree shook Which the js ecosystem could optimize with webpack

emccue13:12:18

The namespace for whatever the module could be generated by configuration, just like it is right now. And the hybrid (yeah let's call it hybrid that sounds cool and not hacky) workflow would be something like Npm/grunt/etc. Install file. Configure project.clj with the path to lodash and that it should go under "halfbreed.lodash". start webpack watcher to make your bundle.js, then wrestle whatever magic is possible to require whatever stuff from the synthetic namespace, and finally have some watcher parse your code, make a bundle.js for webpack. ???? Profit

emccue13:12:06

Though I will admit I don't have a full/partial/any idea how synthetic namespaces work

Pablo Fernandez18:12:26

Does anybody know of a cljsjs package written in ES6?

hulunote18:12:47

I want run lumo in my Android’s termux, but “lumo.exe” erro .

anmonteiro19:12:05

@stevechan probably better to discuss this in #lumo

anmonteiro19:12:22

you probably want the linux distribution. there might be a problem with the npm installation script

anmonteiro19:12:52

if it needs to run on ARM, there's no way to do it yet

nikki21:12:10

hey all just wondering -- i'm reading this article http://www.mattgreer.org/articles/clojurescript-internals-vectors/ and was wondering -- things like https://github.com/clojure/clojurescript/blob/22dd4fbeed72398cbc3336fccffe8196c56cd209/src/cljs/cljs/core.cljs#L4226 are you able to read them and immediately intuit the syntactical understanding that takes you to the pseudocodey description right after that in the article?

nikki21:12:35

like the article follows the paste of the code with some pseudocode which makes me think: "do u need pseudocode when explaining cljs code?" -- i'm just leraning cljs

nikki21:12:49

potentially they did it in the article because they were expecting cljs newbies to also read it

nikki21:12:02

but wondering if with practice you get to a level of being able to read code like that pretty quicly

bbloom21:12:10

nikki: as a general rule, standard library code is never idiomatic

bbloom21:12:24

remember: core is one everyone’s hot path

nikki21:12:44

i guess it can't be because it has to be optimized as well as be at the abstraction bottom

bbloom21:12:50

so it’s always hand optimized, and often built using primitives that are incompletely available at that stage of compilation, etc

nikki21:12:08

i will say tho i hope to write code that is a lot of ppl's hot path since i want to build a system that a lot of ppl use 😅

nikki21:12:35

but also this code is actually not that bad, it's pretty good

bbloom21:12:49

in order to understand that code you linked to, you need to understand 1) how the persistent collections work 2) a fair amount of clojure 3) the idiosyncratic things about this particular implementation

nikki21:12:51

i.e., the pseudocode is good, i'm talking about the step of the understanding that is sexps --> algo not algo --> understanding

nikki21:12:05

yeah #1 i understand

nikki21:12:51

thanks @bbloom for the perspective 🙂