I think he misses that storing HTML and having a webserver turn this into HTTP responses, might be exactly the storage format that solves this problem.
Worth noting that the incoming younger generations can't and don't into file systems.[1]
Yes, anyone who wants to be a webmaster should do their homework, but that is besides the point.
We are probably the last generation who can be ubiquitously assumed to have an understanding of files and folders/directories in a computer.
[1]: https://www.theverge.com/22684730/students-file-folder-direc...
It takes me a minimum of 60 seconds to naviate to ~ using the GUI on my work laptop.
(Partially because the dialog box sucks, and partially because I only do that once every 6 months or so.)
It's like some UI designer didn't understand folders, then somehow forced their brain damaged mental model of them on the rest of the population. After that, for some reason I will never understand, the rest of the industry copied the design.
(I've worked on filesystem implementations, tested for POSIX compliance, debugged insane customer issues, etc, etc. I know how directories work...)
Which OS? For all its flaws (and there are many related to this issue, like overzealous hiding), macOS lets me add ~ as a 'Favourite' which then shows up in file choosers as well as the main file browser app.
He probably didn't.
For everyone else, who cares? Search is so good that it doesn’t matter where a file lives on your device. They don’t need to understand the internals of how directories work.
Good riddance! Even though people knew how to use files and folders no one did it well. It was a mess of “new directory” and “copy of copy of essay5.doc” I’m so thankful that most folks don’t have to deal with that anymore. They can use their computers instead of fighting them.
If you’re someone who likes working with the filesystem directly, why? Seriously why? It really does seem like anything would be better.
Even for code, wouldn’t you rather things like Python modules or packages be first class objects? No more sys.path nonsense, no more namespacing, just your whole venv in a single trivially relocatable file.
Being able to understand where your data is located in a computer and knowing how to manipulate them makes a lot of subsequent data management easier. For one, a file system is independent of any given piece of software. You don't need to rely on your word processing program knowing where your documents are, you can just tell it where your document is. You don't need to wrangle with sending a picture from your Photos program to your email program, you can tell your Photos program where to save the picture and you can just tell your email program where your picture is.
And did I say picture? Is it a JPEG? PNG? GIF? An abstraction of the file system won't tell me, but if I go look in the file system I can immediately tell what the picture is, and where it is too.
And like I just alluded to, you get to decide where the files reside too. Your Photos program might stuff all 6000 of your pictures under "C:\Program Files\VendorMcVendorface\Photos\userdata", and sure, that works, but that's nonsense. You could sort everything exactly how you want it where you want it. "C:\Photos\2006\Yosemite" for just all the pictures you took on a trip to Yosemite National Park in 2006, for example.
Admittedly, it's a feat that file systems have been successfully abstracted away for Joe Average, but not knowing how to navigate and use file systems is going to bite you in your arse when something inevitably comes around demanding you do it.
Understanding file systems is one of those bits of knowledge and wisdom in life you can do without, until you can't. And by then, you don't have time to call for a time out and get a crash course on it.
[the author here] The article is not about misunderstanding file-systems.
As I've commented earlier on a different thread, <https://news.ycombinator.com/item?id=32733825>, the problem is that when it comes to performance and jumping through the hoops the internet gatekeepers (i.e. the search engines) have set out, just dropping some files somewhere the web-server can pick up isn't enough; there are additional tasks that can't be easily performed with files-on-the-disk approach.
I linked it here because, with regards to "already standardized the hosting side of static sites by using the file system", it means squat if the webmaster-to-be doesn't know what a file system is. There's no preconception of using files to hold and serve data from if you don't know (and possibly don't care) about file systems.
If we're going to be discussing attempts at changing the paradigm, then it stands to reason to understand the environment at large that might be encouraging it. If we're going to be talking about something replacing file systems for data storage, it's pertinent to know first of all that the younger generations give zero bits about files.
Also, SEO is at best a tangent to data storage and serving. Some webmasters might not even care to bother with SEO if they don't care about search engine rankings.
The most familiar computer to young people, their smartphone, does everything to hide and abstract away the file system and even the fact that it's a computer.
When someone doesn't even realize a concept exists, it shouldn't come as a surprise they will struggle.
1. I’m lazy, and I already manage a bunch of other stuff in AWS, so it’s convenient for me to have the domains in the same place
2. For some of the domains, I’m serving records that point to other AWS resources (like Cloudfront and S3). AWS’s Route53 has clever helper features when you’re pointing records at other AWS services).
Otherwise, you’re right that there’s plenty of registrars that’ll do perfectly solid DNS
But it's true that cloud providers have that solved, and "DIY" bring-your-own-server don't, and the article somehow concludes that bringing your own server with the right configuration is not an option.
[the author here] On the contrary, it is an option to fine-tune your web-server configuration to put all the right headers in the right places. (I usually do this from HAProxy and just ignore the web-server.)
However, the point I was trying to make in the article is that where these headers are configured is divorced from the content itself lives. I can't look at a HTML file and easily say "when the browser will hit this resource these are the HTTP headers that will be sent in the reply"; I need to execute in my mind the web server configuration logic to get that.
Thus my proposal is to move back (some of) the headers where they belong: as meta-data right besides the actual resource.
Also if you use CloudFront be aware you'll be paying for bandwidth, so if one of your pieces goes viral (or you're just a popular writer) the cost can be surprisingly high (over $50/mo).
But then it turns out that this is actually pushing folks towards some new paradigm of static cached HTTP responses instead of files. It pitches this as an attempt to “standardize the hosting side of static sites”, which doesn’t pass muster for me. We’ve already standardized the hosting side of static sites by using the file system. Shifting to a new storage format besides “HTML on disk” doesn’t unify anything, nor does it seem desirable to have fewer options for serving content.