Posts in "javascript"

Structured Concurrency and Effects for JavaScript. Stop worrying about asynchronous bugs and memory leaks. Effection gives you leak-proof, composable operations with the structured concurrency guarantees you didn’t know you needed.

Effection takes a different angle on async JavaScript – instead of bolting cleanup and cancellation onto promises after the fact, it bakes structured concurrency in from the ground up. Every operation automatically cleans up after itself, including all child operations it spawned, so resource leaks become a thing of the past. The API feels familiar too – just regular let, const, try/catch/finally – no exotic abstractions to learn. Dependency-free and under 5KB gzipped, with first-class TypeScript support. The GitHub repo is worth a look.

Also see their post The Hearbreaking Inadequacy of AbortController for a great explianer of the type of problem Effection is solving.

When I arrived at Inato, the codebase was written in ES6. Then, we added some robustness with Flow. It helped us perform major refactors and lower our bug count. We were happy… until problems showed up.

I’ve been using Flow for a bit over 3 years now on the same project. I have had experience with typed languages before (.Net C#, Java) so it was not an entirely new thing, but I admittedly found many annoyances with types in these languages and I was always eager to use new features in a language (C#’s var for one) to reduce the overhead. I found it annoying that the compiler would complain if I told it the wrong type, but tell me what type it should be. I mean if it knows what it is, how about it just dealt with it and stop bothering me? 🙄

So coming to and environment that used typed javascript (Flow) I was skeptical at first… but it quicly became clear that there were whole classes of bugs that didn’t exist because I had the safety of a type system… ensuring I wasnt passing the wrong things or edge cases were properly covered (looking at you null or undefined 🤨)

But 3 years on and supporting Flow in our still growing codebase has been wearing us down. Third party library support is… spotty. Updates to flow-bin have lead to a slew of new errors (aka newly supported cases) with little help from the error messages or library typedefs to previously “happy” codebases (redux connect and @FlowFixMe like cookies and cream), to the point that we are wondering “is it all worth it?”

Has TypeScript won the war of developer mindshare? It sure is time for us however, and I’m relieved to see we are not the only ones.

Comprehensive and exhaustive JavaScript & Node.js testing best practices (August 2019)

Pretty good set of guideline for testing Javascript (frontend and server) with code examples and examples of anti-patterns

Blazing fast, zero configuration web application bundler

I was just talking with some folks at a meetup last night about the pain of webpack configuration. In previous jobs, spinning up a new app was a regular thing so I got pretty adept at doing the webpack dance, but at the current gig, I’m working on a large React app that was setup before I got here so I havent had to dive into webpack for over a year! This is going on the short list of things to check out with my next pide project.

Tabs in browsers (not browser tabs) are one of the oldest custom UI elements in a browser that I can think of. They’ve been done to death. But, sadly, the majority of times I come across them, the tabs have been badly, or rather partially implemented.

So this post is my definition of how a tabbing system should work, and one approach of implementing that.

A useful cheat-sheet of Flow types generated from the source code.

Lerna is a tool that optimizes the workflow around managing multi-package repositories with git and npm.

I just started using this and I’m sold. I’ve found while I often like the idea of splitting a codebase into multiple packages, there’s significant overhead of releasing, managing multiple repos, package registries etc. required. Lerna makes this so much simpler to ease into by managing multiple packages (that can be published independently if that’s your thing) under a single mono-repository. So with this I can properly split my code into sane packages without going insane trying to manage it all.