This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-28
Channels
- # ai (1)
- # beginners (190)
- # boot (24)
- # cider (43)
- # cljsjs (3)
- # cljsrn (29)
- # clojars (6)
- # clojure (310)
- # clojure-dev (6)
- # clojure-nl (6)
- # clojure-russia (11)
- # clojure-spec (66)
- # clojure-uk (95)
- # clojurescript (103)
- # clojurewerkz (2)
- # core-async (9)
- # cursive (4)
- # datomic (5)
- # hoplon (163)
- # lein-figwheel (52)
- # off-topic (6)
- # om (6)
- # onyx (42)
- # perun (8)
- # re-frame (16)
- # reagent (10)
- # ring (7)
- # ring-swagger (1)
- # rum (1)
- # slack-help (2)
- # uncomplicate (1)
- # untangled (80)
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)
/ping @juhoteperi ^
@emccue the easy parts: https://github.com/google/closure-compiler/wiki/JS-Modules and https://github.com/google/closure-compiler/pull/2130
the real hurdle is that many many JS libs do their own thing that is non-standard since there basically is no agreed standard
@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
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?
I see, because we're also wondering how to turn both js and cljs files into one plus optimization
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?
yes, you'll probably want a separate process for the JS stuff. probably in its own terminal.
you can feed the output of the JS stuff into the CLJS workflow through :foreign-libs
but don't take my word for all of it, some people are way more optimistic about all this stuff
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
@ejelome What kind of es6/npm libs do you need to use? Your own code? Existing libraries?
Superagent could be packaged in Cljsjs and then you would only need to have a Maven dependency on that to use it
so cljsjs is like a fork of the originals made to make these js libs compatible to closure?
Nope, it is a packaging effort to provide packages with externs and :foreign-libs
configuration
The packages include deps.cljs
file with extern and foreign-libs info which is automatically read by ClojureScript compiler
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.
but if you plan on using many CLJSJS packages you might be better off not using them at all
so you just end up with 1 foreign lib (or just keep them completely separate as you are doing)
Hmm, how could webpack (or other tools) optimize them any better when building one output from multiple libraries?
@juhoteperi take material-ui as an example
Ah okay. Yeah, you could use your own JS file to require the parts of material-ui you need?
Material-ui is definitely a case where even module level dead-code-elimination is useful
But with many other libraries (React, Leaflet) that is not that useful
yeah, that is why I recommend bundling things yourself and not relying on CLJSJS too much
so if 2 libs requires jQuery for example, you'll then get 2 bundled js file with 2 jqueries
for obvious dependencies like jquery that should mostly not be a problem since the JS release artifact also probably won't bundle jquery
but even looking at this: https://github.com/callemall/material-ui/blob/master/package.json#L48-L60
small things like lodash.merge
may be very likely to end up 1 or more times in your build
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)
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
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
Though I will admit I don't have a full/partial/any idea how synthetic namespaces work
Does anybody know of a cljsjs package written in ES6?
@stevechan probably better to discuss this in #lumo
you probably want the linux distribution. there might be a problem with the npm installation script
if it needs to run on ARM, there's no way to do it yet
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?
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
potentially they did it in the article because they were expecting cljs newbies to also read it
but wondering if with practice you get to a level of being able to read code like that pretty quicly
i guess it can't be because it has to be optimized as well as be at the abstraction bottom
so it’s always hand optimized, and often built using primitives that are incompletely available at that stage of compilation, etc
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 😅
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