-
Notifications
You must be signed in to change notification settings - Fork 85
93k for compiled hello world #480
Comments
Probably the 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 😃 |
There was also a tweet recently talking about that: https://twitter.com/p_cstl/status/1139790337742782466?s=20 |
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 |
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. |
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. |
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. |
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. |
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. |
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 |
Heya, I was using Lumo 1.10.1 and was trying out the compilation as described in https://anmonteiro.com/2017/02/compiling-clojurescript-projects-without-the-jvm/.
For these files:
Running
lumo -c src build.cljs
creates a 93kmain.js
file. I don't know if this is expected. I only use ClojureScript with Lumo, so maybe this is normal and I just don't know.But https://stuartsierra.com/2012/06/16/why-im-using-clojurescript mentions
and https://dev.clojure.org/jira/browse/CLJS-2696 mentions
So that kinda makes me think that the 93k size is abnormal.
Then I tried to change
:target :nodejs
to:target :browser
and that gives me a 6kbmain.js
instead. But then if I change(.log js/console "Hello World")
to(println "Hello world")
I get a 93k bundle again.The text was updated successfully, but these errors were encountered: