Hey,
agreed on external libraries as a rarely changing framework.js served
separately.
While you are still developing you could do :simple but again that needs to be
done for everything then. You can't do cljs.core as :simple and the rest as
:advanced. Too much of the cljs internals rely on either everthing running
through advanced or nothing. You can't just write externs for cljs.core and
treat it as an external library. Well you maybe could but you might as well
skip :advanced at that point.
I would recommend to not worry about it too much while prototyping. Once
everything settles you probably won't deploy that frequently and given the size
of well optimized CLJS builds we are probably talking about 100kb (gzip'd)
which shouldn't really be significant for an enterprise user. Enterprise users
send around Excel/Word files 10x that size much more frequently. ;)
You could probably try :simple + closure modules to increase the chance of
cache hits while developing but in the end you are probably optimizing the
wrong thing. No one notices 100kb on an enterprise network. Everyone notices
animations not running smoothly or otherwise janky app performance. Everyone
says React is fast but it really isn't. I would worry much more about the apps
performance while running not while downloading. Even :adcanced only buys you
maybe 5% here.
/thomas
On Thursday, November 24, 2016 at 6:48:41 PM UTC+1, Scott Klarenbach wrote:
> Thanks a lot for the response Thomas. I think we are on the same page, I
> just wasn't using the correct terminology.
>
> I can use :advanced mode for my own code so long as I include an externs file
> for jquery, material-ui, etc.
>
> Not including the external libraries as part of the build (my framework.js)
> is what you're proposing, and the same goal I was after. Even with cljsjs, I
> was including those in the build, and therefore redeploying a 500k+ js file
> every time a tiny part of my application code changed. If I remove all non
> cljs/closure code from the build and just use a cdn and externs, much of my
> code base doesn't have to be redeployed when my application changes, which is
> my goal.
>
> For context, I'm building heavyweight web apps, for a small number of
> enterprise users. The code changes rapidly in the beginning due to the
> prototyping process. Most traffic is from existing users, not new visitors
> to a website. I just wanted a way to return 304s for most of the javascript
> and only send my app.js code when it changes.
>
> My instinct is that even the cljs/closure runtime could be deployed to my
> clients once, and only updated a few times a year. Hence the idea of simple
> optimizations. I think you're saying that I should just resend all the
> cljs/closure each time with :advanced optimizations. It just seems to me
> that in my situation I *could* treat the cljs/closure core runtimes the same
> way I do jquery - deploy a :simple version once to the client, and rarely
> have to send again. Even in :advanced mode, a lot of redundant cljs/closure
> code is resent to the client each time any tiny part of my app.js changes.
>
> Thanks,
> Scott.
>
> On Wednesday, November 23, 2016 at 5:12:15 PM UTC-8, Thomas Heller wrote:
> > Hey,
> >
> > I have done quite a few experiments over the years and these would be my
> > general recommendations.
> >
> > TL;DR: Embrace :advanced fully, keep non-cljs/closure out of your build,
> > mind your dependencies, use closure modules to split code.
> >
> > Most things really depend on your app and your general audience. Say you
> > have mostly new users that spend some time on your site but only once every
> > few days/weeks at most. Their cache will very likely be empty most of the
> > time. So having a "larger but re-usable" framework.js is just worse since
> > they have to download it anyways. Only because you say "cache forever" does
> > not mean the browser will do so, some (especially mobile) Browsers will
> > purge on their own terms (LRU, LFU) anyways to save space.
> >
> > You can use things like React via a public CDN to increase the chances of
> > the user having the thing cached. I have no statistics here but in theory
> > this is a good idea (and fairly common).
> >
> > You want to keep things like React and Material-UI completely out of your
> > CLJS build anyways since the Closure compiler doesn't unterstand them and
> > can't do much. If you get Material-UI via CLJSJS for example it is one huge
> > JS file, even the min is 150kb gzip'd + 100kb for the icons. If you only
> > use 3 out of the 40 or so Components they provide you are better off with
> > JS tools to handle this. Webpack or Rollup are supposed to be good and will
> > most likely provide better results until Closure fully understands this.
> >
> > CLJS/Closure code should always go through :advanced though as the
> > potential savings are huge and you get better performance for
