ClojureScript 1.10.844 • Hacker News Board

Re: ClojureScript 1.10.844

#71

Post by _e » Wed, Apr 07, 2021, 4:48 PM UTC

beders wrote: post #39

This is great! What is not so great is that Google's closure team (not be confused with clojure) decided to remove various functions, making breaking changes - for no obvious reasons other than saving a few lines of code. Example Things like `goog.isArray` is gone, a library that was adopted by many (including the CLJS compiler) to help smooth out the differences in JS versions and supported features. The closure tea…

These are great points. Google's Closure is open source with an Apache 2.0 license [0]. This is a huge ask but do you think a fork of Google's Closure with the goal of minimizing breaking changes be embraced by everyone who currently rely on Google's Closure?

[0] https://github.com/google/closure-library/blob/master/LICENS...

Re: ClojureScript 1.10.844

#72

Post by pandeiro » Wed, Apr 07, 2021, 5:40 PM UTC

raspasov wrote: post #43

pandeiro wrote: post #36

Earlier quoted context omitted.

Do you know if shadow-cljs support source maps for React Native? (Their absence was a really significant pain point when I worked on a production CLJS/RN app.)

You need two source maps: one produced by ClojureScript and one produced by RN Metro. When you get an error with a stack trace from RN, you need to walk the source maps in the correct order to find where the error in the CLJS code originated. I wrote some custom code to do this but I haven’t polished it/made it into a lib at this point.

Sure, I understand. But that's several orders of magnitude less useful than what one gets in eg the chrome devtools console from a CLJS webapp.

I found this to be a major timesink when debugging things, and never came up with a good bulletproof solution to automate this traversal. It was especially painful with random breakages due to NPM's automatic dependency/transitive dependency upgrades due to version ranges (ie, things that don't just fix themselves by checking out a previous known good version).

Re: ClojureScript 1.10.844

#73

Post by pandeiro » Wed, Apr 07, 2021, 5:42 PM UTC

achikin wrote: post #51

pandeiro wrote: post #21

Earlier quoted context omitted.

My impression is that CLJS, while an amazing way to write frontends with react, suffered from an incomplete/fractured tooling ecosystem, with the official maintainers leaning on the community to develop the 'batteries' and several good but incomplete and unofficial solutions being offered (lein-cljsbuild, figwheel, boot, etc). I'm not actively involved with CLJS development anymore but last I checked that still conti…

All of the most popular Clojure DE's, namely VSCode/Calva, Idea/Cursive and Emacs/CIDER has great support for clojurescript for now.

Can you set a breakpoint in CLJS code within your editor? Can you instrument a CLJS function, call it and do step-by-step debugging like in CIDER or Cursive for clojure?

Re: ClojureScript 1.10.844

#74

Post by pizzeriafrida » Wed, Apr 07, 2021, 10:18 PM UTC

lukashrb wrote: post #45

pizzeriafrida wrote: post #10

Earlier quoted context omitted.

The question is funny because on the the list of advantages that Clojurescript offers the syntax / language is quite low on the list imo. Clojurescript has the best client-side build tool I have used in https://shadow-cljs.github.io/docs/UsersGuide.html and everyone uses it. Clojurescript targets/outputs Google Closure compatible code which is easily the most sophisticated JS compiler out there. The reason no one use…

Reading this and other replies I wonder why no one mentions core.async?

core.async is great, but admittedly I haven't needed to reach for it on the client (when building SPAs). I'm not sure if it's because re-frame is the focus for event driven workflows or what, but...