Hacker News Reader

Comment by ragnese | Hacker News Reader

For those with experience, would you say that ClojureScript for frontend stands on its own without a Clojure backend?

Absolutely, shadow-cljs is all you need, it's not coupled to the Clojure ecosystem, it uses NPM. I'm actually working on a project that uses clojurscript on the backend which is just a `:node` build target in Shadow.

Same here. I’m slowly writing some wrapper libraries for server side ClojureScript (starting with Express.js).

It’s a fun side project for now, but hopefully I can use it to convince some of my JavaScript loving co-workers to give Clojure a try.

I’m a bit biased, but from my personal experience I would definitely say that it does. I’ve worked on two projects that had different backends (PHP and elixir) where the choice to use clojurescript IMO was the correct one. Both projects relied heavily on highly interactive frontends that would’ve been a nightmare to write if I had to use vanilla js. If your backend can spit out json, and your frontend isn’t static, then I’d say cljs should be good to use regardless if the backend is clojure or not. However, the biggest pain point for me was the disappointment of not being able to use clojure everywhere in the stack... so prepare for that if it’s the route you choose.

It depends on what kind of project you are using it for.

Hobbyist/toy project - sure, using shadow-cljs you can do your front end entirely in ClojureScript and make calls out to whatever backend you want

Professional project with ClojureScript backend - sure, you can use shadow-cljs to target both node (using :node target) and the browser which will allow you to utilize ClojureScript for full stack and not have to rely on Clojure

Professional Project with non-clojure(script) backend - no. It would not be worth it to spend resources to learn clojurescript (talent pool of existing clojure devs is small) and not taking advantage of full stack clojure(script) can be detrimental

> Professional Project with non-clojure(script) backend - no.

Allow me to offer a contradicting point of view. On my last project we used Elixir on the backend and Clojurescript (with re-frame) on the frontend.

Best decision we've ever took. We were orders of magnitude more productive than we would've been with Javascript. And we were all beginners to Clojure at the time.

Re-frame is a beast. Not having to deal with Javascript and its ecosystem is an absolute relief. Once you use Hiccup for the first time, you'll never want to use JSX ever again.

So yeah, if it's a new project in my opinion it is worth exploring Clojurescript, even if you don't plan on using Clojure.

Same experience here except with python as the backend.

We could not have done half the things we did without ClojureScript on the front end.

Also, the learning curve is not very steep if you're just doing a re-frame front ends. You really just need the basic 1/3 of Clojure, and rarely if ever touch all the complex parts.

> Best decision we've ever took. We were orders of magnitude more productive than we would've been with Javascript.

Would probably have been the same boost in productivity if you had chosen TypeScript though. And choosing TypeScript obviously comes with numerous benefits (large pool of developers, ecosystem, first-class integration in VSCode, backed and highly maintained by Microsoft, etc).

> Would probably have been the same boost in productivity if you had chosen TypeScript though

Nope. It wouldn't. You can replace "Typescript" in your sentence with pretty much any other "-script" thing: Coffescript, ScalaJS, KotlinJS, etc., and it still wouldn't be closer to the truth.

The biggest advantage of Clojurescript is out-of-the-box support for interactive development. You are connected to your running application. And without any ceremony, without re-compiling or even saving anything on the disk, you can tweak the program without resetting the state of it. If you have never experienced that first hand, it would feel like it's not a big deal. Alas, it really is.

Clojurescript right now (at least for me personally) is the fastest way to prototype anything for the browser. Building things like web-scrapers feels like magic. You just run the program, connect to it and keep experimenting with things until you get the results you want. No other language ecosystem today gives you that liberating feeling. Almost everything else feels too formal and bureaucratic - can't do "this" without "that". It becomes pretty tedious and often removes "the fun" from programming.

So, yes, I attest to that - Clojurescript can give you incredible productivity boost.

It seems fairly subjective. I'm familiar with Clojure and happily use it at work, but I haven't seen anything in CLJS that comes close to the power of automatically generating types for GraphQL queries, for example. With a single command, I get notified if some client queries do not respect the server schema, plus separate types for each response which provides autocomplete and information about each field (type, nullability...) right in the editor. I don't feel the need to reload a bunch of times because everything usually works on the first try. I still need to tweak the CSS but I tend to prototype that in the browser dev tools anyway.

I'd pick CLJS over JS but not over TS.

On the backend, I'd pick Clojure over both JS and TS in a heartbeat, though.

I admit I have not used GraphQL in Clojurescript. However, Clojure has its own type-system. Of course, purists would argue that Clojure.spec cannot be categorized as a type system, albeit it is, and you can do pretty cool things with it.

For example, you can build a suite of specs that denote a ledger - where amounts in every transaction depend on each other. That is not a trivial task - most other type-systems don't give you good instruments to achieve something like that. You can then use those specs to generate data for property-based tests.

You can also use them to validate the data flow in the back-end for different data stores. And re-use the same specs on the front-end for input validation. Clojure and Clojurescript allow you to get as much code-reuse as possible (even though the code has to run in completely different environments).

> I don't feel the need to reload a bunch of times because everything usually works on the first try.

Perhaps you haven't had to build reasonably complex front-end applications, where a user has to go through many steps in the UI. With a lot of state and state transitions involved. I spent several years building web-front ends. Used if not all, but most popular ways to compile/transpile/deal with Javascript. I'd choose Clojurescript, because it makes sense for me today.

Tomorrow perhaps something better comes up. But Typescript today is not an option for me. I have tried it multiple times in multiple projects. "Joy of Typescript" doesn't even sound right. "Joy of Clojure" though is a thing. People love Clojure and Clojurescript, and not without good reasons.

I currently use Typescript at my day job, and before that I used Elm.

Based on my experience, no, it's definitely not the same boost. Elm felt more productive than Typescript, and Clojurescript felt more productive than Elm.

And yes, when compared to Javascript, Typescript is awesome and well worth the investment.

I'd say so. I used it for a relatively large front-end (leveraging Reagent) with the backend served by Django Rest Framework. Worked beautifully!

Definitely so. We use Clojurescript with Python backend and it's great. Clojurescript is very good at json processing/manipulating, so it does not matter what backend you have.

On a related vein, is cljs viable for PWAs and purely static front end only apps?

I would say so, I have implemented a pwa https://djblue.github.io/portal/ hosted via github pages for people to browse through their data-structures. You can also connect the ui to a live host and send it data directly with tap> (kinda like console.log in js).

Reply on news.ycombinator.com