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

Interviewer: Here is the interview challenge. Tell me what the expected output is. You have 5 minutes.

** 100 line class with 4 async methods that contain if/thens nested 4 layers deep that call each other and log things to the console

Dev: Ok wow this is a bit of a maze to work through but I’ll try my best.

** 1 minute later of reading through the code

Interviewer: One minute has elapsed. There is now 4 minutes remaining.

Dev: Actually could you please not interject with time updates like that while I’m reading code? It makes the challenge harder than necessary. Just letting me know when the time is up would be fine.

Interviewer: Ok.

** ~2 minutes later trying to comb through this spaghetti mess

Interviewer: What do you think are you getting close to figuring it out?

Dev: …

At my first big boy job at a start up with only 50 users, we noticed we had cloud cost spikes about 20x larger than we were expecting. I remember spending all night debugging it, checking the requests as they go through.

The culprit? Someone left an async on a UseEffect with a variable that was regularly updated as a parameter.

In other words: every time a request was fired, the variable would change… so the function would sense the variable changed and fire it again, and so on.

Felt like a total hero.

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

I typed awync

> turning the whole codebase into a muddy ball of dirt because the leader didn't like 1 (one) call to an async function on startup

Way to go buddy, you sure show them how it's done.

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.

yeah we use isomorphic async hydrated SSR pseudo-rendering with edge-server chunked ES module CSS-in-JS-in-CSS ESNext TypeScript interop through GraphQL in react-native-web transpilation to react-dom in NextJS isomorphic rendering context React hooks

Smartphones ruined social media. msn, yahoo, ICQ, even Facebook for some years - i loved them before. When you felt lonely you just looked who was online from your list and said hello and chat a bit because most likely the person sat in front of his or her PC and had time. At least it was indicated by the online status. I miss this feeling sometimes very much.
Now that everyone is online all the time this is gone. Among grown ups you only write someone if you have something important to say like setting up a date or what, and among the younger you send only memes. And even if you start a conversation you don't (and can't) expect a real time answer but see it as so called async comversation.

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!

Looking for platform specific language options for a new project at work and reading articles from well known sources.

If you start your article with something like, "when I think of a good programming language, I think of JavaScript", I'm going to punch out of your shitty opinion faster than an async function.

When you're trying to convey an unbiased message you generally don't start with, "I'm an absolute shill for {language}".

What the fuck happened to journalistic integrity?

Python async is a total, unapologetic shitshow. It’s as if the design goal was explicitly to invalidate the maximum number of thoughtful stackoverflow QAs possible. Pro tip: make you sure to memorize the release dates of every minor version of python from 3.5-3.10, so that you know which stackoverflow answers are not relevant in any way to your codebase.

Sharing a first look at a prototype Web Components library I am working on for "fun"

TL;DR left side is pivot (grouped) table, right side is declarative code for it (Everything except the custom formatting is done declaratively, but has the option to be imperative as well).

====

TL;DR (Too long, did read):

I'm challenging myself to be creative with the cool new things that browsers offer us. Lani so far has a focus on extreme extensibility, abstraction from dependencies, and optional declarative style.

It's also going to be a micro CSS framework, but that's taking the back-seat.

I wanted to highlight my design here with this table, and the code that is written to produce this result.

First, you can see that the <lani-table> element is reading template, data, and layout information from its child elements. Besides the custom highlighting code (Yellow background in the "Tags" column, and green gradient in the "Score" column), everything can be done without opening even a single script tag.

The <lani-data-source> element is rather special. It's an abstraction of any data source, and you, as a developer can add custom data sources and hook up the handlers to your whim (the element itself uses the "type" attribute to choose a handler. In this case, the handler is "download" which simply sends a fetch request to the server once and downloads the result to memory).

