hi everybody! What is the best way of accomplishing something like (System/identityHashCode o) in ClojureScript being o any js object?

I'm not sure if this is the right forum for this conversation, but I am really struggling with code/module splitting in ClojureScript for browser applications. This sounds like a complaint but the actual question at the end is, "am I missing something?" Splitting up the actual ClojureScript code is easy enough using the guides, but if you have a significant number of NPM dependencies, the size of your cljs_base.js file is still going have the lower bound of the NPM dependencies index.bundle.js. It's starting to seem like a mistake to bundle NPM deps with ClojureScript code, and instead go the extern route. Because then at least there is the hope of chunking the index.bundle.js into smaller files. Annoyingly, neither the cljs.loader framework nor the :modules directive in foo.cljs.edn seem to have any interesting in working with js/npm code, so it seems I'd have to handle that part manually. Lastly and perhaps tangentially, it seems if code/module splitting were take to its logical extreme, every namespace would look like this:

(ns some-ns
  (:require [cljs.loader :as loader]))

(defn bar [a b]
  "blah")

(loader/load :some-other-ns
               (fn [e]
                 ((resolve 'some-other-ns/foo))))

(loader/set-loaded! :some-ns)

@goomba we cannot solve the splitting wrt. bundlers, if you want to use many NPM modules - code size is nearly always going to be an issue anyway - I think shadow does it’s own thing here? It should be possible to chunk etc. but not ClojureScript’s problem

I don’t know what you mean by “logical extreme” - but maybe it’s not clear that such things are not necessary w/ Google Closure Compiler code splitting

it is nothing like “chunking”

Closure will move functions, properties, object methods etc.

"logical extreme" meaning, in my mind (I may be incorrect) all dependencies (every namespace) would be loaded asyncronously using loader/load in order to make each network hop as small as possible. That would therefore imply that there would be few if any dependencies listed in the :requires. Again this is an extreme -- given unlimited time and maintenance was not an issue -- but in practice I would assume you would try to find a compromise of implementation speed and maintainability with performance and dynamic loading. Again -- I could be wrong here about the intentions. Seeking information. But I also agree with your point that this really isn't ClojureScript's charter to do the NPM deps, that makes sense to me. just making sure I'm not missing something obvious.

(the reason for this, in case it's not obvious, would be to make the cljs_base.js as small as possible -- ignoring NPM deps -- so that the page loads as quickly as possible)

what I mean is that what you are suggesting is unlikely to be any better than how Google Closure Compiler works - which as far I know is quite optimal and been measured for over a decade

there are no chunks in Google Closure

what you are really is saying this is an entry-point for my application

and it is irrelevant what is in that file or in the dependences

Google will move and eliminate

more chunks doesn’t necessarily make anything faster

but getting only what a chunk needs down to individual functions probably does matter

Pulling back from the specifics, the main problem here is I'm trying to get the initial bundle size as small as possible, and the cljs_base.js is currently my bottleneck for that. I'm trying to move as much code out of that as possible so I can bootstrap the page as quickly as possible. And what it sounds like, and it is a fair point, that this has nothing to do with the ClojureScript compiler or the GCC and so other techniques must be used.

there are few other things which are not obvious that I verified a long time ago

i.e. if you don’t use any CLJS data structures then of course the advanced output will be gzipped into bytes

it is possible to setup things so that one of your namespaces (i.e. a login page) doesn’t use anything but JS primitives

Would that then be compiled with a separate build entirely?

no

I should also add that this in the case of a large/complex SPA

it is not magic, but you can design the initial load to avoid all the other stuff

really the only thing that should be in base is ClojureScript data structures / fns

so 20-25K gzipped base

Agreed, that's what I'm trying for. So I'm thinking the approach here is probably going to be to get rid of the NPM deps as part of the advanced compilation and side-load it, then setup my externs appropriately. And I can defer the loading of the index.bundle.js using some other techniques. That will keep the cljs_base.js extremely small and allow for fast page load. Worst case scenario can put the bare minimum on some vanilla js bootstrapping code and then pull in the cljs code. Does that sound practical or does it sound like I'm using the tools incorrectly?

it’s some work to setup for sure it will be annoying - but it is kind of one time job for a project - what you’re suggesting sounds like one way to do it

Also maybe one other thing is, it doesn't seem to me like GCC advanced compilation does any dead code elimination on NPM deps. Because I'm am 100% certain I am not touching all 5 or so MBs of the NPM deps but my cljs_base.js still seems to be lower bounded by the size of the index.bundle.js. Am I correct in that a webpacked index.bundle.js does not benefit from GCC advanced compilation dead code elimination and I need to be more careful about pulling in only the required things?

advanced compilation cannot work on random JS libraries

you have to try different packers if you want to get that smaller

makes sense. Thanks again for your hard (and mostly thankless) work, I appreciate it! Won't take up any more of your time.

what I would recommend is toy around w/ code splitting separate from what you are doing w/ NPM

will do. I'll do a write-up if I identify some good patterns, I think we could use some more info out there on the subject.

try what I said, i.e. minimal login ns w/ JS primitives only - and then another ns w/ core.async or something and you’ll get a sense of how it’s supposed to work

another possibility is tsickle I haven’t time to really use it - but I think this is in heavy use at Google to use random libs - it converts ES6/TypeScript to Closure w/ generated externs

then you could avoid trying to combine two bundler (JS thing, Closure)

whoaaa, interesting (regarding tsickle).

yes, a bit short on time, but it’s on my list of things to assess - it could drop the need for multiple bundlers which is a real pain

https://github.com/angular/tsickle - super light on documentation on how to use it

It also seems like there's a good possibility to use goog.events to "communicate" between modules without explicit ((resolve 'some-ns/bar)) , so there are certainly opportunities there

but I did succeed at converting random libs to Closure style

I think the point where this is becoming a real pain is for things like reagent which require react and react-dom as external deps, so some form of bundling (whether advanced compilation or cljsjs/react) seem kind of necessary and the "best" way to handle it is unclear. But nothing that can't be solved with some roll-up-the-sleeves engineering effort.

But despite that, cljs is still an island in the middle of the js insanity

I’ve been in React Native land for a few years where the code size thing is significantly less of a concern and the existing approach is satisfactory

fwiw, I think for people who really care about bundle size NPM modules are serious dead end - I would just do everything in Closure

Yeah I was actually thinking about going to React/Typescript for the components, might make runtime dependency injections easier too.

a Google Closure incremental DOM thing in pure JS a la Transit would be nice

again not to discourage React stuff, but some times you just want more control over the bundle, and that could be a good starting point

as an alternative to React? :thinking_face:

the thing is for “bottom” stuff writing in JS has some benefits, it can be easier to eliminate depending

the problem with writing ClojureScript is that implies the data structures which compose like 50% of the source of the standard library

but anyways, if there was a functional DOM thing in JS that you could use w/ ClojureScript that just got the job done - you could do fairly light weight development easily idiomatically

this is a separate thing then big / complex SPAs - where likely you’ve already chosen heavy solutions

but currently there’s not many super light weight things for idiomatic ClojureScript UI augmentation for web stuff

interesting. I guess hypothetically you would have to split out cljs.core to allow for runtime selection of the underlying primitives, defaulting to the cljs data structures. I'm assuming only an edge case of users would even bother with that implementation unless it were made the default.

like cljs-a-la-carte haha

At least with cljs.core it would be possible -- I was pretty shocked when I found out there were no protocols for things like assoc and deref in clojure.core.

they are both protocols in cljs.core and interfaces in clojure.core

hi all, hi @thheller - I presume you are the author of shadow cljs 🙂

I am very new to clojure(script) ecosystem and I am trying to set up cider with shadow-cljs. I can get REPL all right, but the source file is not seen as the part of the same session.

hey. indeed I am. I do not use cider, so I can't really answer any questions related to that

are you aware of any bug around it? the emacs buffer with gui.cljs has cider[not connected] at the bottom and I cannot M-. (go to source) or C-z (go to repl) from it

ah

thanks, no worries

Ok does anyone have any insight into how cljsjs works? As in, why is it if you provide your own, for instance, cljsjs.foo , I can (:require foo) at the top level namespace form in a cljs project?

is that clojurescript compiler thing?

It saved my a** monkey patching reagent

did the default output of npx create-cljs-app change recently? I just ran this for a different project last week and it did not include devcards or reagent iirc