93k for compiled hello world about lumo HOT 9 OPEN

Probably the println function involves some very-had-to-tree-shake core functionality. This is a well-known ClojureScript problem and the usual answer is that in case you will need to include core at some point and therefore you'll end up with more than 90kb, which is comparable to including jQuery.

This is the price we, as ClojureScript devs, are willing to pay for the the language we like but I am sure not everyone would agree 😃

from lumo.

There was also a tweet recently talking about that: https://twitter.com/p_cstl/status/1139790337742782466?s=20

from lumo.

90kb is still to bigger for many JavaScript developers if they think the size does not provide any actual features. We sometimes use Webpack to analyze the size in the project to see if we can reduce it. 90kb is definitely worthing looking into.

I'm fine for 90kb in my ClojureScript projects. But to be honest I have tens of small projects built with ClojureScript, and it might be like 90k * 20+ and in total 1800kb+ for me. Turned out Google Closure Compiler is not that powerful in some way. I would really like to try if there's some solution for reducing the number.

from lumo.

JavaScript developers if they think the size does not provide any actual features.

I think this would be the main point. For me a "feature" of ClojureScript is maintenability so I would also always make that trade-off. I understand though not everybody is on the FP+simplicity boat in which case they would not probably use ClojureScript to begin with.

from lumo.

It's trade-off. Meanwhile ReasonML is another example of functional programming language that we can compile to JavaScript with simplicity and maintainability with less time and get smaller size. Although the language is different and Clojure has too many features, I think the main factor is ClojureScript does not has its own code optimizer and Google Closure Compiler does not try to fit into the case of ClojureScript. One day when ClojureScript is compiled to WASM and there a powerful optimizer for WASM, ClojureScript would get a smaller size.

from lumo.

Meanwhile ReasonML is another example of functional programming

Agree it is tradeoffs, but there another interesting thing to point out - does ReasonML include persistent data structures? If so and it is smaller, then I would definitely like to know what they are doing and port it over to ClojureScript. See, for me maintainability comes directly from immutability as default (yes you can rarely escape but it is discouraged, like in Clojure). More specifically this is the trade-off worth making IMHO.

from lumo.

Also worth noting that things like https://github.com/santoshrajan/lispyscript exist folks that like lisp but don't need immutability as first class citizen.

from lumo.

Personally I don't have a strong opinion one way or the other regarding the design and trade-offs, but rather wondered if there was some overhead related to Lumo's implementation. Like injected code that introduced references that couldn't be shaken out.

from lumo.

I don't know in detail and OCaml turns out to have mutable Vectors somehow, this is a different from Clojure. But I do heard that they are doing lots of analysing and optimizing during compile time to generate smaller and faster code: https://github.com/BuckleScript/bucklescript/wiki/Why-bucklescript-matters-for-Javascript-platform#how-does-it-compare-with-other-transpilers

from lumo.