Templates are stored in an html file, not string literals (Which I think really fucks the code) and loaded async, then cached into an object (so that the network tab doesn't get crowded, even if we can count on the HTTP cache). This also has the benefit of allowing me to parse the HTML templates once and then caching the parsed result in memory, so templates are never re-parsed from string no matter how many custom elements are created.

Everything is "compiled" into a single, minified .js file that you include on your page.

I know it's nothing extraordinary, but for something that doesn't need to be compiled, transpiled, packaged, shipped, and kissed goodnight, I think it's a really nice design and I hope to continue work on it and improve it over time

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

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 -_-

!rant
Loving the the fact that constructors in Swift (initializers) can fail (returning null/nil) and be async.

In C# there is no other way than using static methods instead.

Question: We are planning to transition our old ES5 codebase to modern ES6/ES7 and even typescript.

What would be the build tool you would recommend if we want to start supporting ES6/ES7 and even Typescript?

Webpack, Vite some other?

This is a vanilla Javascript Project with large codebase it's been built using custom build tools like UglifyJS and UglifyCSS and of after lots of begging it finally got the green light to move to a more modern build tool and start supporting a more standard JavaScript Features.

Mainly I want to move to TypeScript but transition would be slow so the build tool would need to support .ts and .js as well, that is traspile both the .ts and .js into one final production build.

What build tool would you recommend for that?

I just want to combine python3 pygame with asyncio without asking Shiva for a dance.

It's a shame that people don't want to use F# but prise C# for how cool it became and continue becoming. At the same time, little do they know that many of the features were simply drawn from F#.

It's just rediculous how far this OO and C-Style syntax crap has progressed. They keep copying things from functional langugages, making the initial language to be a monstrocity like C++ is now, insted of just using languages like C#. I mean, it was right there before C#: async/task, immutablility, records, indexes, lambdas, non-null by default, who the hell knows what else.
Besides, many people (in my company at least) are just blindly overengineering with patterns and shit, where a simple function would be just enogh.

Watch some some NDC talks about F#, in particular those of Scott Wlaschin. It's just better in so many ways: less noice (I'm looking at you, brackets, commas and semicolons), the whole LOT of type inference and less duplication (just look at the C# signatures of linq methods - it's difficult to read them), immutability by default, non-nullable by default, ADTs and pattern matching, some neat features like type providers (how many times have used "paste special" or an online tool to create C# classes from a JSON/XML file, and how many times have your regenrated it because of schema changes?) and units of measure.

Of course, in some cases it's not optimal, in some cases mutable datastructures of C# are better for performance. But dude, how many performance critical systems have you wrote in C#? I mean, if it comes to performance you should use Rust or C++ or C after all.

*sighs*

Pygame can handle kinect, but can't interface with asyncio. It freezes if I try to run event.wait in an executor. You may write the best game engine for a language, if you won't use language standards and don't support async, then it's shit.

Continuing to learn k8s ecosystem and to achieve acceptable level
With trying eventually Helm, Argo CD and even trying to use not managed setup for k8s.

Going though books to find out theory about being SRE.
And about data intensive apps.

Learning and trying Kafka

Learning and trying FastAPI and diving in generally to async python ecosystem

Learning Go.

Learning few more books to increase code quality and its compositioning.

Getting more practice in monitoring and logging systems with applicating them to k8s.

Guys cover your eyes I'm gonna say two bad words inside a paragraph

Fuck JavaScript and asynchronous programming - I'm not skilled enough for this so I have to insult it periodically until I'm skilled enough to know partially more than now what the fuck I'm doing (therefore the times I use bad words when referring to js and async programming will decrease - or maybe at the increase of knowledge, my usage of bad words will augment. Only time will tell).

Today on fucked up Javascript stuff: Call stacks whose bottom isn't an entry point or event handler

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

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());
});

Useless JS library #0 ready.
Communication among windows in the same window group (iframes and popups with a common root), with dynamically generated objects, so it feels as though you were just calling local async methods.
Useless JS library #1 will be a layout manager, a program that manages panes and tabs, context menus, toolbars and a menubar much like Visual Studio, and let all of that communicate through Useless JS library #0.
Since JS is sloooooow, I try to make everything run the fastest possible, trading startup for runtime resource usage. #0 fulfills this, any message will take exactly 4 stops, although registering a callable method set takes .3 sec.

