Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ClojureScript 1.12.42

clojurescript.org

Post reply on HN
Print view View original

11–20 of 45 posts

Re: ClojureScript 1.12.42

#11

Post by Volundr »

john2x wrote: post #9

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.

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.

Re: ClojureScript 1.12.42

#13

Post by john2x »

amgreg wrote: post #10
john2x wrote: post #9

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.

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 op…

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?

Re: ClojureScript 1.12.42

#14

Post by btown »

I wrote about one under-appreciated and still-relevant use case for Google Closure Library a while back here: https://news.ycombinator.com/item?id=41397235 - reposting it here!

> If you want a rich text editor that truly is Gmail's compose editor as it has existed for the past decade - that emits the same structures that Gmail would, handles copy-pasted rich text the same way Gmail does, has the same behavior in typing inside links etc... which is especially useful if you're building an email client that Gmail users need to feel familiar on every keystroke... then following https://github.com/google/closure-library/blob/master/closur... line-for-line is still the gold standard, because it grew from the same codebase as Gmail.

> I've had great success at a previous startup referencing a prebuilt Closure Library from a modern ES6+ codebase and creating a React-friendly wrapper around the editor component, and using this to power an email templating experience. Ironically, I'm within weeks of needing to do it again, thanks to Zawinski's Law https://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski's_Law - "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can." I'll give you one guess what I'll be reaching for, archived or not.

> Others have more context on the history and have written more detailed obituaries - but it's a true testament to the engineers that worked on it, that a library can be so ahead of its time that it's still an industry-leading experience [15] years after its initial release.

I'm happy to see that it's being maintained! (And that project where I was planning to use it again got delayed, but it might be on deck soon!)

Re: ClojureScript 1.12.42

#15

Post by amgreg »

john2x wrote: post #13
amgreg wrote: post #10

Earlier quoted context omitted.

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 op…

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.

Re: ClojureScript 1.12.42

#16

Post by [deleted] »

john2x wrote: post #13
amgreg wrote: post #10

Earlier quoted context omitted.

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 op…

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?

[deleted]

Re: ClojureScript 1.12.42

#17

Post by spinningarrow »

btown wrote: post #14

I wrote about one under-appreciated and still-relevant use case for Google Closure Library a while back here: https://news.ycombinator.com/item?id=41397235 - reposting it here! > If you want a rich text editor that truly is Gmail's compose editor as it has existed for the past decade - that emits the same structures that Gmail would, handles copy-pasted rich text the same way Gmail does, has the same behavior in typi…

Is it being maintained? From the README:

> Closure Library has been archived. We no longer see it as meeting the needs of modern JavaScript development, and we recommend that users look for alternative solutions.

Edit: ah I see that the Clojure folks are going to take that up. I missed that!

Re: ClojureScript 1.12.42

#18

Post by bbkane »

Borkdude wrote: post #2

> We are working on restoring that original stability. With this release, you’ll find that quite a few old ClojureScript libraries work again today as well as they did 14 years ago. > ClojureScript is and never was only just for rich web applications. Even in the post React-world, a large portion of the web is (sensibly) still using jQuery. If you need robust DOM manipulation, internationalization, date/time handling…

From the outside (I haven't tried it), committing to ClojureScript for an application looks very similar to committing to a framework - it's a heavy influence in how you will write code.

Re: ClojureScript 1.12.42

#19

Post by actuallyalys »

bbkane wrote: post #18
Borkdude wrote: post #2

> We are working on restoring that original stability. With this release, you’ll find that quite a few old ClojureScript libraries work again today as well as they did 14 years ago. > ClojureScript is and never was only just for rich web applications. Even in the post React-world, a large portion of the web is (sensibly) still using jQuery. If you need robust DOM manipulation, internationalization, date/time handling…

From the outside (I haven't tried it), committing to ClojureScript for an application looks very similar to committing to a framework - it's a heavy influence in how you will write code.

I daresay ClojureScript typically has a significant influence, but it's more social than technical. Many of the examples and tutorials are going to favor a certain style, and people who choose ClojureScript mostly do so because they like Clojure.

But if you want to do tons of JavaScript interop, you can. If you want to adopt some syntax, you can (through macros). If you want to use jQuery directly, you can. If you want to use a React wrapper, you can. There's not really technical limits pushing you toward a style or architecture, although you still have the underlying limits of JavaScript and the runtime environment.

Re: ClojureScript 1.12.42

#20

Post by swannodette »

bbkane wrote: post #18
Borkdude wrote: post #2

> We are working on restoring that original stability. With this release, you’ll find that quite a few old ClojureScript libraries work again today as well as they did 14 years ago. > ClojureScript is and never was only just for rich web applications. Even in the post React-world, a large portion of the web is (sensibly) still using jQuery. If you need robust DOM manipulation, internationalization, date/time handling…

From the outside (I haven't tried it), committing to ClojureScript for an application looks very similar to committing to a framework - it's a heavy influence in how you will write code.

I'm curious as to how you think this is different from say, committing to JavaScript/BundlerX/NPM or TypeScript/BundlerX/NPM? Surely those have an equally heavy influence on how you write code?
Post reply on HN