what kind of use cases do people have for including something like datascript in their app?

All, struggling with the Clojurescript idiom that deals with child classes of Javascript libraries e.g.

class Foo extends Bar

so there’s not a super easy way of doing that in CLJS, since Clojure doesn’t really have first-class support for inheritance

the important thing to know is that class Foo extends Bar is JS syntax sugar on top of prototypical inheritance. so we can use the underlying prototype to do this.

another way of writing class Foo extends Bar would be:

Foo.prototype = Object.create(Bar.prototype);
Foo.prototype.constructor = Foo;

there are some helper functions in the goog.object namespace we might find useful:

(ns my-app.thing
  (:require [goog.object :as gobj]))

(defn Bar [])

(defn Foo [])

(gobj/extend (.-prototype Foo) (.-prototype Bar))

(set! (.. Foo -prototype -constructor) Foo)

And if you feel compelled to have more sugar - there's macros

what does the ^not-native type hint actually do? I’m trying to optimize some paths that use a lot of a particular protocol, which is extended to native JS types (string, number, nil) as well as CLJS/user types like Keyword, PersistentVector, and Object

Hey there, I'm trying to optimize my bundle with shadow-cljs, in particular by trimming down cljs.core as much as I can. I've got a reproduction of just a small proof-of-concept here: https://github.com/staab/shadow-tiny The problem I'm running into is that if I use anything in core, my bundle blows up in size; currently I'm just invoking a couple core functions, and the size of cljs.core.js alone is 97k. Is there any way to improve this? I was thinking of maybe using refer-clojure in all my namespaces, but the docs say "The only options for :refer-clojure are :exclude and :rename". I'm also not sure if this would work, because it does appear that google closure compiler is properly tree-shaking things (`cljs.core.js` is only 1.1k if I remove the body of my main function, and my other project's cljs.core.js is 136k).

have you used the shadow-cljs build report?

it can give you better insight into what’s taking up space

I haven't on this project; I tried it on my main one yesterday and it crashed so I moved on

let me give it a quick go

that might a good thing to report if you have the time

This is my source code though:

(ns shadow-tiny.core)

(defn ^:export main []
  (print (map inc [1 2])))

I think what you’re going to run into is that the CLJS data structures weigh about 60-80kb un-gzipped

Ok, so I guess there's just not really a good way to avoid that

Is there a way to use a CDN for cljs core?

no, because it will tree-shake and remove things you don’t want

if you used a CDN for cljs.core it would be even bigger

Bigger, but hopefully aggressively cached

Preact/redux are a total of 5k (gzipped), and I'd like to get cljs to compete with that somehow

it looks like my toy project is 88k gzipped

Is there any prior art on this you know of? I haven't been able to find any articles about tiny bundles online

preact and redux are much smaller in scope than CLJS (the language)

it’s comparing apples to oranges

It's true, but as far as delivering something to users, I'm more willing to suffer with js than bloat my bundles

for perspective, immutable.js is ~64K minified

ouch

Man, I love immutable data structures, but I'm not sure they're worth the cost

I think they are 🙂

heh

88K is honestly not enough that I would start to balk. that’s not going to strain my users

hmm I think I'm misusing du too, it should be smaller than that

ls gives me closer to 35k

@jstaab CLJS isn't really suited for "tiny" bundles since you are always going to end up with cljs.core and the datastructures

its never going to compete with preact/redux

@thheller thanks for the confirmation, that's what I was beginning to suspect

but it'll easily beat preact/redux/immutable/lodash

which you are basically getting with cljs.core

do you have any strategies for alleviating the burden? I'd love to use it everywhere, and with cljs.core aggressively cached on a CDN that seems feasible

there's really not much more you can do

I’m setting up SPA routing without /#. I’ve configured webserver to always return index.html. Basic stuff works but I’m having trouble with nested routes like . My build tries to find /foo/js/compiled/out/goog/base.js when it actually exists in /js/compiled/out/goog/base.js. Same for deps.js and deps_cljs.js. What knobs I need to turn to make those paths absolute?

use code splitting .. but no CDN caching cljs.core is not possible

code splitting is the answer if you want to limit the initial payload - but fundamentally we start around 22K-25K gzipped and go up from there

given modern JS development - we are in fact very light weight

CDN caching is not possible meaning not supported/worth supporting, or is there something more fundamental going on with how it's linked?

and not really interested in investing more time beyond what Closure gives us

Ha @dnolen I've been reading some Henrik Joreteg lately and it's inspiring me to change that

sure

but I don't really sympathize that much with such efforts - Closure fundamentally does the only interesting thing that can be done

the only JS project that understands this is Rollup

hand optimizing payloads is a massive waste of time IMO

I buy that for sure

Cool, thanks all for the answers, that was super helpful

Svelte is also interesting - but I can't find any data on that on really large projects

but my hunch is once you factor in all the dependencies you actually need, internationalization etc.

Svelte is interesting

it doesn't add up to much

yeah, I trimmed down my moment-timezone bundle yesterday

which is probably why don't find anyone bragging about non-toy stuff

saved me 800k

so suffice to say, I think ClojureScript and Closure are still state of the art, the real answer is make sure deps can be dead code eliminated

I think ClojureScript core is like 75,000-80,000 lines of generated JS or something

and you get 22K gzipped as the starting point

Yeah, that makes sense

If there were fewer macros, would bundle sizes shrink? I suppose run times would grow commensurately though

macros don't contribute to bundle size at all

macros don't contribute

Really? I thought they were evaluated during build time, so if I had (defmacro x [] "blah blah blah") and used it a bunch, wouldn't the output be bigger? Or do you mean it's just negligible?

the code they generate end up in the JS. the macros themselves don't.

so yeah if you generate a bunch of code they can affect the bundle size if emit the same stuff over and over again

I see what you mean, the output would be the same whether you used a macro or manually wrote everything out longform, unless your macro is bloating the output unnecessarily

Anyhoo, thanks for your time, both of you

@jstaab right and if you don't use it, it will still get eliminated from the final build

has anyone done custom transitions with material-ui? Can someone point me at a snippet written in Clojurescript? I need to make something that can’t be done using default transitions: Collapse, Fade, Grow, etc. I don’t want to waste too much time learning all the intricacies.