The nodejs code I have to work with looks like: doshit() .then(doothershit()) .then(somethingelse()) .then(killyoursel())
and inside of each of these functions there is another structure exactly like it. Keep in mind it's a big codebase with probably 10k LOC, never actually counted though.
I don't know what's the point of using nodejs if this is how you're gonna program, working around the asynchrony all the time.
>.then >.then >.then listen to this user, use async/await. don't get caught up in callback and .then hell. promises are your friends but use them smartly.
Colton Cooper
And what's actually wrong with this? It's basic monadic control flow and it's certainly better than try-catches everywhere.
David Kelly
I didn't write it bro, I believe it was written before async/await existed in node yeah we have to refactor everything
oh there are catches everywhere
Noah Sanchez
damn, that's rough. i've never refactored shitty code before, but i imagine it's a nightmare.
2 reasons: disposability and order of operations with multi threads
Try managing a multithreaded app where operations must happen in a certain order, then allow those operations to be cancellable in one line. You'd need an assload of boilerplate if you didn't have a fancy framework managing it
It's why I recommend Rx
Jack Gomez
But are there try-catches?
Here's how refusing to use .then and .catch can make your code much more verbose. In general, async / await works badly with concurrent execution (Promise.all and others) do1() .then(val1 => Promise.all([ do2(val1) .catch(() => null), do3(val1) ])) .catch(console.error)
You never heard of Rx? lol... Get a load of this guy Are you a student in CS by chance?
Jace Cruz
I still haven't to this day found a situation in regular UI code where streams would be worth the trouble. Futures aka promises suffice for practically anything, and if there's the odd case where you need to filter or concatenate them in a stream-like way, you can do that with helper state ad hoc. Not worth integrating stuff with streams.
I dont do webshit, in systems programing we dont create 10 new problems to "solve" one problem.
Jason Rodriguez
It doesn't sound like you do anything complicated at all if you've never even heard of Rx. And no, it's not webshit.
Dominic Cooper
I prefer just using C++ and using std::thread/async for that type of shit.
Kayden Cooper
>Synchronous >Upload image to website >Site has to process it for 2 seconds >during this time no other requests can use the site
>Asynchronous >Upload image to website >Site has to process it for 2.1 seconds >during this time all requests also can visit the website, because the stack isn't blocked the entire time
Christian Bailey
I never understood why someone would want to use a synchronous language for the backend.
Is nodejs popular solely because it's related to web and web people know javascript?
Brody Perez
>he doesn't know about async/await kys
Cooper Adams
async await, user.
Josiah Morris
it's fast for small input/output, really good for streams and sockets,
I've read from people online who used it for larger computations and declared it as shit, of course everything stalls, because it's single-threaded, multi-threading is currently experimental
Colton Campbell
>I don't know what's the point of using nodejs if this is how you're gonna program, working around the asynchrony all the time. >Why, when an how to use asynchronous programming? Use the right tools for the right problems, you fucking mongol. You're trying to solve synchronous problems with a language/runtime that's made to solve asynchronous I/O-bound problems, and you're complaining that it doesn't work so well? Why in the name of fuck would it? Of course you have to work around the asynchronicity of Node if you're writing synchronous code. Maybe doesn't use Node for writing synchronous code, has that idea ever occurred to you, you dumb fucking nigger?