Comment by nashashmi | Hacker News Reader

Comment by nashashmi | Hacker News Reader

The people who use these features are busy using these features. And they are not part of browser development. So they revolt in a nasty manner. Like when ftp was torn down.

It is nice to see workarounds. But those workarounds are not conducive to HTML purists who do things without JS. They are the real web developers. They have always relied on the browser to improve and become faster but not start abandoning old technologies.

Chrome OS also became popular on this point that a browser can do things like being universal viewers and so the need for programs goes away. There are so many lite OS who are also using the browser to do everything.

Now I understand that the web has failed XML and XML failed the web in favor of JSON. I also whole heartedly believe that XML and XSLT can do so much more for the web and do this natively.

But open systems are not in the interest of the big FAANG and Microsoft ecosystem. They abandoned RSS. They abandon APIs on a regular basis. And this turn of events is causing browser vendors to start developing for big companies rather than open indie developers.

There is much gain from XML and XSLT. But I want to see a specific development. I want to see XSL import an XML. I want to see the reverse. XSL will be the view. XML will be the model. And the browser will be the controller. MVC paradigm.

> HTML purists who do things without JS. They are the real web developers.

I don't think using one set of technologies as compared to another one can really be said to make one a "real" web developer. Real web developers are developers who put sites on the web, there is no benefit to anyone to be had claiming one choice is "real" and therefore the other choices are lesser-than.

Put it this way: whatever set of constraints you used to arrive at that decision does not apply to every situation, and when you frame things through the lens where you implicitly disregard that oh-so-obvious truth, it's hard for anyone to interpret your analysis as anything but myopic in the best case and actively self-serving and destructive in the worst case. It's nearly impossible to read through someone speaking this way about a topic and believe their analysis is objective, comprehensive, or without obvious bias, even if it may actually be all of those things.

> Like when ftp was torn down

FTP needed to be torn down. It’s sad, but true. There was no reason for anyone to be using it past 2010 - and in fact many reasons actively against using it

It was a quick way to share files. FTP as an internet application made a lot of sense. The only counter reason was it did not have password protections like SFTP did, and did not support encryption. But that is like arguing against HTTP in favor of HTTPS.

I don't think they put SFTP in browsers yet.

There was FTPS (FTP+TLS). Not sure if browsers ever supported that but I imagine it’s not too hard to implement iv you have HTTPS already.

I have yet to find a website which pleasantly lets me download a bunch of things in an efficient and organized manner that compares with FTP. The hilarity of buying a Humble Bundle and pressing "download all" and watching your browser spam "save as" windows for a minute and a half...

I kinda wish I could (S)FTP a lot more things than I can today.

Wget? Like this isn't a protocol issue but a website issue. You can do this sort of thing with http just fine.

Can you POST with wget? wput? I should know this...

The comment i was responding to was about download not upload.

Certainly though you can do multiple upload on a protocol level in http (resumable upload less so)

Afterall, S3 clients are all http under the hood, and that is basically the defacto standard now.

There certainly exists features in ftp not present in http, but they were rarely used/bad ideas (hello server to server transfer)

FTP was not torn down just because some web browsers stopped also being FTP clients. You can still use any FTIP client with any FTP server that you want.

But it was torn down from the browser. That’s what we are talking about with respect to XSLT

Firefox and Chromium had in-built FTP protocol handlers. I believe extensions could depend on this in such a way that the removal might break things for them, but general web content couldn’t—it was just an external link.

Safari and IE didn’t have integrated FTP: rather, they could hand FTP links over to the OS for something outside the browser to handle.

Now Firefox and Chromium can hand FTP over to the OS too.

XSLT, on the other hand, is integrated, a true part of the web platform. XSLTProcessor on any page, <?xml-stylesheet?> on XML files loaded directly… it works everywhere. The case is quite different from FTP.

If they remove XSLT, this will be the first time a major baseline-available feature has been removed. (One or two minor features have been removed: SharedArrayBuffer was temporarily dropped very shortly after landing across the board, for solid security reasons, taking up to 4 years to return with suitable limitations; and mutation events came in 2011 before quickly being replaced with mutation observers in 2012–2013, finally being removed in the last year or so; and the unload event which has been known to be unreliable and a bad idea for at least a decade is in the process of being removed. But all three of these are likely to be very minor in their effects, where XSLT removal just breaks your entire page.)

Reply on news.ycombinator.com