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

41–50 of 74 posts

Re: ClojureScript 1.10.844

#41

Post by fiddlerwoaroof »

napsterbr wrote: post #28
divs1210 wrote: post #7

Earlier quoted context omitted.

For me, the primary advantage has been the ecosystem. Reagent and re-frame have been awesome since Day 1, even as react has tried to play catch-up with hooks etc.

Very interesting take from re-frame's author regarding React Hooks (and why it ultimately doesn't matter that hook-based components are not very popular on CLJS): https://github.com/day8/re-frame/issues/590#issuecomment-624...

I’ve been writing a lot of react over the past several years (JS/TS), and I strongly agree with this take: hooks, especially hooks like useState really are an attractive nuisance that, by making it easy to have local state in components, end up spreading business logic all over the view layer and coupling all the wrong things together.

Re: ClojureScript 1.10.844

#42

Post by raspasov »

Scarbutt wrote: post #23
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 (?)

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.

Re: ClojureScript 1.10.844

#43

Post by raspasov »

pandeiro wrote: post #36
frankiesardo wrote: post #22

Earlier quoted context omitted.

I shared a similar opinion a while ago, but lately (last two years perhaps?) the general consensus is pretty much shadow-cljs which has stellar support for node modules. shadow-expo also integrates with RN effortlessly. Cursive is really good at handling cljs too, with jump-to-definition and refactoring without using a REPL

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.

Re: ClojureScript 1.10.844

#44

Post by lukashrb »

Scarbutt wrote: post #23
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 (?)

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…

Could you give us more details about the problems you running in?

Re: ClojureScript 1.10.844

#45

Post by lukashrb »

pizzeriafrida wrote: post #10
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 (?)

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?

Re: ClojureScript 1.10.844

#46

Post by raspasov »

fiddlerwoaroof wrote: post #41
napsterbr wrote: post #28

Earlier quoted context omitted.

Very interesting take from re-frame's author regarding React Hooks (and why it ultimately doesn't matter that hook-based components are not very popular on CLJS): https://github.com/day8/re-frame/issues/590#issuecomment-624...

I’ve been writing a lot of react over the past several years (JS/TS), and I strongly agree with this take: hooks, especially hooks like useState really are an attractive nuisance that, by making it easy to have local state in components, end up spreading business logic all over the view layer and coupling all the wrong things together.

Agreed.

I would not use local state apart from fine-grained performance optimizations or temporary, always-can-be-thrown-away state specific to the component itself.

Example: email field input before passing validation.

Re: ClojureScript 1.10.844

#47

Post by halfmatthalfcat »

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.

Re: ClojureScript 1.10.844

#48

Post by fiddlerwoaroof »

raspasov wrote: post #46
fiddlerwoaroof wrote: post #41

Earlier quoted context omitted.

I’ve been writing a lot of react over the past several years (JS/TS), and I strongly agree with this take: hooks, especially hooks like useState really are an attractive nuisance that, by making it easy to have local state in components, end up spreading business logic all over the view layer and coupling all the wrong things together.

Agreed. I would not use local state apart from fine-grained performance optimizations or temporary, always-can-be-thrown-away state specific to the component itself. Example: email field input before passing validation.

I’ve had the experience, though, that “temporary” state often becomes a feature requirement. Like, you have a field to search your dataset by email address and, next iteration, the product manager wants autocomplete based on partial input.

Re: ClojureScript 1.10.844

#49

Post by adamkl »

pizzeriafrida wrote: post #11
ragnese wrote: post #6

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.

Re: ClojureScript 1.10.844

#50

Post by ggregoire »

napsterbr wrote: post #25
jetti wrote: post #16

Earlier quoted context omitted.

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

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

Post reply on HN