Live data from Hacker News

React/JavaScript fatigue

medium.com

171–180 of 187 posts

Re: React/JavaScript fatigue

#171
post #94

Earlier quoted context omitted.

Nitpick - Grunt is a task runner, Gulp and Brunch are build tools, Webpack is just a module bundler, it's not a full build tool - it's more a replacement for r.js than for Gulp (and it's remarkably faster than r.js). After trying out Grunt and Gulp, I found Gulp to be more to my liking because the tasks are written as actual JS code, not as a pile of configuration. Plus, it runs the tasks in parallel if they don't de…

Sure but they all end up being used as a build tool. Webpack may be a module bundler, but it has hot reloading, live reloading, and plugins to transpile. Watch any React tutorial and the first thing they have you do is set up a Webpack config that gives you a live-reloading build system with ES2015. And it's a different one than the one I used 5 months ago. It's nice that there are people willing to address problems,…

> Watch any React tutorial and the first thing they have you do is set up a Webpack config that gives you a live-reloading build system with ES2015.

To be honest, I prefer learning by reading specs/documentation, tinkering and Google-ing specific bits, not by watching tutorials, so I did not know this. That's not ideal conceptually, but it does mean one less tool in the pipeline, which is not a bad thing for beginners.

> it would be nice for web development to grow out of its "oooh shiny" phase.

Absolutely. Just as long as it doesn't swing to the other extreme, like PHP does, where 12-year-old and deprecated techniques are still entrenched at the top of Google... :)

Re: React/JavaScript fatigue

#172

Earlier quoted context omitted.

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

The thing is many people try ClojureScript and end up leaving while many others do stay. I am in the former group and my reasons are exactly what i stated but you are right to point out that my reasons may not be everyone's reasons, which I never assumed. Hence the Rant tag. Fair enough, some people find use of CSP for simple scenario of concurrent wait-for-all async management a natural fit but i find it an overkill. Promises are fine but I find async/await syntax much more easy to understand.

I do hope CLJS stays a strong niche language but any hope of it taking over the world is unlikely, IMO.

Re: React/JavaScript fatigue

#173

Earlier quoted context omitted.

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

The thing is many people try ClojureScript and end up leaving while many others do stay. I am in the former group and my reasons are exactly what i stated but you are right to point out that my reasons may not be everyone's reasons, which I never assumed. Hence the Rant tag. Fair enough, some people find use of CSP for simple scenario of concurrent wait-for-all async management a natural fit but i find it an overkill…

I'm not saying that ClojureScript is for everybody. Obviously, different people like different things and that's why we have so many different languages available.

However, the reason that async/await is difficult to do in ClojureScript as the main reason for leaving it is a strange one. It's clearly still very easy to do, even if ES7 version might be slightly cleaner at the cost of being baked into the core language semantics.

When you compare all the things that are much uglier in JavaScript compared to ClojureScript, it's a bit of a silly argument to cherry pick async semantics in my opinion.

I wouldn't expect ClojureScript to take over the world either. It's obviously never going to displace JavaScript, but it's reasonable to expect that it will continue to grow in popularity and that anybody who wants to work with it will be able to do so professionally.

Re: React/JavaScript fatigue

#174

Earlier quoted context omitted.

How is "never-ending-chain-of-thens" fundamentally different from async/await? It's still the very same code but with different (and somewhat disconcerting) sugar. I've been using promises long before ES7, and it's actually harder for me to read async/await functions and reason about them because they look so much like ordinary functions but aren't. There are useful features in ES6/ES7, to be sure: fat arrows, destru…

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…

Oh, yeah, it replaces that cumbersome

.then(() => doSome(thing)) with bare doSome(thing)

and

.catch(err => doOtherThing(err)) with catch (err) {doOtherThing(err)}

A breakthrough indeed!

I just don't see how's that fundamentally different and why one should have synchronous-like semantics for async operations.

Moreover I do a lot of RxJS and like stuff and it's perfectly normal for me to have async computations steps wrapped in functions. Luckily no one tried to "improve" JS syntax specifically for RxJS.

So I totally get async/await syntax and semantics but it forces me to switch mental context for no good reason and thus is useless and disconcerting.

And it's ridiculous to see this minor "feature" as a reason to switch from CLJS to ES6/ES7

Re: React/JavaScript fatigue

#175

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…

Oh, yeah, it replaces that cumbersome .then(() => doSome(thing)) with bare doSome(thing) and .catch(err => doOtherThing(err)) with catch (err) {doOtherThing(err)} A breakthrough indeed! I just don't see how's that fundamentally different and why one should have synchronous-like semantics for async operations. Moreover I do a lot of RxJS and like stuff and it's perfectly normal for me to have async computations steps…

You seem oblivious to the advantage of organizing your async code in the same manner you organize your sync code. But the bigger reason I gave up on CLJS (besides core.async and its CSP model being a ridiculous over kill for simple async management yet being the primary choice the language gives you out of the box) was that ES6/7 are advancing at a much rapid pace than all of those Compile-to-JS languages and no one I know in the JS world would want to program a web app in a Lisp-like language (it's like using an RPN calculator rather than a normal one to do your taxes) for advantages that are disappearing fast relative to JS.

The Extensible Web Manifesto embraces the Babel inspired iterate-before-you-approve spec development model and that just makes JS evolution go so much faster.

So there is no hope for any niche language to unseat JS, and staying with a healthy and growing mainstream standard is far more appealing to me than writing web apps in Lisp-like language that once was a great choice (compared to ES5) but is no longer in that position.

I hope ClojureScript continues to be a niche strong language but I'm really hapoy with the progress being made with JS as a language and ecosystem. Fatigue (what the article is about) is self inflicted IMO.

Re: React/JavaScript fatigue

#176

Earlier quoted context omitted.

The thing is many people try ClojureScript and end up leaving while many others do stay. I am in the former group and my reasons are exactly what i stated but you are right to point out that my reasons may not be everyone's reasons, which I never assumed. Hence the Rant tag. Fair enough, some people find use of CSP for simple scenario of concurrent wait-for-all async management a natural fit but i find it an overkill…

I'm not saying that ClojureScript is for everybody. Obviously, different people like different things and that's why we have so many different languages available. However, the reason that async/await is difficult to do in ClojureScript as the main reason for leaving it is a strange one. It's clearly still very easy to do, even if ES7 version might be slightly cleaner at the cost of being baked into the core language…

I didn't leave because of core.async being exclusively CSP. That was a big annoyance (and couldnt find the promise library) I left because ES7 and next year ES8 and year after ES9 are bound to give us what we need from a modern language without resorting to coding in a Lisp-like labguage, ClojureScript is extremely expressive but something about the Lisp form makes me spend too much time thinking about the code rather than the problem domain (product features) It does produce tight code so it is a better medium for expressing algorithms but I found that it moves my focus from thinking about features to thinking about algorithms (a strange attractor?) and in the end very few people (Lisp users mostly) will be able to maintain the code... So what am I doing writing a web app in a Lisp like language unless i really enjoy thinking about algorithms more than UX... What matters to me is having a good modern language with large enough eco system and that I could use to build kick ass UX. Modern JS and React-Flux-Immutable suffice. When i want to do heavy data processing I would probably miss ClojureScript and Clojure but the UI is not where I would want to do heavy data processing... I really thought about it based on all these factors and decided to jump back to JS. That was my choice. I don't expect it to be everyone else' choice...

Re: React/JavaScript fatigue

#177

Earlier quoted context omitted.

I'm not saying that ClojureScript is for everybody. Obviously, different people like different things and that's why we have so many different languages available. However, the reason that async/await is difficult to do in ClojureScript as the main reason for leaving it is a strange one. It's clearly still very easy to do, even if ES7 version might be slightly cleaner at the cost of being baked into the core language…

I didn't leave because of core.async being exclusively CSP. That was a big annoyance (and couldnt find the promise library) I left because ES7 and next year ES8 and year after ES9 are bound to give us what we need from a modern language without resorting to coding in a Lisp-like labguage, ClojureScript is extremely expressive but something about the Lisp form makes me spend too much time thinking about the code rathe…

>I left because ES7 and next year ES8 and year after ES9 are bound to give us what we need from a modern language without resorting to coding in a Lisp-like labguage

I'm not sure what that's supposed to mean exactly. I don't really understand what the "resorting" part refers to here. Clojure is a modern language with that has excellent syntax with tangible advantages over syntax found in most languages.

The syntax is very uniform and follows the principle of least astonishment well. The s-exps provide additional visual information about relationships in code making it more scannable. Finally, the syntax facilitates structural editing making it much easier to manipulate in the editor.

>ClojureScript is extremely expressive but something about the Lisp form makes me spend too much time thinking about the code rather than the problem domain

Perhaps that might have something to do with the fact that you've only used Lisp for 6 months, while you probably have years of experience working with Algol style syntax you're familiar with.

There's absolutely nothing inherent in Lisp syntax that distracts from the business logic. If anything, my experience is that it puts you closer to the business logic as there's a lot less syntactic noise.

>and in the end very few people (Lisp users mostly) will be able to maintain the code

That's completely false. My team has been using Clojure for the past 5 years and we've never had trouble hiring people to work with it. None of the people we've hired over the years had any experience with Clojure or even FP for the most part. The average learning curve to becoming productive tends to be a couple of weeks. We also hire co-op students every 4 months and all of them have learned the language quickly and enjoyed working with it.

A new hire doesn't have to become an expert to start doing useful things. Learning the basics takes very little time, and they can pick up new concepts as they need to. Personally, I wouldn't hire somebody who was unwilling to work with a new language as it implies the sort of rigidity that antithetical to the developer mindset.

> So what am I doing writing a web app in a Lisp like language unless i really enjoy thinking about algorithms more than UX

That's funny since ClojureScript provided the first environment for developing web apps where you could get instant feedback on the UI making it much easier to focus on UX.

Having a live environment with a REPL makes it much easier to experiment as it cuts down the time between making a change and seeing the effect. This is one of the greatest tools for being able to experiment with the UI and provide the a good UX.

>What matters to me is having a good modern language with large enough eco system and that I could use to build kick ass UX

This is precisely why I, and many others, use ClojureScript. If Js is your idea of a modern language I simply don't know what else to say here to be honest.

Again, if you prefer working with Js that's perfectly fine. However, your rationalization of that decision is flimsy at best, and really boils down to the fact that you'd rather use something you're more familiar with.

Re: React/JavaScript fatigue

#178

Earlier quoted context omitted.

I didn't leave because of core.async being exclusively CSP. That was a big annoyance (and couldnt find the promise library) I left because ES7 and next year ES8 and year after ES9 are bound to give us what we need from a modern language without resorting to coding in a Lisp-like labguage, ClojureScript is extremely expressive but something about the Lisp form makes me spend too much time thinking about the code rathe…

>I left because ES7 and next year ES8 and year after ES9 are bound to give us what we need from a modern language without resorting to coding in a Lisp-like labguage I'm not sure what that's supposed to mean exactly. I don't really understand what the "resorting" part refers to here. Clojure is a modern language with that has excellent syntax with tangible advantages over syntax found in most languages. The syntax is…

You are vested in Clojure/Script and biased toward it. Obviously you are biased due to the heavy investment you hve made. I see so many disadvantages in ClojureScript: Lisp is super small in terms of adoption. Lisp is like using an RPN calculator, for uber nerds not for everyone. Who will maintain my code? The few people I know who know ClojureScript? How hard is it to find a ClojureScript dev or anyone interested in working on it? Can my company hire hundreds of engineers who love it and are easy to replace if they leave. If you say yes then you are contradicting actual experience i have had and dismissing it due to shear bias, not based on objective facts and data-supported evidence. Clojurescript's biggest problem, however, is that it has people like yourself who want to shove Lisp Is The Truth down everyone else' throat which people like myself have no tolerance for :)

Re: React/JavaScript fatigue

#179

Earlier quoted context omitted.

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.

Show me the code! Go ahead and let's see how pretty that is, and son't forgeg error handling and concurrency.

Re: React/JavaScript fatigue

#180

Earlier quoted context omitted.

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.

I am biased. Just as you are.
Post reply on HN