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

ClojureScript 1.10.844

clojurescript.org

Post reply on HN
Print view View original

51–60 of 74 posts

Re: ClojureScript 1.10.844

#51

Post by achikin »

pandeiro wrote: post #21
pizzeriafrida wrote: post #18

Since this thread/Clojurescript is getting some love I'd like to express something to a hopefully receptive audience: There was a point where Clojurescript and Javascript sort of walked hand-in-hand during the advent of when React started to make sense in the minds of the community[0]. It felt really exciting because of the cross pollination that was happening between the two languages, Redux felt very familiar, and…

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.

Re: ClojureScript 1.10.844

#52

Post by iLemming »

raspasov wrote: post #42
Scarbutt wrote: post #23

Earlier quoted context omitted.

The benefits of using Clojurescript over JS/TS in 2021 are superficial and not worth it IMO. Typescript is great, has good tooling and plays nice with the JS ecosystem. With Clojurescript you spent more time fighting integration with the JS ecosystem than getting any real work done. The mismatch between JS objects and Clojurescript data structures is annoying and tedious and riddle with performance issues, and Clojur…

I usually avoid a direct ad-hominem attack but here I think I have to. Most things this person says in every thread about Clojure are false.

That account belongs to a regular Clojure-hater, it's seems the person is biassed against it at the personal level.

Re: ClojureScript 1.10.844

#53

Post by iLemming »

ggregoire wrote: post #50
napsterbr wrote: post #25

Earlier quoted context omitted.

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

> 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.

Re: ClojureScript 1.10.844

#54

Post by achikin »

systems wrote: post #2

A bit of an obvious question Elm, Typescript and Purescript all offer Javascript + Types Clojurescript is dynamic, beside the lisp syntax which is arguably cleaner, and offer some nice advantages like homoiconicity What is the real advantage of Clojurescript (?)

It offers REPL, great hot reloading, a small set of immutable data structures, and a great set of carefully architectured core library functions to work with those data structures.

Also because of immutable data structures it has a very clean comparison semantics e.g. you can compare data structures by value with `=` which helps a lot in React-like environments.

The absence of static typing enables you to write more general code with less effort. All that leads to simple, clean and compact code. If you check Real World App statistics [1] you'll see that Clojurescript/Re-frame implementation has the fewest LOC (almost 4x less than Elm and 3x less than Purescript).

[1] https://www.freecodecamp.org/news/a-realworld-comparison-of-...

Re: ClojureScript 1.10.844

#55

Post by iLemming »

systems wrote: post #2

A bit of an obvious question Elm, Typescript and Purescript all offer Javascript + Types Clojurescript is dynamic, beside the lisp syntax which is arguably cleaner, and offer some nice advantages like homoiconicity What is the real advantage of Clojurescript (?)

> What is the real advantage of Clojurescript

IMO. Interactive development. It allows you to connect to a running program (local or remote) and tweak things on the fly. Without even affecting the state of the program. Without even having to save or re-compile. It's hard to explain the benefits of that approach. One has to experience it.

Another major benefit: true code re-use. You can write functions that would work both in Clojure and Clojurescript (even though we're talking about very different environments). With Javascript/Typescript (in practice) that is hard to achieve even when you have a nodejs backend.

Re: ClojureScript 1.10.844

#56

Post by achikin »

ragnese wrote: post #6

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

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.

Re: ClojureScript 1.10.844

#57

Post by iLemming »

rcarmo wrote: post #8

Any updates on Lumo? That was a great workflow.

If I remember it right, Lumo and Planck (mainly) were created to deal with the long startup times of Clojure. People needed a faster way to get the REPL up and also something that can run tiny scripts. With the emergence of Graal, and tools like babashka, it looks like the JVM warmup time is no longer that big of a problem.

Re: ClojureScript 1.10.844

#58

Post by knubie »

frankiesardo wrote: post #19
pizzeriafrida wrote: post #18

Since this thread/Clojurescript is getting some love I'd like to express something to a hopefully receptive audience: There was a point where Clojurescript and Javascript sort of walked hand-in-hand during the advent of when React started to make sense in the minds of the community[0]. It felt really exciting because of the cross pollination that was happening between the two languages, Redux felt very familiar, and…

Fulcro is getting a lot of love lately and a passionate community of users around it. So no, it's not forgotten, just migrated https://book.fulcrologic.com

Just to add some context for the OP, Fulcro is kind of an evolution on om.next.

Re: ClojureScript 1.10.844

#59

Post by darksaints »

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…

https://killedbygoogle.com/

Cljs never should have been built on top of closure.

Re: ClojureScript 1.10.844

#60

Post by beders »

halfmatthalfcat wrote: post #47
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…

Maintaining backwards compatibility is not trivial as your comment seems to allude to. There's obviously a reason things are deprecated and removed from code bases. There's also a reason SemVer exists, to notify you to the fact of breaking changes (whether the library maintainers actually abide by the correct usage is another conversation). Don't want breaking changes? Dont upgrade your stuff, sounds easy to me.

Yeah, never upgrade, fork and get the security updates somehow in that new fork. Not very convenient.

Semver is not an excuse to break your clients.

The reason given was "code size and keeping the API surface small". Both are bogus, especially since this is part of an optimizing compiler who will REMOVE unused code. Leaving simple forward from goog.isArray to Array.isArray in there does not cost any maintenance, does not mean extra tests (you already have those) and does not mean your API surface is overblown.

Post reply on HN