Fork me on GitHub

hi, does clojurescript have this feature? functions accepting both keywords and maps by default?


The version I'm using clearly doesn't but wondering if any do/ there's an accepted workaround / it's on a roadmap

Alex Miller (Clojure team)03:09:39

that is still in an alpha version of Clojure so has not been ported to ClojureScript yet afaik, usually that kind of syntax thing waits for Clojure to release first (because sometimes it changes between initial introduction and final release)


got you, do you think it will go across?


A coworker of mine is reluctant to use Clojurescript for our frontend cause he says the bundle size is too big, are there any references or articles available that would verify this?


@hewrin compared to what?


Modern JS bundle sizes are terrible


@hewrin somewhat related, I looked at TTI for some demo cljs react apps here.


ClojureScript never got bigger than jQuery

🙌 2

So the one he is partial to currently Mithril.js


ask yourself if you're optimizing for the correct parameter(s)


ClojureScript is around ~25-30k gzipped


still, if you go down the React route - it's very hard to control the bundle size


@hewrin A neat tool to show how things contribute to bundle size is the shadow build report


@borkdude JS libraries are very liberal w/ the dependency graph


@hewrin it appears Mithril.js could be used with ClojureScript - but it's not that popular of an option


so that probably a 40-50k gzipped baseline - but that is a small image so I don't know - it's worth investigating - definitely not worth dismissing ClojureScript over

maleghast13:09:16 - Mithril under CLJS - not maintained, but it might be a good starting point..?


@dnolen So if I use Reagent, I’d have the same issue as React right?


Thanks for the tip @borkdude! I’ll test this it out!


oh Moria looks cool! @maleghast


In nbb I'm getting about 11kb gzipped for reagent only


you'll have to add React to that as well, and that's it, if you don't use any other deps beyond those


Oh yeah, I heard React is quite small, its all the other stuff that causes bloat.


reagent itself is smaller than react, it's just a wrapper


Oh I didn’t know that, I thought it would be larger, like React + some Clojurescript


note that including certain things like cljs.pprint can also add another 100kb or so (ungzipped)


Hi sorry to jump in between but I was quite dazzled by the bundle size differences your project and ours. In the attached image you can see that our project’s cljs is huge compared to yours. I felt maybe it might be something that we are doing wrong since 236 KB before gzip is still huge I guess. I’m pretty new to cljs and shadowcljs so any direction might be useful. Thanks!


what are you comparing against?


What I'm showing here is just one module of several


and this is a non-typical app, it's a scripting environment which offers several modules which are lazy loaded


I was just wondering what changes the size of the cljs.core (yours is being 1KB for core.cljs however mine is 227KB) or any other library that is imported, I had a first assumption of it might be related to imports but again I’m pretty new to cljs so I was looking for guidance to investigate it further.


this is just because it's one of the optional modules


in the main module there is the true size of cljs.core


I think for every module it creates some kind of stub for the things it needs from other modules


So I guess it is really important to think about main module for a single page app, so that initially loaded bundle size would be optimised.


yeah, but I would only optimize this if people experience this as a problem

👍 2

thanks for your time, I have a better understanding for it now.


also reporting hook is a great I’ve added it to the project already 😄


Interesting! Thanks for this!


Got a .cljc puzzle here. Background: My Matrix library is all .cljc all the time. I have macros that work for both clj and cljs consumers, but only if I use :refer-macros. Not the end of the world, but in a cljs-only MatrixRN (for react native) I can use the trick of defining macros in a clj and requiring them from a cljs. Puzzle: how would I convert my .cljc code to allow a client library to Just Use :refer(tm)? Would it be simply doing the dup filename trick in the .cljc? ie, move the macros out of the .cljc into my-macros.clj and then have a my-macros.cljs pull those in? Just thought I would ask in case someone knows off the top of their head. If not I will start experimenting. Thx! 🙏


If your CLJ-specific code and CLJS-specific code are sufficiently different, just put them in separate files. CLJC files make sense only when there's very little difference. That thing aside, I think, you can use :refer-macros in a CLJC file in a reader conditional in its :cljs branch, where the macro would be defined in another reader conditional in its :clj branch.


Ah, I see dnolen has said the same thing in the main channel.


I would expect core.async to also significantly bloat things, but I haven't tested. So there are a few things to watch out for if you care about bundle size, but this shadow tool should give you a good impression


Although forgive my ignorance, but actually I don’t have a sense of proportion with bundle sizes, so what would be a good limit to be under for bundle sizes?


I've been working on an app for 5 years and the unzipped bundle size is about 3.3mb (1mb gzipped). We haven't had any complaints from customers about bundle size or slow JS performance. There are a few areas in our app that don't perform well in the presence of a lot of data, but this is a general React problem, not CLJS specific, also not related to bundle size.

👍 2

Most of our customers aren't mobile users though, mostly desktop. So I think you should think about what is your audience and optimize for that.


Yeah I agree, thats good advice. For our usecase our customers use their phone and can be deep in warehouses where internet connection could be an issue.


@hiskennyness you understand the dupe file name trick. you don't need to separate if you have .cljc - you can self require the macros and your brain explodes 🙂


It woiks!

(ns tiltontec.model.core
  #?(:cljs (:require-macros
             [tiltontec.model.core :refer [cFkids with-par]]))
    [clojure.set :refer [difference]]
    #?(:cljs [tiltontec.util.base
              :refer-macros [trx prog1 *trx?* def-rmap-slots]]
       :clj  [tiltontec.util.base
              :refer :all])
...etc etc


more or less how bootstrapped worked


self require the macros?! Diabolical! 🙀 Thx, @dnolen, I will give it a shot.


data_readers.clj and data_readers.cljc are interchangeable now, right? They both should work with clojurescript?


I believe it should


It seems to work in my case where I'm just calling a record constructor. Seems like there may be subtle differences in general described here: though I'm not sure if the data_readers file extension is relevant here or just context where the thing is read


@jjttjj that JIRA ticket is mostly about conditional reading - though it should work if the names for the fns are the same - which is probably a good idea

👍 2

@jjttjj I updated the wording on that github ticket a bit to make things clearer. The file extension does make a little difference I know of, If it's cljc the vars it refers to will be required for you, but not if it's .clj.

👍 2