n_e

In the example you don't even need the default clause and the helper (the error message without it is worse though).

Totally agree. It seems like a good idea at first as it's simple, but, since the deployment concerns don't match the source code management ones it breaks down quite quickly.

For example it's quite readable when deployment order matches the commit order, but it gets problematic when e.g. the deployed version is rolled back to a previous version.

It also gets messy as environments are added, or even worse you have to manage customer-specific deployments.

> what should I choose and why?

You should choose Node.js unless you have a good reason to use something else. This is what everyone uses, and it is used widely enough that it's in the same position as Java, i.e. it will be supported forever.

Also the other runtimes only offer incremental improvements.

Regarding the blogposts, you don't read a lot about Node.js because it is mature software and there isn't a lot of drama or new things to talk about.

This sounds suspiciously like non-developers dumping their vibe-coded projects on online communities

> 2FA is quite simple, right?

No?

Aside from the fact that the implementation must be secure, you want for example to:

- handle accounts that have lost their second factor in an way appropriate for your business - decide what to do with accounts who don't configure it. If e.g. you want to send them authentication codes via email or SMS that's another can of worms.

Let alone the simple things such as making sure that your implementation works with the various TOTP apps

It's a mistranslation, the original quote is "Une enquête en recherche des causes de la mort est ouverte afin de déterminer l’origine du décès, aucun élément suspect n’ayant été découvert sur place par les services primo-intervenants. Les investigations sont en cours", which translates to "no suspicious element was found", not "no suspect was found"

> There is general agreement among participants that he has engaged in off-wiki canvassing and is not here to constructively build the encyclopedia. There is also a significant concern shared by many editors that his actions constitute calls for outing.

You have web workers, and for shared memory and synchronisation respectively SharedArrayBuffer and the Atomics namespace.

Interestingly, despite the QUERY request being safe, the RFC says it's subject to preflight requests:

> A QUERY request from user agents implementing Cross-Origin Resource Sharing (CORS) will require a "preflight" request, as QUERY does not belong to the set of CORS-safelisted methods (see [FETCH]).

As a user, I like when things appear to sync instantly and perfectly, such as in Google Docs.

As a developer, I hated the article and many of the comments I read thus far because:

- Having clients and a server properly sync and not lose data in the event of a network failure amounts to having a consistent distributed system which is not easy to do, and the commenters don't seem to have understood that

- I hate having written a long document and then losing it because the sync code is buggy, so the previous point becomes even more important.

So reading many of the things here has been mildly infuriating.

That being said, none of these people are likely affiliated with Linear, and given the overall quality of the product I'm pretty sure it works properly.

Unfortunately it's not limited to the trendy topics. For example there is a huge amount of factually wrong comments on the topic of npm vulnerabilities. I'm sure it's the same on topics I know less about.

> The app would look up in both databases. If it exists in any, there would be a session.

And if you find the session with differing values in both databases, how do you know which one is up-to-date?

You need an algorithm to pick which data is right, such as electing a master instance.

And that brings us back to the original discussion: to manage sessions (unlike caches) in a highly available way, you need to setup HA (or reimplement it, which obviously is a bad idea). You can't read round robin from multiple non-HA instances.