Please make your products work with URLs

That's great and I hope you keep on doing that. That said I have a few comments on your actual implementation.

> If you clone my blog[1] (with submodules) you should be able to host it exactly as-is from the repo.

Who would want to do that? Somebody interested in running your website is probably somebody also willing to install and run a build tool. And even if not, if it's just about consuming the contents of your website without visiting your website, the Markdown in your git repository is accessible enough.

> Second, I wanted user interactions within my site to be very fast[3]. > [3] https://anderspitman.net/13/64-ms/

A noble goal, however the initial load time from a cold browser session was consistently between 3s and 4s for me. Probably because you got hit by HN, but looking at the network tab reveals why a statically generated page would've been way faster: Instead of loading 19 resources, you could've simply loaded 3 (HTML, CSS + Favicon). That'd have been significantly smaller and faster.

> After the initial load, subsequent navigations are much faster (and consistent) than retrieving a new static HTML page.

As already mentioned your initial page load would've been significantly faster with a statically generated page. What you do is optimize for subsequent page loads at the cost of the initial page load. I can only speak from my own experience, but I also believe this is true for most of the HN crowd: I usually end up on websites like yours, because somebody links to a specific article on it. I then read such an article and close the website right afterware. It's very rare that I look around what other content is available on such a website. So I don't know how your usual website visitors behave, but I'd assume visitors which actually visit more than 3-4 articles on your page a probably relatively rare and for such a few pages the sum of loading times would be shorter than your premature optimization.

However if you want to optimize for subsequent page loads I suggest you do so without compromising your initial page load and completely without JavaScript by utilizing link prefetching [1] which is supported by all major browsers [2] except Safari.

[1]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefe...

[2]: https://en.wikipedia.org/wiki/Link_prefetching

EDITed to be less inflammatory.

They'd probably make the point that most user-video content is on Youtube or Vimeo, and that for most users there really isn't much need for a non-app solution.

They'd probably make the point that Roku is designed to fit a particular user, not to stream arbitrary content, that it's not trying to be a be-all-end-all streaming solution for everyone.

They'd probably make the point that a URL system wouldn't allow them to support cool app-streaming-specific features like resuming play between devices, or social features like comments, or suggested content.

And they'd probably tell you that of course they considered supporting URLs, and of course they considered the tradeoffs, and ultimately it just wasn't worth it.

I have no doubt that the number of people who want to use URLs with their TV are a minority of the market. Almost certainly not as much of a minority as people who disable JS (that's a tiny sliver of traffic that mostly just hangs out on tech forums like HN). But probably not a high enough market segment that it makes financial sense for a Roku or Chromecast to expend a lot of time adding support.