> Here is my plea: when you build hardware/software, please make it support the primitive, simple case.
Says a webpage that is just a couple empty divs w/o JS, and, with JS, is 4 hyperlinks, a few paragraphs of text, and absolutley nothing (aside from google-analytics) that ever needed any JS in the first place, let alone 5 or 6 files' worth of it.
But, I think that conflict really speaks to the funamental issue, here: Thinking about the primitive, simple case is often, from the creator's perspective, more work than it's worth.
Yep. Your reasoning is valid, and further illustrates my point: From your perspective, pasting a URL to some media is a really basic use case. From mine, a stripped-down browsing experience is. The common element is that, no matter how simple and straightforward we think our preferred way of doing things is, it's still not particularly interesting - and therefore not particularly worth worrying about - to someone upstream.
I mean, if you're going to wax lyrical about how what your making should support that basics, you should at least first make sure you're doing the same thing.
Otherwise, you're just demonstrating exactly why Roku doesn't have a way to input a URL to play media.
JS can be a highly supported tool, but it isn't itself a primitive use-case. It is an enabler of use-cases and, to OP's point, JS for the sake of loading JS isn't useful if the content of the site really didn't need it.
The very purpose of JavaScript is to be dynamic and changing. "Primitive" and "Basic" are not apt adjectives, especially when the page in question is entirely static.
Says a webpage that is just a couple empty divs w/o JS, and, with JS, is 4 hyperlinks, a few paragraphs of text, and absolutley nothing (aside from google-analytics) that ever needed any JS in the first place, let alone 5 or 6 files' worth of it.
But, I think that conflict really speaks to the funamental issue, here: Thinking about the primitive, simple case is often, from the creator's perspective, more work than it's worth.