
Please make your products work with URLs - anderspitman
https://anderspitman.net/16/please-work-with-urls/
======
jchw
I hate smart TVs with a burning passion. They accomplish literally the bare
minimum to keep people happy and sometimes not even that.

Samsung’s Tizen OS is the most genuinely frustrating experience I’ve had with
a consumer device outside of printing. Advertisements on my home screen that
can’t be disabled, dubious privacy, bugs that require me to reboot my TV, and
of course security so bad that they recommend installing a virus scanner?
Yeah, that’s great. It’s got a web browser at least, though that’s the only
positive thing I can really say about the web browsing experience.

Can it run software? If you can find it! There’s no app ecosystem here, just
the big apps it absolutely had to have to be worthy of shipping. If you want
to watch Twitch.TV streams for example you are SoL. There was an unofficial
Twitch app, but it was removed from the store.

I tried to set up development for Tizen. Yeah not gonna try that again. I
always thought getting started with development on Android or iOS was a little
cumbersome but it really doesn’t compare. Even getting into developer mode was
challenging since I had trouble finding the instructions that were pertinent
to my model of TV, and that was the last thing I accomplished successfully.

So I’ve got a desktop computer hooked up to my smart TV and now I am
contemplating paying more for a TV so I can get one that doesn’t have any of
this dumb crap on it. The only downside? You can’t really run many 10 ft
versions of things, and there’s not many good casting solutions. Lame, but
every time I run into a new pathological case with the TV OS and its set of
subpar apps I reconsider how much it’s even worth to have fancy 10ft
interfaces and smart phone integration.

(If you are looking for a casting solution for an HTPC running Windows, I
tried Reflector 3 briefly and it looks pretty good. But I personally do not
run Windows on my _own_ HTPC, so I’m stuck in the dark.)

~~~
zeta0134
I've long since run with the notion that if you must have Smart TV features,
do it with an external box. Last time I checked the Roku devices were decent
for this, but there's a bunch of alternatives, and some lovely FOSS stuff
(Kodi comes to mind) that is much more privacy focused.

The TV itself is a black box of mystery, and does NOT get to go on my network.
It doesn't need my wifi password, and I certainly don't want it sending
screenshots of my desktop (with sensitive information) off to some advertising
agency. No thank you! But far more importantly, the TV will last for _years_
as a dumb monitor, and the external box is usually much cheaper, and can be
upgraded and secured separately. This just feels like the correct model.

~~~
tzs
> I've long since run with the notion that if you must have Smart TV features,
> do it with an external box

I'd go farther. I want _everything_ to be external boxes. Right now I'm
looking at having to get a new A/V receiver because mine cannot handle 4K
video. It does all the audio stuff I need just fine.

If video switching and audio processing was handled by separate boxes, I'd
just be looking at changing out the video switching box.

Now suppose that later I decide I would like to be able to control my receiver
with Alexa or Google Home. As it is now that will be another "replace the
whole damn receiver" moment. If it were all separate boxes, the preamps, amps,
surround sound processor, and radio receiver would all be separate components,
controlled by a controller box. If I decide I want Alexa, I'd just buy a new
Alexa compatible controller box.

Or I decide I want to upgrade from 5 channels to 7 channels...buy a couple
more amp boxes and speakers for the new channels (and might also need a new
surround sound processor box).

Basically, take a block diagram of a complete full featured home theater
system, and make every block in that a separate box so I can (1) just buy the
boxes I need for my system, and (2) upgrade a box at a time.

That said, I doubt TV makers will ever stop primarily making Smart TVs. A
Smart TV can function as the only component of a home theater system. Someone
moving into their first apartment after school, say, wanting to start putting
together their entertainment system can start with a Smart TV, stick it on
their home internet, and then use the Netflix/Prime/Disney+/etc app on the TV
to watch movies.

That Smart TV probably has a few HDMI in ports, so they can also use it with
the cable box if they have cable, and with their gaming consoles.

With a dumb TV they'd need the TV, and they would need an A/V receiver, and
speakers, and something to run the Netflix/etc. apps. Buying all that at once
might be a budget buster for someone starting out.

By making the TVs smart, the TV makers greatly increase the chances that a TV
will be the _first_ component bought for a new home theater setup, and
probably also increases the chances that that first TV will be a big screen,
high resolution, high quality display model.

