> gulp-vinyl-browserify-babelify nonsense Use Webpack. It replaces the need for all of these and does a much better job.
Doesn't that just glue them all together? We're using it at work, and we brought in an in-house React person, but I have no idea what the config does/signifies, and every time they change something, I absolutely don't understand why or how it works. (Our tests currently don't work. I mean, they can run - unless there's an error, in which case it exits early with a 0 status, without running any of the subsequent tests…
Late update: read through some of the webpack source code. As near as I can tell, it completely ignores most of the options passed to it via the CLI. (For example, --colors seems to have zero effect on anything.)
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) { ... } }
I couldn't find example in the docs for that library showing concurrent async ops with simple try/catch type error handling. So it's still not clear to me how you would rewrite the above shown async/await concurrent scenario using this library.
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…
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, destructuring, imports/exports. Classes and spreads are useful too if you do a lot of React and JSX. But async/await, decorators and generators are just fancy and questionable ways to perform routine functional stuff one can easily do in shaggy pre-ES5 Javascript.
I write a lot of ES6/ES7/JSX at work and CLJS at home and 100% prefer the latter.
I want immutable values with destructuring, lazy sequences, suit of threading macros, decent cond|p/case, protocols and whole CLJS ecosystem.
I've adapted to ES6/ES7/Redux/RxJS and often even could write code near-identical to CLJS/Reagent/Re-frame/Reagi stack. But it is definitely more painful and limiting experience.
I couldn't find example in the docs for that library showing concurrent async ops with simple try/catch type error handling. So it's still not clear to me how you would rewrite the above shown async/await concurrent scenario using this library.
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 ;)
Many of the newer Javascript libraries seem massively over-engineered compared to what you actually gain over using jQuery, or even just plain Javascript. I don't want to detract from the complexity of what some of these frameworks can achieve but at the same time it's not like they are doing complex 3D or machine learning. For me it's about readability and maintainability. I can come back to a program weeks, months…
It seems like no one asks "Just because we can use Javascript for everything, should we?" Pros: AJAX for loading content makes requests smaller making your app more performant. Cons: The Javascript framework requires a 1xx KB download before content can be rendered, making your app less performant, hurting SEO, and breaking the back button (no, I don't want to scroll again from the top through the 5 posts I already r…
"Google doesn't use AngularJS for Gmail" - IMHO This is non-reason for a start. Why will they suddenly start migrating their main product which was built a long time before Angular was developed. Meanwhile most of the new websites at Google are being developed using Angular - google trends, google fiber, DoubleClick etc.
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…
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 code. Thanks.
I couldn't find example in the docs for that library showing concurrent async ops with simple try/catch type error handling. So it's still not clear to me how you would rewrite the above shown async/await concurrent scenario using this library.
So what you're saying is that you can't be arsed to spend 15 minutes to learn a library, but you're ok gobbling up all of ES6/7 without problems?
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…
Perhaps you could instead provide an example of a concrete problem that you believe to be difficult to tackle with CLJS.
I couldn't find example in the docs for that library showing concurrent async ops with simple try/catch type error handling. So it's still not clear to me how you would rewrite the above shown async/await concurrent scenario using this library.
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% probably.
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…
@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?