Hacker News Reader

Comment by slipperydippery | Hacker News Reader

Having a reasonably complete and well-performing set of XML tools available in the browser is really nice.

The counterpoint seems to be "well it has Javascript so we don't need actual features since you can theoretically write anything in JS" but one of the nicest things about it was having that toolkit available to Javascript. You can spin up a DOM for arbitrary XML and apply a bunch of natively-compiled, fast tools to it, coordinating and supplementing that with JS. Then present that to the UI as HTML. It's very nice.

I'm on team "the right move is to upgrade these, not remove them".

If they want to remove things to simplify the spec I've got a list I'd suggest, but it's mostly stuff added in the last decade.

View on HN

I'm sympathetic to the argument that the feature is an elegant one. But at the same time, maintaining it is not cost-free; every line of code written, imported, or linked poses an ongoing "tax" and/or risk. This is a garden-variety product management decision: is it worth the ongoing maintenance and risk? As a responsible PM, you have to weigh the costs against the benefits, and I think they've presented sufficient evidence users have voted "no" on the benefits.

As I said in another thread, not everything of value or benefit gains meaningful adoption. A rational actor doesn't preserve everything of value for its own sake. At best, we call people who do "museum curators," and at worst, "hoarders."

The people stewarding the Web platform have neglected a lot of nice things, among them this—a major version two major versions ahead of what's in browsers, is eight years old.

That it still has any use on notable sites at all seems like a decent cue to at least try not neglecting it before declaring nobody wants to use it.

... however, it's mostly useful for doing things that owners of walled Web platforms have no interest in, like working with interoperable protocols & formats. They've been killing those through active moves and neglect for 15 years, so why would they do something that makes that easier & nicer?

It seems like a long logical leap that browser authors have no interest in working with interoperable protocols and formats--despite all the work they put into maintaining and improving Javascript (a terrible language since the day it was born), HTML, CSS, downloadable fonts, TLS and other security protocols, SVG and other image formats, security tokens and keys, WebUSB (!), WebRTC, etc.--because they want to drop a feature that practically nobody uses.

> ...because they want to drop a feature that practically nobody uses.

Outside of the Googleplex, I expect that far, far, far fewer people use WebUSB than use XSLT.

Plus, attaching devices that have field-reprogrammable firmware and have always assumed that the only thing that can access them is software running on the local system directly to the worst parts of the Internet seems like a shockingly poor idea, from a security perspective.

I'm no champion of WebUSB, and I have no idea what its usage stats are. I'm only saying that the idea that browser vendors are on some sort of mission to stifle open standards and interoperability is ludicrous on its face.

There are some that would say that moving a standard that covers a large number of complicated things from a versioned standard to a "living standard" makes interoperability impossible for all but the most well-financed organizations. I agree with this assertion.

I'll also point out that (for quite a long while now) only two companies produce the major browser engines: Google and Apple. Mozilla Firefox doesn't count as an independent entity because without the funding from Google, it would have shut down long, long ago.

So, anyway. If Google wants to remove a complicated, security-compromising feature that very, very, very few people use, they should REALLY start with WebUSB.

Reply on news.ycombinator.com