Draw is great, I use it to edit PDFs, though it doesn't always handle that very well, it's really nice when I need to do some simple stuff.

Except lots of applications need to be able to forget things, similar to how things can be destroyed in the real world

Forgetting what you had for lunch last Friday is not necessarily the same as changing what you had for lunch last Friday.

You could, for example, throw away the encryption key for that fact. What you had for lunch is now inaccessible, but the fact remains unchanged.

Yeah I agree. You should be demonstrating how you would write code in the job. Based on devs I've worked with, I don't think a pure type solution as presented is very maintainable.

On the job I don't have lines of code restrictions, and can use math functions.

> You should be demonstrating how you would write code in the job

That was forbidden, check the rules given by the interviewer.

I think part of the problem is that there is no other thread (outside of service workers), so that's why it's hard. In C# I would just fire up another thread to do the work and I don't have to worry about blocking the UI until I want to notify the UI from that thread. But I can't fire up a separate thread in JS so everything is done on the UI thread

I don't think it's the problem.

I think that it's a combination of two things:

1. many webdevs just have no clue what a thread is, because generally, they don't need it, so it isn't taught;

2. most of the documentation you can find online was written by people (and now ChatGPT) who don't understand async, sprinkle the word randomly and tweak things until they seem to work.

As a consequence, webdevs learn that async is magic. Which is a shame, because the underlying model is almost simple (the fact that we have both micro-tasks and tasks complicates things a bit).

When your answer is "the problem is the developers", your answer is always wrong.

Both your points, 1 + 2, are variations on that.

The right answer is the problem is the language design.

My points are "the problem is it isn't taught" and "the problem is the documentation available", so I'm not sure how you read "the problem is the developers".

Parent commenter helped implement async in JS, they know what they are talking about. JS has threads locked behind semantics. Web workers run on separate threads. I do a lot of heavy parallel processing that never blocks the UI with them all the time.

I stand corrected.

It looks like web workers is the way for JavaScript to do multi-threading.

Async has always been enough for what I need to do in the front end, as most of my long running processes are just calling a back end.

Edit to add: for context, I am a full stack developer and know what threads are... I just never have needed them in the browser.

Web workers are great for local compute and isolation. Unfortunately it's a hassle managing sane pooling because different platforms have different worker limits.

On the other hand, the isolation guarantees are strong. There aren't really any footguns. Messaging is straightforward, works with a lot of data types and supports channels for inter-worker communication.

This is not meaningfully true in 2024

*2025 (although still true of 2024 and several preceding years, heh)

The browser as a runtime is the epitome of worse-is-better.

Outside of workers, of which service workers are one type.

You can create a new thread via. `new Worker` but using a worker requires a separate file, and lots of serialisation code as you communicate via `postMessage`. TC39 module expressions helps but not a lot of movement recently. https://github.com/tc39/proposal-module-expressions?tab=read...

There's some progress on that proposal, just happening elsewhere. https://github.com/tc39/proposal-esm-phase-imports defines machinery for importing a ModuleSource object which you can instantiate as a Worker, and once that's done module expressions would just be syntax which evaluates to a ModuleSource rather than needing a separate import.

> But I can't fire up a separate thread in JS so everything is done on the UI thread

Yea targeting the web is nuts if you have other options!

His question was specific to not having your old device

But that's still not a circular dependency then, that's just the normal case for "I lost all my verification options" and it's exactly what the last option is for.

If I create an account via e-mail and password at a random service, destroy the password and delete the e-mail account, then it's not a circular dependency. In fact, the service has nothing to do with it, it can not know that you don't have access to either the e-mail or the password.

Correct if you don’t have your phone, you’re doomed. This can happen for a variety of reasons and is not an uncommon use case. Theft, damage, upgrades, etc.

I use https://github.com/maildev/maildev which you can run from docker. But +1 for dotnet, don't see much of that these days.

Cool that you can run that just from a Docker container. Thanks for the dotnet love! I use it for work, so it was a natural choice for building MailMock.

You say they chose not to fix it like it's a simple problem with an obvious solution

Ignore this, I misread what the author above wrote.

Yeah that's strange, it's like they heard that null was a mistake and removed it without realizing that it provides a useful function

Yeah the company asset is not source code. It's the relationships with devs and trust built up over years of delivering.