> Yes. Currently optimization is something we are doing when compiling > clojurescript, but perhaps *ideally* optimization could be done after > bundling when all the javascript is available. However, I realize this > may not actually work very well in practice since most modern js > applications include dozens or hundreds of npm libraries that are not > closure ready and would break in unexpected ways. Perhaps this is why > UglyifyJS is more common for webpack users? UglyifyJS does dead code > elimination as well I believe, is it as good? probably not? is it good > enough? not sure. >
UglifyJS is not good enough in my opinion, not even close. The JS world has "accepted" that you need to make lots of many small files to make it acceptable. We don't since we have Closure. > Do we still need analyzer data after its compiled? Can't we just use the > javascript as a lib? I assume that google closure isn't written in cljs but > cljs has no problem using or optimizing it... perhaps the packages are > distributed as unoptimized google closure compatible js and the webpack > plugin turns google closure modules into commonjs modules? not sure. just > ideas. > You need to analyzer data if you want to compile any .cljs. It is not needed at runtime (which is where the closure library comes in). > Best optimized perhaps, but possibly not the best js dev ux. Many js > developers don't want to run java as part of their build process and might > prefer to use uglifyjs even if the results are not as good. > But many js devs do optimize and the best results would probably be to put > the unoptimized closure together with the unoptimized javascript and then > optimize everything together. But my guess is that wont work in practice. > UglifyJS I think is safer than closure, as good? probably not, good > enough? not sure. Your solution probably produces best optimization, but > its worth asking if thats what devs care about the most? Slower build > process with more complexity vs a faster website. There will be devs on > both sides I think. > This is one place where it is far more important to optimize for production users not the developer UX. I care very little about the fact that my production build may take a while longer if the resulting .js my users have to download is substantially smaller with much better runtime performance. The fear of Java is unreasonable and mostly FUD. If I run builds with create-react-app or create-react-native-app they are frequently much slower than a :advanced compiled CLJS build. There are still lots of places where we can optimize the dev UX but production concerns will always come first. JS integration is still a work in progress and will get a whole lot better soon. Stay tuned. ;) /thomas -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