~~~
satyrnein
20 years ago, I was making the same argument about desktops vs laptops. I was
also carefully selecting which stick of ram to buy. Now, the whole world buys
laptops, except for gamers and linux users. I don't think non-enthusiasts want
to think about that many boxes and arrows.

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

~~~
jschwartzi
Before Youtube this was a thing, just as streaming radio was a thing before
Pandora. You'd get a URL and the URL would stream radio or video instead of
being a website.

Obviously the protocol descriptor would be different from HTTP/HTTPS.

~~~
Izkata
It wasn't even just "a thing", it was the main way to share video on the web
before youtube made flash players ubiquitous.

------
pba
Maybe this was the whole point of the author's post.. but I'm fairly certain
the reason the author's use case is not easily workable is because the OEMs
mentioned are deliberately discouraging the ability to play anything that is
not inside some sort of DRM control. They don't want you to just be able to
play any URL. Its not a technical problem, its a content management problem.

~~~
valiant55
When I first bought a Chromecast I was disappointed how much of a pain it was
to play content I already had on my computer. I shouldn't have to spin up a
Plex server just to get acceptable streaming capabilities.

~~~
lozaning
The VideoStream chrome plugin is spectacular for this. Of all the chrome
plugins I've installed over the years, this is still the only one I continue
to donate towards.

[https://getvideostream.com/](https://getvideostream.com/)

------
ryanbrunner
I have a love / hate relationship with Chromecast.

When it works, it works well, and it is nice to just press a button and
whatever I'd like to use is up on my TV. It does feel a little magic.

But even when you're using compatible tools / devices that _should_ work
together, sometimes they mysteriously don't, and there's absolutely no way to
know what's going wrong. Approximately 25% of the time, my Chromecast device
just doesn't seem to exist according to my computer. Both my computer and the
device have network connectivity, but there's just no ability to cast. I'm
reduced to randomly restarting things in a vain hope that things will work.

~~~
Spivak
The intermittent connectivity problem might be the result of a chatty network.
mDNS is really sensitive to this and clients don’t wait very long before
deciding that they got all the responses from devices.

If you stick your Chromecast and your phone in their own broadcast domain I
think the problem would disappear. Unfortunately it’s not a solution to
whatever is spamming your network but it would tell you that that’s the
problem.

~~~
coda_
Any suggestions on how to determine what is causing the chatty network?

~~~
namibj
Wireshark should help. Otherwise, it's a pretty open-ended question.

------
dewey
Apple TV and VLC works exactly like that, I use it all the time.

1) I copy some URL on my phone or computer

2) I open the VLC app on my Apple TV and select the URL field

3) My phone buzzes because it recognizes an input field

4) I paste the url and press play

The nice part is that you can also use that to watch Acestream content if you
run some Acestream container on your NAS / Computer exposed via a http proxy
and just paste that URL into VLC on the TV.

------
deanebarker
I wrote this five years ago, and it actually made from the front page of
Hacker News back then.

"We Suck At HTTP"

>"We have broken HTTP. We’ve done it for years in fits and starts, but apps
have completely broken it. HTTP was a good specification which we’ve steadily
whittled away."

