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

React/JavaScript fatigue

medium.com

Post reply on HN
Print view View original

161–170 of 187 posts

Re: React/JavaScript fatigue

#161

Post by yogthos »

ilostmykeys wrote: post #149
yogthos wrote: post #147

Earlier quoted context omitted.

This is a really strange line of argument. While core.async is popular, nothing precludes you from using other libraries such as promesa https://funcool.github.io/promesa/latest/ that have semantics you seem to prefer. Second, ClojureScript has great interop with Js, so there's absolutely nothing stopping you from using a Js library/feature if you so choose. >And now that we have decorators, typed data structures, it…

promise-a by itsef does not solve callback hell it simply turns it into a never-ending-chain-of-thens but async/await (built on top of promise) does make things easily comprehensible. How do i use async/await in CLJS? More importantly why shouldn't i use something like ESLisp if I am into lisp but want to work with JS features directly? Why would I want to mix JS with CLJS amd require everyone who maintains my code t…

>promise-a by itsef does not solve callback hell it simply turns it into a never-ending-chain-of-thens but async/await (built on top of promise) does make things easily comprehensible. How do i use async/await in CLJS?

There's a long discussion here, which I'm pretty sure you're already aware of, on the tradeoffs:

https://groups.google.com/forum/#!topic/clojurescript/LBy0yi...

Each approach has its downsides, but clearly core.async and promises work just fine here.

>More importantly why shouldn't i use something like ESLisp if I am into lisp but want to work with JS features directly? Why would I want to mix JS with CLJS amd require everyone who maintains my code to know both?

Language semantics is why. ClojureScript has much cleaner semantics than Js and languages that provide syntax sugar on top of it. It's immutable by default, has clean and consistent syntax, and far less gotchas than Js.

Nobody actually mixes Js with ClojureScript. People write libraries backed by Js internally, but the users of these libraries don't have to know or care about that.

The real question is why would somebody want to learn the giant clusterfuck that ES6/7 constitutes when far saner alternatives are available.

> i gave up on CLJS after it was evident to me that JS is maturing and has copied a lot of the stuff I like from CLJS plus some stuff from C# like async/await.

Adding features to an already poorly designed language does not make it better. You end up with a giant kitchen sink language that takes inordinate brainpower to work with. We've already seen that this is a bad idea with languages like C++ and Scala. And no, you can't just learn a snae subset of the language, because sooner or later you have to deal with code written by other people.

If working with a giant quirky mess that looks like this https://i.imgur.com/AjSTP20.png is you cup of tea then who am I to stop you, but I certainly question that it's a rational choice. :)

Re: React/JavaScript fatigue

#162

Post by yogthos »

ilostmykeys wrote: post #159
mad-mad-beaver wrote: post #154

Earlier quoted context omitted.

Just use promesa/all then catch :) Moreover, it has funcool/cats bindings, so you can use promises in mlet and alet macros if you are into monad thing ;)

Oh right, that makes sense but does not make async code organize the way synchronous code does (as async/await sugar enables) but is a fair deal if you don't mind your async code using a different organizing pattern or if you specifically want it to be that way... :) Re: cats Not a big fan of abstractions that don't contribute to code simplicity. What is the percentage of programmer who dig monads? Less than 1% proba…

You're just cherry picking though. When it comes to complexity there's plenty more of it in Js than there's ever likely to be in ClojureScript.

Re: React/JavaScript fatigue

#163

Post by yogthos »

ilostmykeys wrote: post #160
ilostmykeys wrote: post #156

Earlier quoted context omitted.

Async/await doesnt lead to a long chain of thens with a trailing catch. It gives you proper synchronous semantics like any other synchronous code, while allowing you to specify concurrent logic. Its syntax is very understanable. You're missing out! I think you don't actually have a clear idea if you think async/await is a step backwards. You're arguing for the sake of arguin, right? Else, give me some examples in cod…

@yogthos Nothing is hard to do in CLJS but finding the right way to do things can be hard. For example, why doesn't core.async include promises and even better some async/await equivalent? Why does core.async push CSP as the built in async model to the exclusion of all other async patterns? Why are those only found in some 3rd party libraries?

>Nothing is hard to do in CLJS but finding the right way to do things can be hard.

So you're saying that you have to learn the language and its ecosystem. Please explain how that's different from any other language.

