We need a protocol for file transfers because having a protocol makes it more standardized and interoperable than if everyone rolls their own solution.
Do we need browser support for it? It still happens now and then that a link will have an ftp target. That could be handled in the browser or it could open a separate url-handling application, as e.g. email or magnet urls do.
Yes, but as someone who's been around when FTP was a big thing, and HTTP only just came into fruition... what, really, is the benefit of FTP? In fact, FTP is actually a horrible protocol, that caused me much pain even back then:
It uses separate "command" and "data" channels. The data channel is usually in the other direction, i.e. the client listens to a connection from the server when downloading a file. Passive mode, and an extra command for that, had to be implemented, and if the stars don't align right, it still ends up being a pain.
FTP also used to default to 7bit. If you did not explicitly switch to 8bit mode, you got corrupted downloads. This maybe made sense in a world with fundamentally different encodings, line endings, and where connection speeds were slow enough that downloading text files was a big task, but now?
Then, if I remember correctly, the file listing you got was not actually standardized, it could just be the output of the "ls" command on the server! FTP clients used to be dumb and just passed that output through to you, so it did not matter much. For smarter clients later, it did start to matter.
Finally, what does FTP actually offer that, in most cases, HTTP, and, in niche cases, rsync, scp or sftp do not offer?
This is not a bad thing in itself. It could enable you to download each file from a different, potentially better endpoint, while talking to the same server for coordination. It's just not the way we do it these days anymore - 3xx and anycast/CDNs solve that one to some extent. And NATs destroyed that idea being usable years ago. It's still fine in protocols like sip.
Yes. Just like the text conversion thing, or the non-standardizes file listing thing (not everything was UNIX-ish, VMS was still around), at the time it made sense. Today it's just clunky hindrances, and the protocol has lost its benefits.
I would argue, that separate control/data channels makes protocol more secure. You can't sneak commands on data and you don't need worry, how do terminate data transmission and switch back to control mode.
FTP is basically useful as a single-use protocol: file transfer only. File transfer only allows a more stripped-down, dedicated server with better security. Vsftpd and others have excellent security specifically tailored to permission-based file transfers with access control lists etc. You will rarely find a comparable http option. It's not perfect, but there are also good partes and reasons why it's still around. Secure FTP is still a good option for some cases.
As written in another comment, you will find FTP to actually be a truly horrendous protocol, at least from today's perspective. I'm not sure there is anything that FTP offers, that the rsync or sftp, for example, offer much better (or simply HTTP if it's only in one direction), and then some.
SFTP is actually not just FTP over SSH. The protocol is different precisely to get rid of a lot of the outdated nuisances.
FTP became a nightmare to use thanks to introduction of NAT, it was developed before NAT existed so it wasn't designed with it in mind.
As for rsync, sftp, scp those are heavily tied to ssh, rsync to the point that you actually ssh to host and call rsync command. rsync has a server mode as well, but almost no one uses it.
Yes, there are lots of issues with FTP. I've worked with it, and it is in many ways a nightmare.
That aside, you can use FTP for auth and ACL in of which HTTP and rsync just aren't capable. I'm not sure this is a flaw in the core protocol so much as the tooling, but there you have it. FTP config syntax may often be byzantine. But it's widely supported (especially on old, low-spec, or embedded devices). For newer stuff, yeah sftp is probably better. But it's still got its uses.
And that’s also why SFTP is slower than FTP: because it’s a separate protocol implementing its own windowing which interferes with TCP’s, thus performance goes down the toilet when using SFTP over a high latency connection.
Whole solution and experience is different, even if some point uploading file by bytes over TCP is similar. HTTP server itself isn't solution. You need code implementing upload functionality, probably support for uploading many files at once and tracking progress. Now you client uses javascript and that client is remote, you need to "download" it from HTTP server. FTP client is small, local and don't have much overhead, HTTP with its stateless form needs headers retransmitted with every request.
Indeed, but your question wasn't about Chromium ftp support.
Note, I am not lazylizard, so I don't really know, what he meant by "Ftp is fast", but I have my own thoughs and general dislike to webify everything on internet.
Do we need browser support for it? It still happens now and then that a link will have an ftp target. That could be handled in the browser or it could open a separate url-handling application, as e.g. email or magnet urls do.