Hacker News Reader

Comment by john2x | Hacker News Reader

While the level of commitment to backwards compatibility is commendable, I had hoped this would trigger dropping GCL instead of forking it.

My surface level understanding is that GCL is a big reason why 3rd party libraries are a huge pain to use in Clojurescript.

Of course this would have went completely against the project’s goals, so it was never going to happen.

View on HN

I think you are conflating the Closure Library with the Closure Compiler. They are related but not identical. The Compiler, I think, is what makes it difficult to use externs; its “advanced optimizations” can and often does break libraries that weren’t written with the Compiler’s quirks in mind. But advanced optimizations is an option; if you don’t need aggressive minification, function body inlining, etc. you can opt out.

Shadow CLJS has made working with external libraries quite easy and IIRC it lets you set the compilation options for your libraries declaratively.

Ahh right. Yes I am in fact conflating the two.

But can the compiler be used without the library? Or can the library be used without the compiler/would it still be beneficial?

Yes and yes; in the past, prior to ECMAScript providing first-class inheritance, module ex/imports etc, the Library supplied methods to achieve these in development, and the Compiler would identify these cases and perform the appropriate prototype chaining, bundling, etc. See, eg, goog.provide

For the most part, I would guess people still use the Closure Compiler because of its aggressive minification or for legacy reasons. I think both are probably true for ClojureScript, as well as the fact that the Compiler is Java-based so it has a Java API that (I am guessing here) made it easier to bootstrap on top of the JVM Clojure tooling / prior art.

I've been doing frontend development for over 10 years, and obviously it's anecdotal but I never heard anyone use the Closure Compiler outside of ClojureScript, and I imagine that in practice most people doing frontend development are using Webpack, Vite, Parcel, etc. The idea of really small bundles sounds nice, but in practice because the advanced optimizations require manual tweaking in many cases to get it to work (externs) it's something few people would want to deal with and the small bundle size improvement isn't worth it compared to the standard tools like UglifyJS/Terser.

There may be other reasons, but I assume the main reason that the Closure Compiler was chosen for ClojureScript was because it's Java based, so it was straightforward to get working. Moving away from it now would be a huge breaking change, so it's unlikely to happen in the official compiler anytime soon or ever. I think the only way it would actually happen is if an alternative like Cherry got enough traction and people moved to using mainly the alternative.

Yeah nowadays I think non-ClojureScript people use it mostly for legacy reasons or the aggressive minification. Back in the day, aside from the pre-ES5 conveniences I mentioned surrounding inheritance and module bundling, it was also a way for developers to do some basic type enforcement (via JSDoc annotations that the Compiler would check). TypeScript essentially rendered that obsolete.

See: https://effectivetypescript.com/2023/09/27/closure-compiler/

At this point dropping GCL would be a breaking change. Many, many libraries rely on it.

> My surface level understanding is that GCL is a big reason why 3rd party libraries are a huge pain to use in Clojurescript.

I'm sure what "huge pain" your referring to, but I'm guessing it's dealing with name munging when externs aren't readily available. That comes from the compiler, not the library, and can be annoying. Mainly you have to make sure you reference things in ways that won't get mangled by the compiler (get x "foo") instead of (get x :foo). If you want to escape that you can always turn of advanced optimizations.

> My surface level understanding is that GCL is a big reason why 3rd party libraries are a huge pain to use in Clojurescript.

This isn't true.

What you might have heard is that the Google Closure Compiler with :advanced optimizations makes external libraries harder to use. This also isn't true if you use good tooling (shadow-cljs makes using npm libraries transparent and totally painless).

It is worth observing that :advanced optimizations result in a significant speed increase, but are considered too difficult to use in the JavaScript world. ClojureScript was designed from the start to be compiled in :advanced mode, so you get the benefits of an impressive whole-program optimizing compiler for free.

what kind of difficulties come up in practice in :advanced mode for JS? I would have assumed that by now code is pretty good about not using "weird" effects

Externs are the main user-facing hurdle, and there's plenty of JS that doesn't bother declaring its shape ahead of time or uses dynamic access patterns.

Reply on news.ycombinator.com