>For example, why doesn't core.async include promises and even better some async/await equivalent?

Because it has different design goals.

>Why are those only found in some 3rd party libraries?

Because most people find the core.async approach to work well. However, since such libraries exist and have great documentation, I fail to see the problem.

In fact, not baking things into the language itself is one of the greatest benefits of Clojure. The language itself is minimal and makes very few assumptions. This means that it can be extended through libraries to many kinds of domains. The more assumptions the core language makes the more rigid it becomes.

Re: React/JavaScript fatigue

#164

Post by yogthos »

Tankenstein wrote: post #142
hellofunk wrote: post #120

Earlier quoted context omitted.

>Clojurescript is, let's be honest, never going to be natively supported in Google Chrome. Not quite sure what you mean by this, but source maps, syntax highlighting and other native extensions were added by the Chromium team over the last year specifically for Clojurescript support. But, as far as a language running natively in Chrome, none of the languages that transpile to JS do, not Elm, Purescript, etc, so I'm n…

He is referring to the fact that his language of choice, es6, will be running natively in chrome, since it's just new javascript.

However, since ClojureScript transpiles to Js I don't really have to care about this do I. From my perspective Js is effectively bytecode.

Re: React/JavaScript fatigue

#165

Post by yogthos »

AlwaysBCoding wrote: post #76
modarts wrote: post #49

Honestly, at this point, since the JS community seems to have fallen back on just lifting all of the good ideas from the Clojurescript community, why not just go straight to the source and start learning some Clojure? - You don't need to bring your own persistent data structure lib (ImmutableJS/mori/etc,) - Don't need to bring a functional utility lib (lodash/ramda/etc) - The build ecosystem revolves around a really…

Also you don't really need to use a flux library or Redux if you're using Reagent, it's pretty much all set up for you. I've been using ClojureScript/Reagent for about a year now and all this JS tooling talk goes way over my head, I haven't needed to use any tooling other than lein cljsbuild for a while now, and it's glorious. If the Clojure community / ClojureScript was more approachable to beginners I think Clojure…

Honestly, I think it's more approachable than Js tooling for somebody who's not familiar with either. You can have a working ClojureScript project up and running in literally 1 step, and only have to install 2 things to do that:

Install OpenJDK: http://www.azul.com/downloads/zulu/

Install Leiningen: http://leiningen.org/

Create a new project and run it:

lein new reagent myapp cd myapp

lein figwheel

Once figwheel starts, you can edit src/cljs/myapp/core.cljs and any changes you make will be reflected live in the browser without having to reload the page. Now consider what you'd need to setup to get the same thing with Js/React.

I think the problem is that a lot of people are already familiar with Js and tooling around it, so integrating more tools piecemeal doesn't feel as hard as diving into a whole new ecosystem.

Re: React/JavaScript fatigue

#166

Post by yogthos »

cageface wrote: post #84
modarts wrote: post #49

Honestly, at this point, since the JS community seems to have fallen back on just lifting all of the good ideas from the Clojurescript community, why not just go straight to the source and start learning some Clojure? - You don't need to bring your own persistent data structure lib (ImmutableJS/mori/etc,) - Don't need to bring a functional utility lib (lodash/ramda/etc) - The build ecosystem revolves around a really…

Lisp is just a non-starter for a lot of people. Maybe it's an irrational bias but it's also widely prevalent. I think Lisp in all its flavors is in the same bucket with Haskell, i.e. not a language that will ever go mainstream but an important laboratory for exploring ideas that eventually trickle down into more mainstream languages. Clojurescript is a case in point. Statistically its userbase is zero but it's been t…

The relative numbers of users to other languages are not really interesting. The question is whether there are enough people using ClojureScript for it to be viable long term and can you get a job using it.

The answer to both questions is a yes. There are thousands of people working with ClojureScript today and there are lots of companies hiring for Clojure/Script jobs at this very moment.

