A smartphone is also a genuinely good all-around tool. Even social media is a genuinely good tool for connecting people.

Yet, I feel like we've been overly optimistic about the impact of said tools on us and our societies in the past two decades.

Smartphones are so good, in fact, in some societies, half of us are addicted to them. Billions of people world-wide.

I ask myself: Will LLMs enrich my thinking in the long run, or will they ruin it?

And what about most people? Will half of us outsource most of our thinking in a decade from now?

Given the speed and global scale that we're running these experiments with, it's fair, I think, to be a bit sceptical of the conclusion that, in the long run, LLMs will enrich our thinking.

If you rename a .html file to .md, your markdown viewer should render it just the same as your browser did.

Been using Deno happily for many years now.

Did I miss anything?

I assume by Service Worker API, you mean FetchEvent? [1] As in:

self.addEventListener("fetch", (event) => {});

That is a web standard indeed, but not one that was designed for use as a general-purpose HTTP handler, but rather for use in a Service Worker proxy.

[1] https://developer.mozilla.org/en-US/docs/Web/API/FetchEvent

[1] https://developers.cloudflare.com/workers/runtime-apis/handl...

> You provide handlers that fulfil requests from the system.

As I said previously, though I wish they were, such handlers are not part of WinterTC.

And then again, how those handlers are registered is also not part of WinterTC, which I also wish it were.

> APIs like that leak implementation details

How?

Almost all runtimes, like Bunny Edge Scripting, Cloudflare Workers, Deno, Bun, etc. use the same basic signature for the handler:

(request: Request) => Promise

Only how you register said handler is, unfortunately, different for each runtime.

https://en.wikipedia.org/wiki/First_They_Came

If I need the markup of a page to not contain any structural errors, I often use XHTML for testing at least because, though it's a little more verbose, if there's a nesting error, for example, the browser will flat out refuse to render it and show some sort of stacktrace error page instead. So it's quite a good built-in "tool" for checking that your markup is clean.

With HTML, everything goes and the browser will happily render broken markup, which is probably the correct default for the web as a whole. After all, you surely don't want a page like Wikipedia to show an error message to its users because a developer forgot to close a tag somewhere.

Have you checked recently? The docs (https://docs.deno.com/runtime/fundamentals/testing/) specifically mention AVA as being supported. Then again, I'd assume that most devs using Deno just use the built-in `deno test` instead of a third-party testing framework.

> The one area of Node compatibility that I want the most is support for ESLint configs in the Deno linter.

Again, have you checked recently? According to the docs this is supported: "Deno's built-in linter, `deno lint`, supports recommended set of rules from ESLint to provide comprehensive feedback on your code. (...) You can specify custom rules, plugins, and settings to tailor the linting process to your needs." (https://docs.deno.com/runtime/fundamentals/linting_and_forma...)

I've been using Deno for 6 years now. And I'm actually quite happy that most Deno projects don't have a custom testing and linting setup.

Considering that the group on UBI was also happier, felt more financially secure and freer than the control group, this is hardly surprising.