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…
ClojureScript 1.10.844
31–40 of 74 posts
Re: ClojureScript 1.10.844
#32A 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…
Re: ClojureScript 1.10.844
#33Since 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…
Personally I find it harder and harder these days to justify writing code that doesn't have static types. Even for personal projects, if I'm writing more than 100 lines, I want editor checks and standardized documentation. Particularly when I'm not doing anything wildly novel, and particularly (but not exclusively) for larger projects.
It's not hard for me to imagine industry reaching a similar conclusion, especially when the novelty of most of the web apps being cranked out tends to be lower, and the scale tends to be larger.
And where industry goes, hobbyists tend to go so that they get to put relevant stuff on their resume (not to mention paid employees who release in-house tooling and libraries as open source).
Re: ClojureScript 1.10.844
#34Earlier 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…
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.
Re: ClojureScript 1.10.844
#35Earlier quoted context omitted.
Also: cross pollination is still happening as libraries like Recoil implement some of the ideas sitting in Reframe for vanilla React. On the ClojureScript side, I would like to see more projects integrating with platforms like Nextjs and Gatsby.
There is nothing that says ClojureScript can’t be used on the server side and integrate with the platforms you mentioned. It’s likely just a matter of writing wrapper libraries similar to what was done for many Java libraries. The hard part is that most Clojure devs default to using the JVM server side so there’s not much appetite there to do the work to embrace JS server side frameworks.
But you're right, for most "serious" projects, people tend to reach for the JVM. Yet, I think a strong ClojureScript presence on the JAMstack would benefit beginners a lot.
Re: ClojureScript 1.10.844
#36Earlier 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…
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
Re: ClojureScript 1.10.844
#37Since 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…
I don't have any specific knowledge of the community dynamics you're talking about, but I have opinions about these technologies, and can speculate: Personally I find it harder and harder these days to justify writing code that doesn't have static types. Even for personal projects, if I'm writing more than 100 lines, I want editor checks and standardized documentation. Particularly when I'm not doing anything wildly…
Re: ClojureScript 1.10.844
#38For those with experience, would you say that ClojureScript for frontend stands on its own without a Clojure backend?
Re: ClojureScript 1.10.844
#39What 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 team even has great advice for you:
"goog.isArray has been deleted. Use Array.isArray instead."
Well, how about you just delegate to that, Google team, and I can just upgrade?
This kind of library maintenance is what keeps me away from JS/TS where prior investments seem to be less valuable:
React deprecating lifecycle methods, Typescript's breaking changes page is pretty long (but admittedly, being MSFT, they try to care about backward compatibility), Vue.js 3: functional components deprecated, manual changes required.
Who can afford these shenanigans?
Changes in re-frame, reagent etc. have been a lot more careful. Not quite perfect (looking at you Reagent 1.0!), but I'm sleeping much better working with a stable, slow-moving framework - at the cost of maybe a few more repaints.
Re: ClojureScript 1.10.844
#40For those with experience, would you say that ClojureScript for frontend stands on its own without a Clojure backend?