| 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. |