@bfast I'm using material-ui-next directly from npm with shadow-cljs, and it works great. For me it was a bit difficult figuring out how to require the different components, as some require using default and some require using refer. Here's my current imports, maybe that will help:

["material-ui/Button/Button" :default Button]
   ["material-ui/IconButton" :default IconButton]
   ["material-ui/Progress/LinearProgress" :default LinearProgress]
   ["material-ui/Radio/Radio" :default Radio]
   ["material-ui/Radio" :refer [RadioGroup]]
   ["material-ui/Form" :refer [FormLabel FormControl FormControlLabel FormHelperText]]
   ["material-ui/Switch" :default Switch]
   ["material-ui/Dialog" :default Dialog]
   ["material-ui/AppBar/AppBar" :default AppBar]
   ["material-ui/Toolbar" :default Toolbar]
   ["material-ui-icons/Menu" :default MenuIcon]
   ["material-ui-icons/Close" :default CloseIcon]
   ["material-ui-icons/MoreVert" :default MoreVertIcon]
   ["material-ui-icons/ExpandMore" :default ExpandMoreIcon]
   ["material-ui-icons/ExpandLess" :default ExpandLessIcon]
   ["material-ui/Menu" :default Menu :refer [MenuItem]]
   ["material-ui/Typography" :default Typography]
   ["material-ui/Card/Card" :default Card]
   ["material-ui/Avatar" :default Avatar]
   ["material-ui/Card" :refer [CardHeader CardMedia CardContent CardActions]]
   ["material-ui/Paper" :default Paper]
   ["material-ui/transitions/Collapse" :default Collapse]
   ["material-ui/TextField" :default TextField]
   ["material-ui/Drawer/Drawer" :default Drawer]
   ["material-ui/List/List" :default List]
   ["material-ui/List" :refer [ListItem ListItemIcon ListItemText]]
   ["material-ui/Divider" :default Divider]
   ["material-ui/ExpansionPanel/ExpansionPanel" :default ExpansionPanel]
   ["material-ui/ExpansionPanel" :refer [ExpansionPanelDetails ExpansionPanelSummary]]

@mjmeintjes that :> seems very interesting, I have been using reagent for a long time and I have never heard of it. Can you point me to some docs?

For those interested, just thought I post some pretty cool info: we’ve been porting over a large CLJS app from lein-cljsbuild + a lot of cljsjs and manually created foreign libs over to shadow-cljs and completed that task this morning. The productivity gains are one thing, but tangibly we’ve gone from an uncompressed 9.9MB build to 2.7 MB and gziped 1.4MB to ~700k

Layer on the potential benefits form code-splitting, and that’s a a huge win for us thanks to shadow-cljs

Big thank you to @thheller

wow interesting @colindresj. Where do you think most of the gains are coming from? I knew that shadow-cljs made it easier to import, but I didn’t realize it would do better at minification

Haven’t done a deep-enough dive to figure it out just yet @lee.justin.m, but I’m guessing that since foreign libs (including those in cljsjs) don’t go through any kind of optimization, there’s a lot of duplication and dead code there

Especially when using JS libraries that are pre-compiled via Babel, I’ve noticed that a lot of our foreign libs contain the same Babel helpers over and over again

I'd be interested in knowing about the optimization benefits too. I had not considered the duplication before, very interesting.

I suppose duplication matters little with gzip though?

the biggest thing that I know shadow allows you to do is reference partial components. e.g. material-ui lets you refer to just the component you are using. that’s actually possible to do in shadow

if you set your foreign-lib up properly, you should be pointing to minified builds during production. if you guys were doing that and you are still seeing gains, that would be pretty amazing

Gzip takes care of shipping the code to the browser, but the browser still has to parse and execute all the duplicate stuff.

@dominicm I think so, which is why the gains at the point of gzip are proportionally much smaller than pre-gzip

@lee.justin.m we were minifying our own foreign libs, hard to know for sure about all the others

@colindresj nice! biggest gain is probably from de-duping some stuff. closure :simple mode (which is used for npm deps) is also pretty good though, so thats part of it too.

but you essentially validated exactly why I wanted to get away from cljsjs. https://code.thheller.com/blog/shadow-cljs/2017/09/15/js-dependencies-the-problem.html#cljsjs

glad I'm not the only one seeing those results

Hi, I am trying to use beicon with shadow-cljs on node, but getting this: The required namespace "beicon.impl.rxjs" is not available, it was required by "beicon/core.cljc". I skimmed last couple of days and found some similar stuff but somehow I can't get my head around it. The problem I guess is that beicon is using https://github.com/funcool/beicon/blob/master/assets/deps.cljs and it is not compatible with shadow-cljs.

https://shadow-cljs.github.io/docs/UsersGuide.html#_migrating_cljsjs

npm install rxjs

Thanks!

I'm not entirely sure how the shim file would have to look

(ns beicon.impl.rxjs
  (:require ["rxjs/Rx" :as rx]))

(js/goog.exportSymbol "Rx" rx)

maybe?

rx is one of those packages where you are better off importing only what you need directly

Ok, I will try it

So at least compilation is working. I will report how it will continue. I started to play with shadow this week and I fell in love.

So this is my first try with small node library. If I manage to work with it, I am planning to move our front-end app to it

Thank you very much again

Well everything is working for me

hehe I did a quick test and rxjs loads 400+ files

thats a bit scary 😛

😄

but it seems to work

It does indeed