Fork me on GitHub
#clojurescript
<
2019-05-02
>
andrethehunter07:05:30

All the assertions fail. As soon as the empty let block is removed, it works.

andrethehunter07:05:49

Putting the empty let block before the (let [f ..., also works

andrethehunter07:05:31

It only break when we define the destructing fn in a test ns. In normal code we can use varargs destructuring fine

axrs07:05:54

The tests are being run by #shadow-cljs in Karma and various browsers

Ferdi14:05:15

good evening! I need to decode a string to base 64. In clojurescript is a namespace cljs.source-map.base64 with decode. But its not working it throws cljs.source_map is undefined.

thheller14:05:10

@ferdi.kuehne use the closure library. (:require [goog.crypt.base64 :as b64]) in ns and then (b64/encodeString "xxx") or (b64/decodeString "a base64 string")

joshkh15:05:50

for those of you who write single-page apps in clojurescript, what's your average / ballpark file size when using advanced compilation?

dnolen15:05:15

@joshkh that's really just a function of your deps, especially non-ClojureScript, non-Closure

dnolen15:05:52

you could write everything with ClojureScript + Closure and it could be quite small - I do that for blogs etc.

dnolen15:05:17

if you're going to use a Webpack build then nearly all of your payload is going to be what you expect from a JS build

dnolen15:05:20

aka. massive

dnolen15:05:48

best viewed in Chrome

dnolen15:05:09

it's 4K written in ClojureScript w/o persistent datastructures or most of the standard lib

dnolen15:05:25

w/ standard lib you're about 22K gzipped

dnolen15:05:37

add React, add 40K gzipped

dnolen15:05:42

and you just keep going up from there

dnolen15:05:25

ClojureScript & Closure libs grow slower because they can be tree-shaken

dnolen15:05:36

but JS libs are broken in this regard

dnolen15:05:40

so you have to eat the whole cost

joshkh15:05:20

cool project! and thanks for the response. i struggle to keep my usual re-frame / reagent / routing / <insert usual cljs dep here> apps under 1mb (uncompressed), and that's without cljsjs or node-js deps. hmm.

dnolen15:05:33

we don't care about uncompressed though

dnolen15:05:44

only gzipped, because that's the only thing that you're going to do in production

dnolen15:05:55

there are tools to examine what's contributing the final payload

dnolen15:05:11

(I don't have any links handy)

joshkh15:05:39

no worries, i'll do some digging. thanks!

dnolen15:05:21

still you're gzip size is probably 120K or something right? I would consider this acceptable

dnolen15:05:32

if you want something smaller you might wanter consider React w/o frameworks

dnolen15:05:36

possible now because of hooks

dkrieger17:05:05

when you say React w/o frameworks, do you mean not using reagent? Or simply sticking to reagent's first- and second-form components (i.e. just the hiccup-esque templates and pure functions) and using hooks instead of using lifecycle methods?

dnolen21:05:36

hooks kind of obviate the need for needing to use a shim library

dnolen21:05:07

but yeah you would need something if you still want hiccup

jakemcc22:05:44

I can’t endorse as I haven’t used it, but I stumbled across https://github.com/Lokeh/hx the other day. Seems like it allows hiccup with react hooks. https://github.com/Lokeh/hx/blob/master/docs/why-not-reagent.md @UJCC8TWBZ

dkrieger18:05:31

hmm... So I used to use recompose heavily when I was writing a lot of React/JSX. Recompose has been deprecated due to hooks making it redundant. Hooks are definitely an improvement over writing classes, and I wish reagent had at least some ability to incorporate react hooks (the lifecycle ones, anyway), but I don't think I'm ready to give up reagent's state management yet -- it's really nice how little boilerplate is involved. I'll probably switch to hx down the road, but for now I'm going to stick with reagent so I can focus on other things.

joshkh15:05:56

around there, yeah

dnolen15:05:36

but based on what you've said

dnolen15:05:00

it's obvious that 50% of 120K is just React and cljs.core, and your other deps / app are the rest

dnolen16:05:00

@joshkh also don't forget about code splitting, as your app scales that becomes important to do, and Closure is really good

dnolen16:05:48

fwiw I just don't think people understand that until you can DCE large deps - you're never going to get out of this hole

dnolen16:05:33

i.e. projects like Svelte are cool - but it doesn't fix the fact that when you drop in MapBox or CodeMirror none of that effort matters

dnolen17:05:44

somebody should write a post showing that it's equally easy to do this with ClojureScript 😉