Actually, that was part of the original plan - https://caniuse.com/iframe-seamless

It worked rather like a reverse shadow DOM, allowing CSS from the parent document to leak into the child, removing borders and other visual chrome that would make it distinguishable from the host, except you still had to use fixed CSS layouts and resize it with JS.

We eventually stopped because we were relying much more on external tools (eg npm, webpack) which had all sort of issues over webdav mounts. Maintaining all this code management infrastructure in parallel wasn't worth it in the end, and we moved the code back to disk, switched to git, etc.

And photoshop silently ignoring webdav I/O errors when saving designs didn't help either.

You already have tagging by type on the filesystem - the file extension. That allows you to limit file searches. Add extra metadata to extensions if the same extensions have different roles (.backend.ts, .frontend.ts, .html.template, .text.template)

These days I prefer to structure for easy removal of code - everything for eg. a widget (frontend, backend, css) goes into a folder and I only need to remove that folder when the widget is retired, and linting/validation will show me the few remaining path references I need to cleanup.

(double opt-in doesn't really help with the latter as you're still mailing it)

Simple solution: completely remove the email, and flush the cache. No accidental mailing.

As far as spamtraps go, I don’t think there’s a way to realistically address this. There’s a couple of well-known services, like spamex, but it’s easy to set them up, if you have your own domain.

I use spamex, because I want people to know it’s a spamtrap.

Plus, using TS directly to do runtime validation of types will become a lot more viable without having to precompile anything. Not only serverside, we'll compile the whole thing to WASM and ship it to the client to do our runtime validation there.

If you disassemble some armv8 binaries that aren't dealing with Javascript, you do see still see FJCVTZS.

When a company buys from another company, no net VAT is collected - it’s only collected when a consumer enters the picture.

True but ..

> Also mobile devices back then had limited storage, didn't have cameras, weren't Internet connected, etc.

which also means they didn't have a lot of data worth backupping

2004 mobile devices are usually either MP3 players or PDAs. Both synced over either a USB cable (or fancy infrared stuff) and were mostly just downloading from a PC. Not much was lost if the device crashed except your Bejeweled progress.

and it can't be free.. even though the systems might have no further marginal cost per transaction, banks still need to do anti-money laundering checks, and someone's gotta pay for that

This would be so much more readable with `using`

  {
    using lock = navigator.lock('my_resource');
    await do_something();
    await do_something_else();
  }

  with lock {
      // do stuff 
  }

This syntax looks more like Python or Rust.

Edit: Nevermind, release of the lock is automatic when the callback resolves its promise. I get it now.

   navigator whileLocked:'my_resource' do:{ :protected |
      protected doSomething.
      protected doOtherThing.
   }

https://github.com/nodejs/node/pull/48518 https://github.com/tc39/proposal-explicit-resource-managemen...

Catch/finally not sharing a scope with try is a repeated mistake, that I surely agree with!

    const denialOfService = res => void navigator.lock(res);