Please make your products work with URLs

Trusted with your viewing history? With a trivially regeneratable netflix password?

I like keeping privacy private, but I'm having a hard time imagining what sorts of private data you are concerned with that would be going over a set top box.

Or were you more worried about the STB being an attack vector into your home and other machines?

> Here is my plea: when you build hardware/software, please make it support the primitive, simple case.

The OP is arguing that the primitive, simple case for this page is to not use any javascript because it's unnecessary for the core functionality of this page. The content here can be displayed simply as a few kilobytes of raw HTML.

Much like the author assumed that javascript is most primitive & simple functionality for internet users, the people who built his TV, assumed that chromecast protocol is the most primitive & simple way to send a video link to the TV.

> anyone who browses that way should expect that many sites won't work and will need to be manually whitelisted.

I never whitelist sites that don't work without JS unless the site is actually critical for some reason (doing so is too risky). I expect that this means some parts of the web effectively no longer exist for people like me, and accept that, but I wonder if the authors of these badly engineered pages really know that they're excluding people.

Author here. Sorry for those having trouble viewing the site. That's obviously never the intention. The current incarnation is actually a bit of an experiment. Unfortunately, my blog is only occasionally tested against front page traffic so I don't always get a feel for what's not working.

That said, I assure you I am intimately familiar with the tradeoffs of different methods of delivering HTML. TL;DR it's my personal site and I'll do what I want with it. It's for fun. The previous version of this site used a static site generator I wrote myself[0]. I switched to client-side JS rendering for several reasons.

First, having a build step creates a dependency on both the build tool and a specific action. If you clone my blog[1] (with submodules) you should be able to host it exactly as-is from the repo. No build step required. I hold a fairly extreme view[2] on dependencies.

Second, I wanted user interactions within my site to be very fast[3]. After the initial load, subsequent navigations are much faster (and consistent) than retrieving a new static HTML page. Obviously once the HTML is cached that's no longer true, but I'm optimizing for first-time visitors. Though I should give more consideration to the fact that most of you are only going to look at the one linked page.

Also, I plan to eventually add some quirky little things to the site which require maintaining state between navigations. For example, I thought it would be fun to integrate a little 2D adventure game with a character you can move around to scroll the content.

EDIT: I should also acknowledge that while I defend the use of JS on my site, I concede that supporting non-JS use cases would be far more true to supporting "the simple case" as fallback. Simply supporting browsers in the default configuration isn't a very high bar. Browsers are incredibly complicated VMs. I would actually argue that my text-heavy content should be accessible via curl, like my other[4] projects[5]. I've never tried making a site browseable with curl before. That might be a fun experiment.

EDIT2: should be working now, with a link to the raw content on GitHub, per danShumway's suggestion (thanks Dan!).

[0] https://github.com/anderspitman/assg

[1] https://github.com/anderspitman/anderspitman.net

[2] https://anderspitman.net/11/dependencies/

[3] https://anderspitman.net/13/64-ms/

[4] https://patchbay.pub/

[5] https://emauth.io/

I don't believe I've ever, once, in my entire history of browsing the internet, come across a direct hyperlink to a video file to play in the browser.

Virtually universally, videos are embedded in webpages, and occasionally a link is provided that downloads rather than plays a video.

So I think this is just a use-case issue: the average user is exceedingly unlikely to ever want to watch a raw video file specified by a URL, because you just don't come across them in the wild. So therefore Roku didn't build that feature.

And that's 100% justifiable for a consumer product. There's no philosophical reason why a consumer product should support computational primitives like URL's or files when the use case is rare or non-existent for the target market.

I mean, if this were a command-line utility then it would be a different story... but it's not.