No, this is very much an HTTP thing. When you request a resource over a URL, you should get the resource... instead with their site you get an HTML page with a bunch of javascript includes... that then retrieves content. It works, but it is opposite of what they are arguing for.
Now, this is this person's personal site... they can do what they want. But it's pretty ironic to put a rant about working with URLs on a site with a design like this that doesn't work with simple URLs.
The URL does work. I don't say anything in the post about reading what's on the other end. What you're saying would be like if I had said in the article that I should be able to give the Roku a video format it doesn't support and expect it to work. My website should work for anyone using a browser with default settings. I never claimed it was a static HTML site. It's an interactive JavaScript application.
I feel like you’re arguing for two completely orthogonal ideas. Either you get the resource with the request or you don’t.
The resource you get with your site is the same thing regardless of what the URL requested is. There is then JavaScript logic that loads more information based on the path. The content is then dynamically added to the DOM. This is how your site works, right?
In this model, you never actually get the content with an HTTP request. You get code that runs that contains/displays the content. From the HTTP point of view, the resource is the code. If you don’t execute the code, you don’t get the content.
This is a perfectly fine way to run a website. I have zero issues with this. And as you say, this ship has largely sailed.
But — what you are asking for in your post is the ability to hand a URL to a media player and have that content play. What would happen if the content site had the same setup as your site (without any special configuration like supporting YouTube URLs, etc)? What is the HTTP request returned a JavaScript wrapper around everything and not the actual video?
The Roku could very well support a video format and still not be able to play the content on such a site. And the kicker is — a web browser would probably work just fine and the user would have no idea why their URL wasn’t working on their TV.
This is why there have to be tools to extract YouTube videos to download. For sites like YouTube, the URL isn’t a simple resource locator. It’s a link to a bunch of code that needs to be run to get to the video.
What I think you’re missing is that it isn’t just the client authors who need to support URLs, but also the server authors. If you have a small local HTTP server that just sends raw files, that’s easy. But loading something like YouTube isn’t as simple as supporting HTTP requests. And there is a certain irony in publishing a post that asks for clients to support working with URLs on such a site design.
JS vs pure data (a video file) is an important distinction. I will grant you that. My point is that it's perfectly reasonable to assume users can access this blog post just fine (and my analytics show that is the case for the vast majority of them), because the functionality is built-in to every browser on the planet. You literally have to take action to circumvent the way your browser is intended to work, in order for my site to not work.
That's exactly my point. It's a website. It's meant to be consumed by browsers, so it's fine if the served resource is a SPA that renders the content lazily or whatever. The claim that SPAs somehow violate HTTP seems weird to me.
FWIW I actually agree with the underlying principle. It's just that I have specific things I'm aiming for with my site that require JS. I wish browsers were simpler. But that ship has sailed. In my perfect world, the JS-app functionality of browsers would be broken off into a separate "app player" application that users would download, and browsers would be stripped down to basic HTML and a subset of CSS (essentially fonts, colors, and flexbox). In that world I would definitely have an HTML-only version of my blog.
