Manager: You can’t define an async function without using await.

Dev: Yes you can.

Manager: Well you shouldn’t, there’s no point!

Dev: Yes there is. It can turn blocking synchronous logic into work performed concurrently. In this case the perform—

Manager: It’s called async *await*. Async *AWAIT*! Did you hear the two parts to that? You shouldn’t ever have one without the other. THEY GO TOGETHER. Worrying about concurrency is for people who use callbacks which just goes to show how out of date your skills are. I’m reading a book on javascript and there are so many advanced techniques out there that I haven’t even seen you use ONCE!

Dev: …

*I looked at the book he’s reading, it’s from the < ES6 era… no wonder he doesn’t see me using any of those archaic patterns/hacks/workarounds…*

it finally happened, PM/PO/SM is now also dev シ

each standup he now also gives update about his work in progress, with his diligently designed subtasks, perfectly sticking to the daily script, like a good well-behaved employee boi. it's weirdly cute

devs can't await to review his first PR. feeling the strong urge to spank his ass for each minor coding style issue or poorly-named variable...

My brain wanted to type 'async' and 'await' at the same time

I typed awync

Trigger Warning - Don't date JavaScript developers.

They Promise to Callback but they won't. You'll Await in vain. They don't know how to Express themselves and React to such situations.
You might not be happy to hear this, but I'm trying to save you from a Garbage situation

I've been working on a proof of concept for my thesis for a few days and the async query calls drove me nuts for quite a while. I finally managed to deliver all query results asynchronously while still very much relying on a strong architectural design pattern. I am filled with caffeine, joy and a sense of pride and accomplishment.

PhD saga:

The applications have closed and yours truly shall await the results, which could come anytime in January or February.

And so I wait. I hate this limbo since there is nothing for me to do to impact the outcome. What's worse is that I am absolutely unmotivated to do anything else. Since this project is literally my dream, and despite how I'm trying to mentally prepare myself in case I don't get in, there's just something in my brain that goes like "nah. I just want this shiney thing. Just this and nothing else". So I don't even know what to do with myself.

*Sigh*

So, I've had a personal project going for a couple of years now. It's one of those "I think this could be the billion-dollar idea" things. But I suffer from the typical "it's not PERFECT, so let's start again!" mentality, and the "hmm, I'm not sure I like that technology choice, so let's start again!" mentality.

Or, at least, I DID until 3-4 months ago.

I made the decision that I was going to charge ahead with it even if I started having second thoughts along the way. But, at the same time, I made the decision that I was going to rely on as little external technology as possible. Simplicity was going to be the key guiding light and if I couldn't truly justify bringing a given technology into the mix, it'd stay out.

That means that when I built the front end, I would go with plain HTML/CSS/JS... you know, just like I did 20+ years ago... and when I built the back end, I'd minimize the libraries I used as much as possible (though I allowed myself a bit more flexibility on the back end because that seems to be where there's less issues generally). Similarly, any choice I made I wanted to have little to no additional tooling required.

So, given this is a webapp with a Node back-end, I had some decisions to make.

On the back end, I decided to go with Express. Previously, I had written all the server code myself from "first principles", so I effectively built my own version of Express in other words. And you know what? It worked fine! It wasn't particularly hard, the code wasn't especially bad, and it worked. So, I considered re-using that code from the previous iteration, but I ultimately decided that Express brings enough value - more specifically all the middleware available for it - to justify going with it. I also stuck with NeDB for my data storage needs since that was aces all along (though I did switch to nedb-promises instead of writing my own async/await wrapper around it as I had previously done).

What I DIDN'T do though is go with TypeScript. In previous versions, I had. And, hey, it worked fine. TS of course brings some value, but having to have a compile step in it goes against my "as little additional tooling as possible" mantra, and the value it brings I find to be dubious when there's just one developer. As it stands, my "tooling" amounts to a few very simple JS scripts run with NPM. It's very simple, and that was my big goal: simplicity.

