Maybe i misunderstood what you were going for. Just saying: Yes, their web fetch handler is not a web standard but the only standard there is to accomplish something like that had a few issues and they picked something that looks as generic as possible. vs import {pretendToStartServer} from ('our:global-injected-pseudo-sdk')
I really loved the idea of using service worker sdk and having something that works in browsers too so the conceptual model of edge functions are spanning backends, edge POPs and browser runtimes.
AFAIC, WinterTC doesn't specify how to start an HTTP server. Their minimum common API requires, among other things, that the Request and Response interfaces from the fetch specification are present. Unfortunately, it does not specify any sort of serve function.
Because an edge runtime should not directly start servers in the first place. You provide handlers that fulfil requests from the system. Edge runtimes that pretend to start the servers in the edge worker context are flawed and ugly from the very start. APIs like that leak implementation details and increase vendor lock-in for no added benefit.
So I guess it really is true that nothing actually gets removed -- except the one that wasn't actually controlled by WhatWG or W3C.
Is there still a real-world use case for XHTML/"XML syntax for HTML", or is this just exhibit A that no standard can actually be removed from browsers?
Re: XSLT, back in the everything-is-XML days I desperately wanted to like XSLT, it seemed so useful (I was that annoying co-worker telling everyone it's supposed to be pronounced "exalt"). But it was such a disaster to actually write or read and no real debugging was possible, I had to use a LOT of conditional bgcolor=red to figure anything out. It didn't take very long to come to the conclusion that XPath was the only useful part.
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.
Switching to Deno might help. It's sandboxed by default and offers granular escape hatches. So if a script needs access to a specific environment variable or read or write specific files, it's simple to configure that only those accesses are allowed.
> My favorite testing framework, AVA, still isn’t supported.
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.
> And I'm actually quite happy that most Deno projects don't have a custom testing and linting setup.
I feel similarly. The standard configurations (e.g. tsconfig, linting, formatting) and bolts-included tooling (test, lint, fmt, etc.) are what make Deno so great for developers.
I've started using Deno in my spare time for various projects - and it just _feels_ more productive. I go from idea to testing TypeScript in minutes - which never happened in Node land.
> The standard configurations (e.g. tsconfig, linting, formatting) and bolts-included tooling (test, lint, fmt, etc.) are what make Deno so great for developers.
And that's great for greenfield projects - although there's competition with Biome and Vite / Vitest for a lot of those - but the vast majority of Node use today is existing projects, and at least at one point Deno (and Bun, maybe others) were marketed (I think?) as a drop-in replacement for NodeJS. But maybe I'm misremembering.
My main gripe is a decade(s?) old Firefox bug related to rendering an HTML string to the DOM.
That may be a fairly specific use case though, and largely it still works great today. I've done a few side projects with XSLT and web components for interactivity, worked great.
This bug is specifically about <xsl:text disable-output-escaping="yes"> not working in Firefox. How is disabling output escaping relevant in regards to sharing templates between pages?
> The only combination that fails to render these entities correctly is Firefox/XSLT.
Which is one good reason not to adopt XSLT to implement HTML includes. You just don't know what snags you'll hit upon but you can be sure you'll be on your own.
> Bug 98168 (doe) Opened 24 years ago Updated 21 days ago
Well it does look like someone's still mulling over whether and how to fix it... 24 years later...
If you rename a .html file to .md, your markdown viewer should render it just the same as your browser did.