Typescript is my new favorite and my grudge is the stupid scoping of type assertions. I have an async function that checks whether a variable is set and awaits a change event if it's undefined. This function is working javascript but invalid according to typescript, because it relies on the exact type changing while the function is running. I had to convert it to a mess of promises to bypass this because (and this is the best) the callback-based syntax of identical meaning will reset all type assertions, even locals that are never written after the callback's creation.

why is async comm preferred over sync? Since when did people learn how to read?

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.

A year ago I built my first todo, not from a tutorial, but using basic libraries and nw.js, and doing basic dom manipulations.

It had drag n drop, icons, and basic saving and loading. And I was satisfied.

Since then I've been working odd jobs.

And today I've decided to stretch out a bit, and build a basic airtable clone, because I think I can.
And also because I hate anything without an offline option.

First thing I realized was I wasn't about to duplicate all the features of a spreadsheet from scratch. I'd need a base to work from.

I spent about an hour looking.
Core features needed would be trivial serialization or saving/loading.

Proper event support for when a cell, row, or column changed, or was selected. Necessary for triggering validation and serialization/saving.

Custom column types.

Embedding html in cells.

Reorderable columns

Optional but nice to have:

Changeable column width and row height.

Drag and drop on rows and columns.

Right click menu support out of the box.

After that hour I had a few I wanted to test.

And started looking at frameworks to support the SPA aspects.

Both mithril and riot have minimal router support. But theres also a ton of other leightweight frameworks and libraries worthy of prototyping in, solid, marko, svelte, etc.
I didn't want to futz with lots of overhead, babeling/gulping/grunting/webpacking or any complex configuration-over-convention.

Didn't care for dom vs shadow dom. Its a prototype not a startup.

And I didn't care to do it the "right way". Learning curve here was antithesis to experimenting. I was trying to get away from plugin, configuration-over-convention, astronaut architecture, monolithic frameworks, the works.

Could I import the library without five dozen dependancies and learning four different tools before getting to hello world?
"But if you know IJK then its quick to get started!", except I don't, so it won't. I didn't want that.

Could I get cheap component-oriented designs?

Was I managing complex state embedded in a monolith that took over the entire layout and conventions of my code, like the world balanced on the back of a turtle?

Did it obscure the dom and state, and the standard way of doing things or *compliment* those?

As for validation, theres a number of vanilla libraries, one of which treats validation similar to unit testing, which seems kinda novel.

For presentation and backend I could do NW.JS, which would remove some of the complications, by putting everything in one script. Or if I wanted to make it a web backend, and avoid writing it in something that ran like a potato strapped to a nuclear rocket (visual studio), I could skip TS and go with python and quart, an async variation of flask.
This has the advantage that using something thats *not* JS, namely python, for interacting with a proper database, and would allow self-hosting or putting it online so people can share data and access in real time with others.

And because I'm horrible, and do things the wrong way for convenience, I could use tailwind.
Because it pisses people off.

How easy (or hard) would it be to recreate a basic functional clone of the core of airtable?

I don't know, but I have feeling I'm going to find out!

For a side project I identified the need for RPC (originally over Websocket but can be extended to WebRTC/DTLS) that supports

- JSON-serializable values
- Promises
- MessagePorts (including shortcut detection for ports that are passed back on a different route)
- async functions

I have ideas for all of these and this is an exciting prospective library, but it's also major scope bloat that will prevent me from ever finishing the project that depends on it.

Would you be interested in such a library if it ever got built?

I have a readonly object property foo on a typescript class. When I create an instance bar by calling the constructor, bar.foo doesn't compare equal to this.foo as seen from within bar several async calls later. What could I have possibly fucked up?

I can't google jargon, what do you call it when you "flip" a function call, such that the call becomes an event in some dispatch system and return becomes a call on the event? I had to implement five such APIs this week with surface level differences and I'm starting to feel like it has to have a name if it's this popular.

For the pedantic, I mean async calls in JS in particular, I know you can't just invert a synchronous function call that uses a stack without peek.

Rust, I demand you give me dyn trait support for async traits now.