This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (1)
- # babashka (28)
- # beginners (212)
- # calva (13)
- # clara (3)
- # clj-kondo (39)
- # cljsrn (1)
- # clojure (16)
- # clojure-australia (1)
- # clojure-europe (11)
- # clojure-nl (2)
- # clojure-spec (9)
- # clojure-uk (8)
- # clojurescript (66)
- # cloverage (3)
- # code-reviews (16)
- # cursive (12)
- # data-science (2)
- # datomic (118)
- # events (1)
- # garden (2)
- # improve-getting-started (1)
- # introduce-yourself (1)
- # jobs (4)
- # missionary (5)
- # numerical-computing (1)
- # off-topic (5)
- # pathom (3)
- # polylith (71)
- # re-frame (99)
- # reagent (17)
- # remote-jobs (5)
- # shadow-cljs (35)
- # tools-deps (5)
- # xtdb (4)
hi, does clojurescript have this feature? https://clojure.org/news/2021/03/18/apis-serving-people-and-programs 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
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)
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 somewhat related, I looked at TTI for some demo cljs react apps here. https://widdindustries.com/clojurescript-datetime-lib-comparison/
@hewrin A neat tool to show how things contribute to bundle size is the shadow build report
I recommend using this with
@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
https://github.com/owengalenjones/moria - Mithril under CLJS - not maintained, but it might be a good starting point..?
you'll have to add React to that as well, and that's it, if you don't use any other deps beyond those
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!
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.
I think for every module it creates some kind of stub for the things it needs from other modules
these are all my modules: https://github.com/borkdude/nbb/blob/5b9027828b7059f466449e868368043f73d99422/shadow-cljs.edn#L9-L21
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.
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
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.
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 🙂
(ns tiltontec.model.core #?(:cljs (:require-macros [tiltontec.model.core :refer [cFkids with-par]])) (:require [clojure.set :refer [difference]] #?(:cljs [tiltontec.util.base :refer-macros [trx prog1 *trx?* def-rmap-slots]] :clj [tiltontec.util.base :refer :all]) ...etc etc
This article by @U05224H0W https://code.thheller.com/blog/shadow-cljs/2019/10/12/clojurescript-macros.html together with those two sections https://clojurescript.org/about/differences#_macros https://clojurescript.org/guides/ns-forms … were useful for me to understand using macros from CLJS.
data_readers.cljc are interchangeable now, right? They both should work with clojurescript?
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: https://github.com/clojure/clojurescript-site/issues/371 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