Is there a compilation of approximate code sizes (minified,compiled, gzip'ed) of various cljs libraries? Like core.async, datascript, reagent etc.

@rauh there is no such thing, since it all depends on how much of those things you are using

say datascript provides some functions you do not use

I know, but basically a rough idea... core.async was much smaller than I expected e.g

most of the core.async magic is macros

I think it'd be helpful to have a rough idea in general... Is it 2kb or 50kb, helps a lot to make a decision

so the lib itself does not carry a lot of code, yet the macros may produces huge amounts of code in your js files

Yeah datascript doesn't get DCE very well. Lot's of datastructures and most of the functions are ^:exported

as I said it is impossible to give an estimate like that since it will vary greatly depending on each project

rough estimate would be really rough

like +/- 50% rough

I have to disagree that it's impossible. To get a general idea, we can just call the most common functions and then see how much code it added

yes in theory

but say you do not use clojure.string

then you add datascript which uses it

I'm at 2kb for core.async (using chan and go) and 30kb for datascript

that gives you datascript+`clojure.string` size

then you measure core.async and you get core.async+`clojure.string` size

indiviually

but if you use both you do not get (datascript + clojure.string) + (core.async + clojure.string)

Well we could get smart about this and look at goog.deps.cljs (or so?) and see what's coming in (relatively)

you get (datascript + core.async + clojure.string)

that is the "high level" of namespaces

since closure works on a much lower level

I'd probably argue that the differences vary much more because of the compression algorithms getting more efficient the larger the file

my argument is that the estimate would be useless

also for core.async as an example

files in out/core/async/... do not tell the whole story

as code generated by (go (doseq [x some-seq] some very nested code)) can get extremely large

but that will not be in out/core/async/... but in out/your/namespace/...

so if you want to know how much a js lib is, measure in your project

Yeah but that's something the developer should watch out for by doing an occasional macroexpand

(Which I do and therefore avoid for completely)

I understand why you'd be interested in the size, I know I am

but given the experiences I had over the years, you cannot quite make general assumptions here

what you can know exactly however

is the size of external deps when using cljsjs for example

as that is just js code that never gets optimized

But the measures we'd get (using minimal examples) would be an upper bound (if calling most common API functions) so that'd be useful for many people IMO

yeah but again, the measures might be way off due to the keeping/removal of namespaces that a lib uses

but you might already be using yourself

so you might see datascript is 50kb extra

and say no

but you are actually already using 30kb of the code yourself

If the upper bound says "100kb gzip difference" then it's not useful, but if it says 10kb it's already very useful

so it would actually be 20kb

I agree with what you're saying, but still think this information could be useful

I'm not aware of any information like that

I think the only way to get this information is to constantly monitor file sizes of your build, then when you notice big changes you should investigate what caused them. Was thinking to make a boot task that tracks filesizes in git metadata (so it's associated with revs) but didn't do anything in that direction yet

@rauh ^

@martinklepsch That's actually what I've been doing for a few months. There is a :watch-fn that gets called each time a build is done. I then pipe it to nginx and get the brotli+gzip sizes of the builds and (spit..)-append it in a file to keep a history of file sizes

I think that's the best you can do really (besides extending that basic approach with graphs etc). Because Closure removes code on a per-function basis it's impossible to give modules a fixed size

trying to compute the average size of a library doesn’t make sense

the only thing that does make sense is - "is this library broken for DCE to work correctly?"

once your dependency graph gets significantly deep such information is even less useful

since dependency C may make dependency B bigger depending on how you use C

Hi all, how should I require a package that has been bundled with browserify?

The equivalent JS is:

var blobStream = require(‘blob-stream’);
var stream = doc.pipe(blobStream());

@cfleming you need to add it as a foreign library

http://clojurescript.org/reference/compiler-options#foreign-libs

@anmonteiro Thanks!

@anmonteiro So if it’s been bundled to bundle.js, I would do something like:

{:foreign-libs 
  [{:file “bundle.js"
    :file-min “bundle.min.js"
    :provides [”blobStream"]}]
 :externs [”bundle_externs.js"]}

@cfleming that's it. note, however, that :file is a filesystem path, not a classpath path

Right, that’s in the root of my project.

(for the moment)

in your ClojureScript namespace, you (:require [blobStream])

but that's just an artificial namespace

Oh, ok, so I can call that whatever I want?

you still need to get at the JS objects with js/ObjectThatTheBundleExports

And Closure will not try to run advanced mode over that lib, right?

right

they're just prepended to the output

Hey new to Clojurescript. Here's some slightly surprising behavior when running code with advanced optimizations vs. not: ;; behavior when :optimizations :none (def inst #js {:foo "bar"}) (println (.-foo inst)) ;; => "bar" (println (aget inst "foo")) ;; => "bar" ;; behavior when :optimizations :advanced (def inst #js {:foo "bar"}) (println (.-foo inst)) ;; => nil (println (aget inst "foo")) ;; => "bar" I understand that this is b/c Google Closure renames symbols. So, I get it, this code is "incorrect". But why? Is the rule/contract that you should never use property access (.-foo inst) for dynamic Javascript properties? What's a better way to explain/understand this...?

@atdixon you can use property access if you have externs for that stuff

also goog.object/get is preferred over aget, which is meant for array access

@atdixon your conclusion is corrrect - and @anmonteiro suggestion is the way to go

if you’re using JSON values as dynamic data you need to use goog.object

for properties which represent code - fns, methods - these must be statically known

they are all subject to renaming

@anmonteiro @dnolen perfect - thank you!

@anmonteiro I can’t get this to work, I must be doing something daft. Here’s what I have - I’ve browserified the packages into bundle.js following the instructions here: https://github.com/whamtet/cljs-pdfkit#setup. bundle.js is in the root of my resources, and I believe it’s being loaded since it complained when it was in the wrong location.

(i.e. I’m including the bundle.js in a script tag)

if you're using foreign-libs you don't need to add a script tag

but that alone might not solve your problem

Hmm

Unfortunately the instructions in that repo are a little light on details.

So in bundle.js I see: function BlobStream() { ... and module.exports = BlobStream;

It looks to me like that library assumes I’ve put everything in a script tag, since for the PDF functionality he doesn’t seem to be using foreign libs.

BlobStream is only one of the deps in the browserify bundle.

Unfortunately the source to his demo doesn’t seem to be available.

Actually, he has another example which does have source available - I’ll check that out.

@cfleming I think foreign libs should be the same as a script tag

the ClojureScript compiler will order the dependencies such that your bundle comes before the code which requires it

oh, now that I think about it, if the library needs some (foreign lib) dependency to be there but it doesn't require it, there might be problems 🙂

Yeah, that’s what I think is happening

I think he’s browserified the whole lot, his lib requires the PDF stuff but I can’t see any evidence of him using foreign libs.

I think he just uses the script tag and then uses js/Whatever

@anmonteiro Got it, thanks - he’s using (js/require “blob-stream”), not foreign libs

heh OK. does the browser support js/require?

Apparently so

I suppose it's there just because of the browserified bundle

I guess, I don’t even have a vague idea how this stuff works 🙂

is there a sample project with reagent that i can look around?

would be nice if it also has a server part in clojure too, but not necessary