Yeah I had an argument on here about callbacks vs. Promises. I’m pretty convinced the ones making the pro callbacks arguments have never actually used JavaScript in a professional capacity, especially in large codebases. I thought the callbacks vs Promises using `async/await` debate was settled.

I’ve never heard anyone argue for callbacks. But the async/await problem isn’t entirely dead since folks still argue generators should be doing they job. They’re similar flavors of cooperative multitasking I guess. But callbacks.. they’re really hard to test without abusing entirely different parts of js. Not that promises are much better.

Yes, but async await isn't really complete without good support for streaming ops and APIs that support them first class. That includes merging streams, canceling them, etc (kinda like Rx). It probably needs both push and pull streams as well. We're not there yet, so in the meantime we have to use events and event listeners, in addition to async/await. I think that's perfectly fine.

Have you tried Ix as a complement to Rx?

https://github.com/ReactiveX/IxJS

No I have not, I prefer to go lightweight so good old event listeners are perfectly fine for my purposes. But once you have ubiquitous first class support for async iterables and so on I'm all aboard. I see Rx very much like an experiment that should influence language features and std libs, rather than a standalone framework.

I couldn't agree more and I've been in this same situation. When your codebase is hundreds of thousands of lines of JavaScript suddenly promises with async await make a lot of sense.

Await is nice, but even with promises, I'd settle with people using them correcly: return something in the promise to the next one can use it without nesting.

But people use promises... and keep nesting.

Even back in early Node days we figured this out with ideas/libs like async.waterfall, which let you turn nesting into a serial flow:

    async.waterfall([function(callback) { callback(null, 'one', 'two'); },
                     function(arg1, arg2, callback) { callback(null, 'three'); },
                     function(arg1, callback) { callback(null, 'done'); }]);

Thus you don't need to make things like 'one' and 'two' into scoped variables that require nesting the second function into the first one so it can see them, and you can split those functions out of being inline lambdas.

Or early Promise libs like coolaj86's futures which included a sequence, letting you do the same sort of thing:

    var seq  = Futures.sequence();
    
    seq
    .then(function(next) { setupContextObj(next, obj)})
    .then(retrieveMD)
    ...
    .then(postUrlDataToS3)
    ...

while also being able to make nice little future() objects you could return from functions and pass around. To be fair it's still JS and lots of third party code needed regular old callbacks so it was still easy to get excessive levels of nesting of various things that leave you with function-closing sequences like });}});return future;} or });}}).end(buf);} that could make a Lisper blush.

These days it's quite a bit nicer having native Promises, a better community-wide understanding of how to use them, but also the syntactic sugar of async/await improves over the waterfall/sequence/.then&.catch chaining styles (especially when it comes to modifications where you want to use data from previous stages of the chain in later stages).

The ResultAsync class in neverthrow has chaining as well as splitting on ok/error - I find this really nice because you can also do away with exceptions at the same time.

I feel like fp-ts is even more powerful for this - provided you (and your entire team / every new hire) can navigate the steep learning curve which tbh defeated me when I tried to learn it in a couple of days last week

I'd argue (from memory!) that there are solid edge cases for nesting promises .. probably all scope-related, where multiple async operations are required for a result that would otherwise require scope-leak / pollution.

> stuck in the late 2000s

jQuery is still the dominant paradigm. It's used on like 80% of websites. Wordpress is also still very widely used

Isn’t jQuery mostly dominant in stats because it’s included in WordPress by default (definitely in 90% of Wordpress themes). It’s been a while since I checked so this could be out of date.

Until very recently it was also a dependency of Bootstrap. That’s why it’s in my project (can’t upgrade yet).

When using classic Angular (some time ago) with Bootstrap I ended up rewriting the JS parts of any bit of Bootstrap we used as Angular components for ease of debugging (I know lots of people hated Angular but it was still easier to only debug one framework-ish thing at once).

The existence today of e.g. react-bootstrap suggests that I'm not the only one to have had this idea.

>I know lots of people hated Angular

Why would they hate on angular? Isn't just another framework

Yes, it's in core. And was only upgraded from a very outdated version fairly recently ( in terms of its lifetime) - https://make.wordpress.org/core/2020/06/29/updating-jquery-v...

I bet bootstrap has something to do with it too.

Many of the bigger libraries like bootstrap but also individual, rich plugins and widgets have moved to a JS native implementation, which is slightly more verbose but clearer, well supported and has no bundle size / dependency overhead.

If I want/need "something more than native" today then I first ask myself again whether I _really_ need it and then maybe I will look for focused/small libraries and polyfills.

Right, but not for new projects.