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

61–70 of 74 posts

Re: ClojureScript 1.10.844

#61

Post by slifin »

ledauphin wrote: post #37
brundolf wrote: post #33

Earlier quoted context omitted.

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…

this rings pretty true to me. I have a whole host of reasons for wishing I could switch our group into the Clojure ecosystem, but a huge thing holding me back is not feeling confident that I understand how spec 2 would help us efficiently solve the documentation and pre-runtime correctness verification problems that static typing (Flow and typescript and mypy) give us.

Spec isn't directly for static analysis

Spec is for specification which can be used for more things than precompile problem checking

Clj-kondo is for precompile static analysis that also supports minimal typing

Re: ClojureScript 1.10.844

#62

Post by raspasov »

fiddlerwoaroof wrote: post #48
raspasov wrote: post #46

Earlier quoted context omitted.

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.

The autocomplete results can come from the global app state. There’s no rules written in stone about what should be in local state. My default is “as little as possible”.

Re: ClojureScript 1.10.844

#63

Post by raspasov »

iLemming wrote: post #52
raspasov wrote: post #42

Earlier quoted context omitted.

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.

Sounds about right.

Re: ClojureScript 1.10.844

#64

Post by fiddlerwoaroof »

raspasov wrote: post #62
fiddlerwoaroof wrote: post #48

Earlier quoted context omitted.

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.

The autocomplete results can come from the global app state. There’s no rules written in stone about what should be in local state. My default is “as little as possible”.

My point is that I’ve found that there is very little local state that doesn’t eventually benefit from being merged into the global state management store.

Re: ClojureScript 1.10.844

#65

Post by peferron »

iLemming wrote: post #53
ggregoire wrote: post #50

Earlier quoted context omitted.

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

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.

Re: ClojureScript 1.10.844

#66

Post by iLemming »

peferron wrote: post #65
iLemming wrote: post #53

Earlier quoted context omitted.

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

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

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.

Re: ClojureScript 1.10.844

#67

Post by napsterbr »

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

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.

Re: ClojureScript 1.10.844

#68

Post by iLemming »

knubie wrote: post #58
frankiesardo wrote: post #19

Earlier quoted context omitted.

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.

AFAIK, albeit it was initially based on the ideas implemented in Om.Next, modern versions of Fulcro are very different today.

I think Om.Next was just a collection of a few, rather conceptual, abstract objectives, quite experimental (perhaps even ahead of their time) and untested in production.

Too bad that Cognitect couldn't give David Nolen a carte-blanche and let him work on it 100% of his work time.

I'd rather live in a world where libraries like Om.Next become popular, and not stuff like Angular.

ps.: I used Angular. And I loved it. Angular made sense. Sometime around 2009-2010. But it stopped making sense. And I stopped liking it. You still can build awesome things with it, and people still do. And I still don't like it.

Re: ClojureScript 1.10.844

#69

Post by robertlagrant »

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…

I remember the original Om already being really exciting.

Re: ClojureScript 1.10.844

#70

Post by raspasov »

fiddlerwoaroof wrote: post #64
raspasov wrote: post #62

Earlier quoted context omitted.

The autocomplete results can come from the global app state. There’s no rules written in stone about what should be in local state. My default is “as little as possible”.

My point is that I’ve found that there is very little local state that doesn’t eventually benefit from being merged into the global state management store.

Fair enough.
Post reply on HN