On the front end, I of course had to choose a framework first. React is fine, Angular is horrid, Vue, Svelte, others are okay. But I didn't want to bother with any of that because I dislike the level of abstraction they bring. But I also didn't want to be building my own widget library. I've done that before and it takes a lot of time and effort to do it well. So, after looking at many different options, I settled on Webix. I'm a fan of that library because it has a JS-centric approach. There's no JSX-like intermediate format, no build step involved, it's just straight, simple JS, and it's powerful and looks pretty good. Perfect for my needs. For one specific capability I did allow myself to bring in AnimeJS and ThreeJS. That's it though, no other dependencies (well, at first, I was using Axios because it was comfortable, but I've since migrated to plain old fetch). And no Webpack, no bundling at all, in fact. I dynamically load resources, which effectively is code-splitting, and I have some NPM scripts to do minification for a production build, but otherwise the code that runs in the browser is what I actually wrote, unlike using a framework.

So, what's the point of this whole rant?

The point is that I've made more progress in these last few months than I did the previous several years, and the experience has been SO much better!

All the tools and dependencies we tend to use these days, by and large, I think get in the way. Oh, to be sure, they have their own benefits, I'm not denying that... but I'm not at all convinced those benefits outweighs the time lost configuring this tool or that, fixing breakages caused by dependency updates, dealing with obtuse errors spit out by code I didn't write, going from the code in the browser to the actual source code to get anywhere when debugging, parsing crappy documentation, and just generally having the project be so much more complex and difficult to reason about. It's cognitive overload.

I've been doing this professionaly for a LONG time, I've seen so many fads come and go. The one thing I think we've lost along the way is the idea that simplicity leads to the best outcomes, and simplicity doesn't automatically mean you write less code, doesn't mean you cede responsibility for various things to third parties. Those things aren't automatically bad, but they CAN be, and I think more than we realize. We get wrapped up in "what everyone else is doing", we don't stop to question the "best practices", we just blindly follow.

I'm done with that, and my project is better for it!

I'm still using .then().catch() instead of the async await.
So, first of all, Fuck you for calling it a STANDARD now. its nowhere near to be called standard. You wanna get some data from an API? Wanna call it using axios or fetch? What if the server is down? what if there's an error that you don't even know existed? Where do I get that kinda error in async await? try-catch? no thanks :| I'm good -_-

Everytime I think I understand async await, I get painfully reminded that I don't.

TL;DR: don’t use Array.forEach use
for … of … instead.

Array.forEach is synchronous, but pass it an async function and the bastard does not await it.

I was so sure that it was sync….

Wasted 2h

Slacking off on tests for medium size projects. I have one project that I consider a major achievement as of today, the NPM package @lbfalvy/react-await. It has like two tests and it does a _lot_ more than two things.

Don't get me wrong, I test it thoroughly, but not in an automated way.

There's a special place in hell for JS people using `.then()` and `.catch()` instead of simply `await func()`.
Why have 5 lines of code with an await, when instead you can have 5 nested `.then` callbacks.

And yes I know there are some cases where async/await isn't applicable, but that's rather rare

It's nice that more and more languages are introducing async/await syntax, but by the example of Rust in particular I'm starting to wonder why we don't instead introduce this syntax for monads in general?

We could have a keyword (say, `bind`) which unwraps a value from any monad provided that the return value of the function is wrapped in the same monad. The ? operator does something a little similar, and I'll be intrigued whether it can actually be implemented for monads other than Result and Option once GATs are stabilized. In particular in the case of Rust, it would be possible to create a reference counting monad for heap-bound management of objects derived from references.

Does anyone have a better way to implement throttle on value changes in c# ?

I'm using this right now and I find it a bit "too much lines"

@highlight
searchThrottle.Throttle(TimeSpan.FromMilliseconds(200))
.Select(e => ((string)e.Value)?.Trim())
.DistinctUntilChanged()
.Subscribe((x) =>
{
quisckSearch = x;
InvokeAsync(async () => await LoadFirstPage());
});

Rant/question:
httpDoSmth1().subscribe(x =>
...then(y =>
httpDoSmth2(x).subscribe(z =>
//do smth with z
return z
)
)
)
Isn't this (not my code) callback hell all over again? The 2. http call expects results from the 1. http call. I feel like this could be solved cleaner using async await/switchMap/etc. ... but not like this.

So I've been forced to work on a project for some time using JavaScript

Many parts of it must function synchronously and js has a lot of libs and otherwise that will spawn threads in threads

I'm horrified by the amateurish appearance of my code

Await this await that
Everything enclosed in something else and what is worse is the base node modules I'm using are ALL asynchronous! Were talking methods that one consistently has to wait on finishing like db reads !

Why is js so dumb ?