how do I port this protocol to clojurescript? https://gist.github.com/e883526c5db2448c38f692f6eeda952d

it works in Clojure but Cljs compiler yells "Use of undeclared Var <some namespace>/Number"

js/Number or number should work

what about Boolean and String?

and why is so?

same for boolean/string

protocols are first checked on the type itself. if not found it checks typeof(thing) which returns string, array, object, boolean, etc for JS

but protocols on native types can be a bit wonky depending on the JS engine

IE had troubles with that in the past

safari too IIRC but I think that was a long time ago

thanks, I'm trying it now

I’ve been really interested in network transfer size lately and have noticed there is a rather large default size for cljs code aimed at the browser (haven’t tested node). I did a console log hello world using figwheel main and it was like 5.5kb. Cljs.core I believe is around 30kb which is what one would expect when using a bunch of cljs features and libraries. Using Preact and other @developit libraries people have created whole PWA’s for as little as 14kb. I personally believe in using a tool that understands the entire application and optimises based on that is the best way to go. So I am quite impressed with what I read over on Elm https://elm-lang.org/blog/small-assets-without-the-headache I haven’t delved too much into it but my assumption is that these libraries are smaller based on using modern/new JS features. I’m curious if GCC has any flags or plans to use modern JS features if this is the case. Is it possible for cljs to compete on smaller file sizes for very very small applications?

GCC is already substantially better than ALL other JS tools and supports pretty much all modern features

cljs.core will always be used in any real application and that includes the immutable data structures

so when comparing it to JS builds compare it to something using immutable-js + lodash or so

use of any modern JS features will not affect the size in any meaningful way

so no CLJS won't compete on those very very small applications

the closure compiler pretty much already does what the elm post describes and soooo much more

(don't get confused by the 5.5kb min size, that is just not a case we optimize for. it would literally be console.log("hello world") if we did)

@grounded_sage I would consider ~30K to be pretty small, given that most other assets will be much larger, if you stick with Google Closure this is actually not that hard to achieve

IMO CLJS is actually pretty great for doing simple static sites where you need a little bit of scripting

@dnolen Why would you bother with cljs for a little bit of scripting if you are not using react? honest newbie question

because I would rather write that in ClojureScript instead of JavaScript? 🙂

write?

oops yeah

I'm pretty comfortable with JS, but ClojureScript just has a lot affordances

plus anything basic I want is in Google Closure

if I write in JavaScript then builds are often more verbose, and you have to go find dependencies etc.

surprisingly I find ClojureScript cognitively less overhead than modern JavaScript for simple stuff

Definitely cljs is much nicer to write in. React sometimes isn’t necessary I’ve been creating static sites in Rum using React but sometimes React isn’t needed so was writing scripts. Been doing a lot of vanilla JS scripts because some pages I get down to less than 10kb. Excluding images of course.

I see, so is common to leverage the closure lib?

The closure lib is hard to find documentation for, but it’

it’s pretty good.

@dnolen but yeah, although 2019 JS is much better than it used to be (Object.fromEntries, etc..) it is no Clojure 😉

The drag and drop library in goog.fx is nice

anything of nominal complexity I appreciate having Clojure data structures + standard library

even if I'm not using React

@jimberlage good to know, I though it was mostly used only for namespace stuff

exactly if I would have to cobble together a couple of JavaScript libs and write more than 200 lines, then I'm gonna use ClojureScript instead

From what I can tell from looking at things in the wild and playing around with them a little. You can keep a JS app even something quite complex relatively small much smaller than what can be made in cljs. Though it bloats much more quickly. Especially once you head north of 100kb JS.

so that's pretty much anything that isn't completely trivial

@grounded_sage that's never been my experience and I know JavaScript pretty well

not without hand picking every (micro)lib anyway, or relying very heavily on very modern JavaScript (implementation) which still isn't that practical IMO

if bundle size is one of your top requirements, and you're willing to invest heavily in pruning and picking and writing code that is optimized very well for JS bundlers/minifiers, then CLJS will not be your best solution

I just disagree

people built websites with jQuery for over a decade

and still do

if jQuery is small enough, ClojureScript is small enough

but if it's a middling concern, I find CLJS provides much better bang-for-buck in terms of how much I have to think about code size vs. what I get

if all your assets are magically tiny

which isn't possible

anyways - the microlib thing was a fad as far as I'm concerned

but the pendulum has swung the other way with React

where one deps means mb of JS

Yea it does take way more work to keep it small in vanilla JS. Something I’m not really interested in which is why I was curious.

I also think about how the impact on the UX is not linear w.r.t. bundle size

Preact is doing quite well IMO. I saw something about Uber having a ~50kb app build on Preact.

I can't think of many JS apps I'd need to write that would be severely hampered by a few hundred KB of cljs deps

what is the size of a hello world react with cljs (rum or reagent) ?

ClojureScript baseline is like 25K, and you go up from there with each lib you add

ah nice, sounds pretty good for a pure cljs (with react) in my case

ClojureScript benefits from DCE, but the mileage is still a bit variable if it's not Closure stuff, but it's definitely better than anything in JS except for probably Rollup

I think React is 35kb at the moment? So that’s like 60kb @lockdown- then there is Reagent as a lib which I don’t think would add much.

I have a moderately complex app that uses a few libraries: React, react-grid-layout, re-frame. it's 100kb un-gzipped

What does that gzip to @lilactown?

@lilactown is that a SPA?

@grounded_sage we're only talking about gzipped

oh sorry I see that @lilactown mentioned his app

Yea I know. He said un-gzipped.

All good

IMHO code-splitting (aka :modules) is still very underused which solves pretty much all size issues since you can delay loading until required

@grounded_sage Up to 150Kb (for mobile) would be good for me, just planning to enhance a web app, not sure if going with react or not, react makes things simpler even for little enhancements I guess

You know what might be interesting... a version of code splits where you can keep an existing compiler env cached for later compiles, so that future modules can depend on the same cljs-base.js... then you could cache your app's base for longer and newer updates could just layer on super-minified updates.

@tundawork1 something like that is already possible

Google Closure supports reusing names across different builds

this means base is unlikely to change

Like, if you just keep a compiler watch going?

no

across builds

ah

doesn't matter when you build

nvm, that is gzipped @lockdown- 😅 @grounded_sage

Yea if I am building something with a bit of complexity or is an unknown/uncontained domain I would definitely use CLJS all the way. But for really small stuff I think JS maybe even Elm might be better in some cases.

@dnolen can you give me a pointer on more info there? I'm banging on a bunch of code-split stuff atm and it might be a worthwhile exploration

https://clojurescript.org/reference/compiler-options#stable-names

the gzip didn't show in the headers, but I doubted myself so I actually pulled it down and looked on disk how big it was

@dnolen thanks!

ah that's cool

how should I handle unknown tags when reading EDN?

I’d like to just pass them through, but I’m not sure how to do that with cljs.tools.read.edn

@lilactown I recall there being relevant information here: http://insideclojure.org/2018/06/21/tagged-literal/

very interesting. thanks!

np

yep, that pretty much does exactly what I want 😄

;)