-
Agree that try/catch is verbose and not terribly ergonomic, but my solution has been to treat errors as values rather than exceptions, by default. It's much less painful to achieve this if you use a library with an implementation of a Result type, which I admin is a bit of a painful workaround, but worth it. I've recently been using: https://github.com/swan-io/boxed.
By far the greatest benefit is being able to sanely implement a type-safe API. To me, it is utter madness throwing custom extensions of the Error class arbitrarily deep in the call-stack, and then having a catch handler somewhere up the top hoping that each error case is matched and correctly translated to the intended http response (at least this seems to be a common alternative).
-
InfluxDB
InfluxDB – Built for High-Performance Time Series Workloads. InfluxDB 3 OSS is now GA. Transform, enrich, and act on time series data directly in the database. Automate critical tasks and eliminate the need to move data externally. Download now.
-
cofx
A node and javascript library that helps developers describe side-effects as data in a declarative, flexible API.
-
I was really hoping this article would discuss the benefits of using raw generators over async/await.
By using async/await, we are inherently limited by the flow control because we are forced into await resolving promises.
This is why libraries like redux-saga[0] or cofx[1] use generators.
https://redux-saga.js.org
-
-
It drove me crazy too, until I needed to use Puppeteer which requires you to write async/await (there are Puppeteer implementations in other languages, but they all seem to make compromises I didn't want). Generally speaking, async/await allows you to write code that looks and feels serial. Perhaps try using one of the async libraries for PHP to wrap your mind around the concept of async/await (like https://github.com/spatie/async)
-
posterus
Composable async primitives with cancelation, control over scheduling, and coroutines. Superior replacement for JS Promises.
Async/Await covers the 80% of use cases for async logic in JS. Most people aren't really using promises as multicast references. They don't call `then` in one place, hang on to the promise reference, then call `then` again somewhere else (perhaps to represent a cached value); they call `then` once on the reference because it's just a moment in a composite operation.
It's for this reason that I think this library[0] is the more appropriate abstraction for that same 80% of use-cases, as its more memory efficient since you can represent the same composite operation that generates multiple promise references with a single object (a unicast reference instead). I haven't learned Rust but apparently the author bases this on Rust's ownership principle.
[0]https://github.com/mitranim/posterus
-
hyperscript is designed for small, embedded front end scripting needs: toggling classes, listening for events from its sister project, https://htmx.org, etc. It isn't a general purpose programming language for use, for example, on the server side in a node-like environment.
you can still perform things asynchronously by wrapping any expression or command in an `async` prefix:
https://hyperscript.org/commands/async/
but there isn't a mechanism for resolving all of them
although, now, come to think of it, the following would work:
set results to {result1: somethingThatReturnsAPromise(), result2: somethingElseThatReturnsAPromise()} -
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
