Hacker News Reader

Comment by Borkdude | Hacker News Reader

> 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, color value manipulation, mathematics, programmatic animation, browser history management, accessibility support, graphics, and much more, all without committing to a framework and without bloating your final JavaScript artifact - ClojureScript is a one stop shop.

View on HN

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.

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?

In what way? Can you elaborate on how your choice of package manager or bundler affects how you write code, except maybe for something like import.meta.env vs process.env?

Committing to a bundler in JavaScript is a lot easier than dealing with clojurescript. JS bundlers are mostly standardized with minor differences; a complex application running on yarn can almost always be swapped out for pnpm with no or few configuration changes. On the other hand for clojurescript you have to understand the clojurescript runtime, the the JS runtime, various clojurescript and JS idiosyncrasies (clojurescript specifically blurs the line between compile time and runtime, and something as simple as reading a file into a global variable at runtime would require a lot of hacks to get working reliably) if you want to truly make the setup work for you.

Neither yarn nor pnpm are bundlers. The buy in for bundlers is a lot higher than for package managers

You wrote bundlers/package managers. I assumed you are conflating the two to be the same. Anyways most new bundlers have a (mostly) Webpack compatible (or are working towards it) API so it's a moot point.

Is that not true for any programming language?

At work, we use what is required as fashionable framework of the day.

On side projects, I don't see the issue with keeping using jQuery for as little JavaScript as possible, especially since it is still much more ergonomic to use than the browser APIs that got added later.

Reply on news.ycombinator.com