[https://gadgetopia.com/post/9236](https://gadgetopia.com/post/9236)

~~~
anderspitman
This is a great post. Thanks for sharing.

------
egdod
Please make your stuff work without JavaScript.

This is a simple text-only web page (in courier new ffs) and it refuses to
load with JavaScript disabled. There is no valid reason for this.

~~~
anderspitman
Please see my explanation here:
[https://news.ycombinator.com/item?id=22038862](https://news.ycombinator.com/item?id=22038862)

~~~
zzo38computer
One possibility is to fix it so that there is a <noscript> block which
contains a link to the Markdown source (or if the way it is set up makes that
difficult, instructions for accessing it). I highly suggest doing this if you
do not want to prerender it on the server. (I saw another comment which
mentioned the Markdown file, and was able to read it from that.)

~~~
anderspitman
Done

------
throwaway55554
Please render your markdown on your server and not my client. You're wasting
my battery, man. Shame on you!

~~~
manicdee
Quite the oversight for someone wanting TV manufacturers to lift their game
huh :D

------
kelnos
Yes, please. I was at an Airbnb in Austin last week, which had a Roku device
attached to the TV. I usually bring along a Chromcast (or at least the proper
adapters to get HDMI out of my laptop) when I travel, but this time I forgot.

I just wanted to play a video file I had on my laptop. I googled around, found
that Roku appears to support DLNA, and tried to use Universal Media Server on
my laptop. The Roku did find the media server, but kept claiming that there
were no files available. Not sure if it was a video format issue (main-profile
h264, ac3, and mkv are listed as supported by Roku) or something else, but at
the end of the day I just couldn't get it to work, and I was bummed and
frustrated.

Maybe play-this-URL functionality wouldn't've helped, but at least I would
have felt more confident that it was a format issue rather than just some dumb
problem with the huge DLNA tech stack.

------
jxramos

        HTTP is the lingua franca of the internet.
        When you build stuff, please make it work with simple URLs.
    

Can't argue with that can we?

~~~
droithomme
Or even alternatively "When you build stuff, please make it work with HTML."

~~~
zzo38computer
When you build stuff, what to make it work with depend what it is, I think.
HTML is not suitable for all uses, and URLs is not suitable for all uses, and
PNG is not suitable for all uses, etc.

------
SnowingXIV
Please make your stuff work with reader view.

~~~
anderspitman
Please see my explanation here:
[https://news.ycombinator.com/item?id=22038862](https://news.ycombinator.com/item?id=22038862)

------
cookiecaper
I have two standalone Rokus that are a major PITA because of this. There's no
way to connect to an NFS share, SMB share, or other local storage directly
from the system itself. There's no VLC app for Roku. The best you can do is
use the rudimentary "Roku Media Browser" to page through a DLNA server, which
means you have to set up either something like Plex (which sucks for a lot of
reasons) or at least miniDLNA to access files. It's really disappointing.

I've recently installed Jellyfin and even put the Roku in "Developer Mode" so
I could install the Jellyfin Roku app from GitHub. This is better because
unlike Plex, it won't transcode arbitrarily, but it's far worse because the
Jellyfin Roku app crashes frequently, has only basic page-based navigation
("go to page 23 for media that starts with 'T'"), and it requires running a
heavy media server for no real reason. I'm still reluctantly using Plex for
the time being.

When I need something that I haven't put in Plex, I fall back to the Android
interface on the FireTV and use VLC to access the NAS over SMB. It still
rankles that Roku won't allow an easy way to access local media.

------
kbenson
As of at least 5-6 years ago when I was doing independent development on the
Roku there have been apps/channels in the Roku channel store that can
accomplish what the author is trying to do, and many for free.[1] Perhaps the
author should have looked into the applications that area available?

1:
[https://channelstore.roku.com/browse/apps](https://channelstore.roku.com/browse/apps)

~~~
anderspitman
I tried. The point of the post isn't that solutions don't exist. It's that I
couldn't find one before I had to give up from time constraints.

------
cronix
My 70" Samsung TV is just being used as a dumb monitor. It's hooked to a small
windows 7 HTPC box. I use Media Center to get my DRM cable using $1.50/month
cable cards from the cable company (comcast), so don't need to rent their
equipment (except the cheap cable card). I can play 100% of everything and
don't have these "smart tv" issues. Skip the smart tv stuff and just use it as
a dumb monitor. The TV isn't even hooked to the net. No update notifications,
ads, or anything else. Everything works seamlessly with macros on a single
Logitech remote that is now about 7 years old. I love this setup. I can access
anything from anywhere in the house on any device and it always "just works."
It has been for many years. Recently MS ditched their program guide, which
sucks, but there are alternatives that make it work and hopefully live on
another 10 years.

------
blackhaz
Or is it the general trend of moving away from the centralized Internet, the
force of deglobalization? Instead of upholding standards and cherishing RFCs
it seems that so many people and corporations are trying to invent the next
protocol, the next flow, often poorly documented and proprietary. Even Linux
is proud to be not Unix. I know, it has never been, but we can remember times
when READMEs had lists of supported operating systems, and stuff did compile.
Everyone's excited about ARMs and non-Intel stuff. I don't mind diversity, but
it feels almost like celebrating fragmentation. I wonder if we are heading
towards something like a pre-Internet era, with CompuServes and Prodigies,
incompatible formats, with countries investing into their own future
independent and incompatible architectures?

------
MattyRad
I think there's some hypocrisy on the author's part:
[https://anderspitman.net/txt/feed](https://anderspitman.net/txt/feed)

> If your browser was redirected here, it's because you have JavaScript
> disabled. To navigate the text version, simply paste one of the following
> URLs into your browser, or the entire cURL command into your terminal. If
> you're looking for a specific post, check the list on the Feed page.

------
jefftk
I think it should be possible to do this with the browser and the Chromecast
protocol, since my understanding is "play a video from this URL" is the core
of the protocol. Someone could build a website following
[https://developers.google.com/cast/docs/chrome_sender/integr...](https://developers.google.com/cast/docs/chrome_sender/integrate)
where you paste the URL of a video and are given the option to "cast" it to
the TV.

This would be some work, but only one person would need to do it and then
anyone could "cast" a URL.

(Disclosure: I work at Google, speaking only for myself)

~~~
rahimnathwani
Right, someone already built it :)

[https://chromecast.link/](https://chromecast.link/)

~~~
bruckie
It looks like
[https://play.google.com/store/apps/details?id=com.rabidgreml...](https://play.google.com/store/apps/details?id=com.rabidgremlin.web2cast)
may be the equivalent in Android app form.

~~~
rahimnathwani
Does it work with videos? The product description mentions HTML and static
image formats. Neither the description nor any of the reviews mention videos.

I guess I could just spend 99 cents and 2 minutes to find out...

------
reggieband
> However, there doesn't seem to be any widely implemented standard for
> playing plain URLs, only walled gardens like the YouTube app.

I've had experience overseeing the implementation of a simple Chromecast
application. It was a relatively painless process and worked pretty flawlessly
with minimal code. It may not be a standard but it is totally accessible to
anyone with a bit of Javascript experience.

I could imagine an evening hack session that would be a Chromecast application
(maybe a browser extension) that you can paste urls into and it would play
that way. Without even bothering looking, I would bet such an extension
already exists in the Chrome Web Store.

------
jdblair
There's a reason that Smart TVs (and set top boxes, and streaming sticks)
usually don't allow you to load an arbitrary URL: it increases the attack
surface by allowing you to load any arbitrary endpoint on the Internet. When
you "cast" from an app on another device you are casting something that app
understands is not a generic endpoint, but reference to an object in the app's
library.

You can disagree with this reasoning. It should be possible to safely load
arbitrary endpoints and not ever execute an attack embedded in it. But then it
wouldn't be called an exploit, would it?

------
jscholes
Amen to this article. Concise and right on point. My parents have a Roku
streaming stick hooked up to their (relatively dumb) TV, but are not tech-
savvy. A bunch of times, they've asked if I know how they can watch X, and I
do. I have an HTTP URL to an HLS playlist or similar ready to go. But good
luck getting it to play it if no fancy app wrapper exists.

In the end, I set them up a Plex server, which I can securely remotely drop
things into. But that comes with its own fair share of ridiculous concerns.

------
causality0
The lack of direct video-out on modern smartphones is something I often find
infuriating. Some of them support OEM smart docks, but imagine if the only way
to output video on your laptop was a $250 HDMI cable. Sure you can cast, but
there's enough lag to make you look slightly inept if you're pausing a
presentation for a question and to make gaming impossible. Some phones support
standards like DisplayLink but in addition to being unable to charge the phone
it also generates a tremendous amount of heat and runs the phone's battery
down.

------
SergeAx
I've got the most dumb TV in the world at home. It's about 10 years old,
biggest one for sane price at the time, 50" 1080p. When I want to watch a
movie - I download it onto a thumb drive and just watch it from there, plain
and simple. When I want to watch a YouTube there for some cryptic reason - I
connect it to notebook via HDMI cable.

I feel that I soon will have to change it for some more fancy set, like 65” 4K
HDR OLED. I will make my best to dumb it down and keep using it in the same
manner. And I definitely will not connect it to the internet!

------
bhauer
Yes, agreed. In fact, I agree so much that I just use a big monitor with a
computer attached for my "living room" television consumption. It turns out
computers can consume URLs pretty well.

~~~
zzo38computer
That look like good enough, but do you have a IR receiver for the computer? If
I have to touch the TV monitor itself to switch on/off it is OK (and I would
prefer it this way rather than using a remote control, I think), but would
like to have a remote control to pause and rewind and so on.

------
X-Cubed
This is the sort of use-case that the DLNA specification was intended for.
It's not quite as simple as the author might want, but it is well supported.
The TV can act as a Renderer for content pushed to it, or as a Player for
content pulled from a Server.

All the smart TVs I've used implement this functionality. VLC and Kodi support
this too.

[https://en.wikipedia.org/wiki/Digital_Living_Network_Allianc...](https://en.wikipedia.org/wiki/Digital_Living_Network_Alliance#Specification)

~~~
pjc50
DLNA is slightly maddening because it's clearly _supposed_ to be the solution,
but was built by set-top-box UI people and therefore has terrible UX.
Basically Chromecast exists because DLNA is too fiddly for the average user.

------
mayneack
There's an android/roku app that makes this fairly seamless in all the
instances I've tried. It even does a good job of finding videos in a web page
if you don't have a direct link.

[https://play.google.com/store/apps/details?id=com.instantbit...](https://play.google.com/store/apps/details?id=com.instantbits.cast.webvideo)

[http://www.webvideocaster.com/](http://www.webvideocaster.com/)

~~~
anderspitman
Yup, that app got me really close. It even worked for about a minute, but I
was unable to reproduce the success (that was infuriating).

~~~
mayneack
Hmm, that's weird. I use it for hours at a time on most Sundays. I'm sort of
surprised how well it works.

------
peteforde
While I agree with this post essentially in its entirety, it's weird that he
didn't mention the most significant fact regarding his request: the Roku
doesn't have a web browser, and the development environment has no hypertext
primatives. To that end, there's essentially no way to browse web pages on a
Roku unless you literally render the page somewhere else and serve it as an
image. (!)

------
mongol
> However, there doesn't seem to be any widely implemented standard for
> playing plain URLs, only walled gardens like the YouTube app.

Actually, I think the standard is UPnP / DLNA. After setting up a UPNP server
I can "cast" most things from Android by using the share button, and then
choosing a UPnP app, such as Bubble UPnP. I don't know if the author's tv
supports this, but many do.

~~~
anderspitman
Why should I have to run a separate server to play a video from URL?

------
zokier
Few minutes of googling found this, and few other similar thingies that send
urls to chromecast just fine.

[http://movies.foamsnet.com/url/](http://movies.foamsnet.com/url/)

discussed at
[https://news.ycombinator.com/item?id=7365256](https://news.ycombinator.com/item?id=7365256)

~~~
anderspitman
I don't have a Chromecast. I have a Roku TV. One of the implied points of this
article is that the solution I'm suggesting would work for any device as a
fallback, let them implement whatever other fancy protocols they want.

~~~
zokier
> However, there doesn't seem to be any widely implemented standard for
> playing plain URLs, only walled gardens like the YouTube app.

But chromecast is essentially that standard you ask for, otherwise "apps" like
I linked wouldn't work. Heck, as far as I know (I'm not really a Chrome user),
Chrome has this functionality built-in, so you can send URLs directly from
browser to a chromecast device.

~~~
anderspitman
As I said in the post, I'm all for these technologies. I'm just asking for a
copy-paste style alternative for when they don't work.

------
imhoguy
VLC for Android (TV) can stream from URLs nicely.

------
dreamcompiler
Alternative solution: Build your own Roku app. Last time I checked it looked
pretty easy; set up a JSON manifest file and a bit of JS on a web server that
can also serve video, or something like that. I don't remember how easy it was
to install your app on your own Roku but I seem to recall there was a way to
do so for testing purposes.

~~~
peteforde
It's not quite as easy as you're making it sound (when it is ever?) but
BrightScript is indeed an option. However, there's no concept of an HTML
primative so everything has to be a bit of a hack. I have faked more than a
few browser-like UIs in Roku apps, and every detail has to be handled by you.
Think: offset math and debouncing key events.

------
tengbretson
Related to what the author experienced, has anyone ever actually gotten
Miracast or WiDi to work from android to a smart tv? I've tried it now on
multiple different phones and televisions and it seems to me to be completely
broken in all implementations. Am I missing something obvious here?

------
skizm
Anyone have a recommendation for high quality 4k dumb TVs that are truly
offline? I have a media center PC I plug into my TV and don't want or need any
of the "apps" or "homescreens", just give me a few inputs to HDMI cables,
maybe USB slot, and I'm good.

~~~
dewey
Can't just you just...not connect it to the internet?

That's what I do (my Apple TV is connected to the internet). A nice side
effect is that you don't get ads in the TV's home screen that way.

~~~
skizm
True, I guess I'm just worried it might hit my neighbors unsecured wifi or
somerthing. I live in an apartment complex so it is tough to monitor all the
connections all the time since people move in and out.

~~~
dewey
Don't think it would auto-connect to unsecured networks but could always set
up an offline access point and force the TV to connect to it to be extra sure.
Probably not worth the hassle though.

------
skybrian
I haven't kept up with the state of video streaming, so for me this raises
more questions than answers:

\- How inefficient is video streaming when you're downloading chunks of a
compressed, static file over a flaky Internet connection?

\- Was it worse before? Would it work better with QUIC or HTTP/3?

~~~
pjc50
Inefficient compared to what? Fundamentally you have to shift the same N bits
per second at a reasonably uniform speed regardless of how the transfer is
done.

Your main enemy in this process is, as usual, middleboxes, which may be a
bigger problem for the advanced protocols. This is why Apple created the
bizarre but effective HLS system:
[https://en.wikipedia.org/wiki/HTTP_Live_Streaming](https://en.wikipedia.org/wiki/HTTP_Live_Streaming)

~~~
skybrian
Inefficient compared to whatever optimized, adaptive, video-oriented protocols
Netscape, YouTube, and Chromecast are using.

I'm wondering how much you lose by doing it the simple way?

~~~
anderspitman
I'm assuming most video streaming is done over HTTP these days, as sad as that
is. But now you have me wondering if the big boys are using something
different.

------
emmelaich
Relatedly - see
[https://play.google.com/store/apps/details?id=com.rabidgreml...](https://play.google.com/store/apps/details?id=com.rabidgremlin.web2cast)

I saw a recommendation for it here or on Reddit recently.

------
unwiredben
You might want to try [http://devtools.web.roku.com/#stream-tester-
tool](http://devtools.web.roku.com/#stream-tester-tool) as a way to test
specific media files and streams without having to code a full channel.

------
chungy
> The way this type of thing is usually accomplished in 2020 is to open the
> video on your phone, then tap a "cast" icon and tell it to send the video to
> your TV.

Is that really typical? I just put a file on a USB drive, and plug it into the
TV to play.

------
anderspitman
Update: My site now has a text-only version, and it even works with just cURL:

[https://anderspitman.net/17/curlable/](https://anderspitman.net/17/curlable/)

Thanks for all the feedback!

------
somishere
I don't use chrome BUT I'm sure you can cast urls directly from chrome, even
from the local filesystem. A walled garden perhaps, but no need for YouTube.

------
calvinmorrison
warning: this page will not load without javascript

~~~
zzo38computer
Anyways, it has been fixed with a link to the Github source to access the text
in case you do not have JavaScript, so you can just use that.

------
Waterluvian
Smart TV's are trying to be walled gardens, no? I would love a tv that
trivially played media from an http server.

------
boutad
As a workaround, can't you load the URL in Chrome and then cast the tab or
load the URL in VLC and cast from that?

------
droithomme
8 hours in and Spitman's site is still a black page, even with JS enabled.

------
a1369209993
> This site requires JavaScript to function.

------
moondev
drag mp4 to browser then cast it?

~~~
AnIdiotOnTheNet
You can't cast arbitrary things like that except through desktop/whole screen
casting, which is not at all what the author is talking about (because it
sucks).

~~~
bhandziuk
You can cast files from your computer though, right? Which is different than
desktop/full screen casting.

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

~~~
derp_dee_derp
As much as HN wants to whine about it, the truth is that Javascript is a
primitive, basic, use case of the internet.

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

------
mrr54
Is this rendering Markdown to HTML on the fly in my web browser?

Just render the markdown to HTML once on the server and upload it for the love
of God.

That being said, the article is entirely correct.

~~~
AnIdiotOnTheNet
Because then when you edit the markdown you have to take an additional step.

~~~
danaris
That depends entirely on how you have your workflow set up.

~~~
AnIdiotOnTheNet
Sure, it's a matter of how complicated you want your workflow to be. The way
things are right now, the author can edit the markdown file directly and be
done with it. It's simple and straight-forward, low-effort and low cognitive
load.

~~~
danaris
I would imagine it would be possible to set up their system such that they
could edit the Markdown file, and a helper process would immediately pick up
that the file had been edited and re-run the local rendering to static HTML.

~~~
AnIdiotOnTheNet
Yes, great, now you've complicated the workflow. What if the service fails to
run? Or fails to pick up the changes? Now you've got another thing to think
about.

Is the overengineering so ingrained in the average HN user that they cannot
see why someone might not bother with that?

~~~
danaris
In the everyday _active_ workflow—the actions the author actually has to take
each time—it doesn't add any complication. It merely adds complexity in the
processing, which is certainly something worth considering.

However, in a case like this, the alternative—as we can already see—is to add
complexity for _every single reader_ on the front-end. So there's not really a
perfect solution here—either the author or the reader has to deal with some
complexity.

------
dredmorbius
Irony: blank page w/o JS, fails in Outline.com.

~~~
AndrewStephens
Well this is one way to write a web page.

    
    
      <body>
        <div id='rain-container'></div>
        <div id='root'></div>
        <script src='/deps/marked/lib/marked.js'></script>
        <script src='/deps/highlight.js/src/highlight.js'></script>
    
        <!-- Start preload for performance -->
        <script type='module' src='/components/core.js'></script>
        <script type='module' src='/components/tutorials.js'></script>
        <script type='module' src='/components/about.js'></script>
        <!-- End preload for performance -->
    
        <script type='module' src='/index.js'></script>
      </body>

~~~
reaperducer
From the site: _I am a data visualization software engineer._

Based on this web site, this is a definition of "software engineer" of which I
was previously unaware.

~~~
gberger
Presumably, he makes _data visualization software_. For example Tableau.

~~~
beckingz
Or builds data visualizations using code. D3 for example.

~~~
anderspitman
This. I work on the open source iobio tools:
[http://iobio.io/](http://iobio.io/)

------
unnouinceput
Quote "HTTP is the lingua franca of the internet. When you build stuff, please
make it work with simple URLs."

Says the one who can't have a simple HTTP only site and I had to enable JS on
NoScript in order to read his rant.

~~~
mtarnovan
Looks like you're mistaking HTTP for HTML... The article makes no mention of
HTML/JS.

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

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

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

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

------
anderspitman
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: <noscript> 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](https://github.com/anderspitman/assg)

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

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

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

[4] [https://patchbay.pub/](https://patchbay.pub/)

[5] [https://emauth.io/](https://emauth.io/)

~~~
dredmorbius
Since the entire conceit of your essay is to tell others what they should do,
I'll return the favour:

Please make your site work with vanilla HTML.

A link to your Github repo head where the Markdown might ... possibly ... be
unearthed ... is not that.

~~~
zzo38computer
Yes, or plain text. I would be fine just with a link to the Markdown text.

~~~
droithomme
Absolutely! A plain markdown file or even txt would be preferable to the
current situation where I can't read anything.

------
Animats
So you can't watch porn and anime?

------
stefan_
URLs are an utter failure, normal people don't understand them, the only
protocol they are ever used for is HTTP, special characters are a mess, IPv6
turns the insanity up to 11. The one other use of URLs has been tricking
unwitting users into launching vulnerable applications with malicious input,
because applications registering themselves for protocols was a thing once
added, then never critically thought about, ever.

URLs are simply not the forward case.

~~~
zzo38computer
URLs are used for protocols other than HTTP(S), although it is most common
with HTTP(S). Other URI schemes are sometimes used where a URL is needed to
make a link to something else (such as in a HTML document, or a Gopher menu
item that links to something using a protocol which Gopher does not support
linking to (HTTP being one of these protocols), or opening local files or
other stuff in a web browser, or for some uses in RDF).

But I agree that IPv6 makes it messy. (I had my own idea which is version 10
(numbers 7, 8, 9 are unusable) which uses the same format like version 4 but
with sixteen octets instead of four, and some other differences too.)