In fact, the demand appears to outpace supply resulting in benefits such as accommodation for remote work (https://www.reddit.com/r/Clojure/comments/3yhm7k/looking_for...).

Thanks to the irrational bias against Lisp you're also competing against a smaller pool of developers when you look for Clojure jobs. Seems like a win to me.

Re: React/JavaScript fatigue

#167

Post by cageface »

yogthos wrote: post #166
cageface wrote: post #84

Earlier quoted context omitted.

Lisp is just a non-starter for a lot of people. Maybe it's an irrational bias but it's also widely prevalent. I think Lisp in all its flavors is in the same bucket with Haskell, i.e. not a language that will ever go mainstream but an important laboratory for exploring ideas that eventually trickle down into more mainstream languages. Clojurescript is a case in point. Statistically its userbase is zero but it's been t…

The relative numbers of users to other languages are not really interesting. The question is whether there are enough people using ClojureScript for it to be viable long term and can you get a job using it. The answer to both questions is a yes. There are thousands of people working with ClojureScript today and there are lots of companies hiring for Clojure/Script jobs at this very moment. In fact, the demand appears…

I've been hearing this argument since I was heavily into Common Lisp in the early 2000s. Personally I like lisps so I hope Clojurescript does establish a viable niche.

But it's not the case that number of users is irrelevant. If I commit to Clojurescript (or Haskell, or any other niche language), I'm cutting my prospective job market down by 95%+. This means fewer companies I can work with, fewer places I can live, and fewer gigs available overall. Some might consider the tradeoff worth it but I don't.

Re: React/JavaScript fatigue

#168

Post by Skinney »

ilostmykeys wrote: post #139
Skinney wrote: post #134

Earlier quoted context omitted.

Install an exception handler on the channel or return exceptions on the channel. The latter is more common. I've written my own macros to make the latter case pleasant ( (defmacro go-catching [& body] `(go (try ~@body (catch js/Error e# e#)))) (defmacro Used like this: (go-catching (<? (async-fn)))

Can you expand that to the concurrent scenario? Show us how you implement this simple and very common concurrent pattern with ClojureScript. I've seen stuff that implement this in ClojureScript and it ain't pretty (to say the least) Impress me! :) In ES7: async function fAsync() { try { var results = await Promise.all([asyncOpA, asyncOpB, asyncOpC]) } catch (e) { ... } }

From reading core.asyncs documentation, it sounds like this should do the trick:

(go (try (let [ops [asyncOpA asyncOpB asyncOpC]] (core.async/take (count ops) (apply core.async/merge ops))) (catch js/Error e ...)))

Where asyncOp* uses go-catching.

Re: React/JavaScript fatigue

#169

Post by Skinney »

ilostmykeys wrote: post #159
mad-mad-beaver wrote: post #154

Earlier quoted context omitted.

Just use promesa/all then catch :) Moreover, it has funcool/cats bindings, so you can use promises in mlet and alet macros if you are into monad thing ;)

Oh right, that makes sense but does not make async code organize the way synchronous code does (as async/await sugar enables) but is a fair deal if you don't mind your async code using a different organizing pattern or if you specifically want it to be that way... :) Re: cats Not a big fan of abstractions that don't contribute to code simplicity. What is the percentage of programmer who dig monads? Less than 1% proba…

It's a trivial matter to wrap promise/all in a core.async channel, providing the exact orginzation pattern you're looking for.

Re: React/JavaScript fatigue

#170

Post by yogthos »

cageface wrote: post #167
yogthos wrote: post #166

Earlier quoted context omitted.

The relative numbers of users to other languages are not really interesting. The question is whether there are enough people using ClojureScript for it to be viable long term and can you get a job using it. The answer to both questions is a yes. There are thousands of people working with ClojureScript today and there are lots of companies hiring for Clojure/Script jobs at this very moment. In fact, the demand appears…

I've been hearing this argument since I was heavily into Common Lisp in the early 2000s. Personally I like lisps so I hope Clojurescript does establish a viable niche. But it's not the case that number of users is irrelevant. If I commit to Clojurescript (or Haskell, or any other niche language), I'm cutting my prospective job market down by 95%+. This means fewer companies I can work with, fewer places I can live, a…

I didn't say that the number of users is irrelevant. There needs to be a minimum user base to make a language viable, however beyond that it's just tradeoffs.

While you might be cutting down the job market, you're also focusing on companies that are forward thinking, get to work with great technology, and get perks such as remote work. The most exciting part for me is that you get to shape the future of the ecosystem. Being on the ground floor of a new technology means that you get a lot of say in how it will evolve. For me the tradeoff was absolutely worth it, but I can understand how it's not for everyone.

Post reply on HN