Hacker News Reader

I think part of what people are pointing out is, if you went and asked the Roku devs why they don't support arbitrary URLs, I'm sure they would be able to give you a list of reasons as long as this if not longer.

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.

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.

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

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

>I'm optimizing for first-time visitors

As a first-time visitor I had a very bad experience while waiting for your JS to download and generate the content - in the meantime I was looking at a completely empty black screen.

Optimizing for first-time user experience means giving your visitors the content they came for as soon as possible, which is not what you’re doing.

Maybe I wasn't clear. I'm optimizing the performance for first time users, specifically when it comes to navigation.

EDITed to be less inflammatory.

You transfer 36K of JS on the first load. I estimate that all the entries together contain about 35K of gzipped Markdown.

Your largest entry (about dependencies) would be about 8K of gzipped HTML, and another quick estimate says that all the entries together would be about 50K of gzipped HTML.

Personal, and perhaps unkind opinion. This whole paragraph amounts to "it's my site and I can do what I want", which is not a great reason to expect one thing of others, but not yourself.

> First, having a build step creates a dependency on both the build tool and a specific action.

Instead, you push that compute off on your readers; actively harming the environment in the process. Yes, in this day and age I feel it's quite justifiable to point that out. You could render it once and be done with it, but instead you chose to have it be rendered (inefficiently) tens or hundreds of thousands of times, consuming orders of magnitude more energy and generating heat, all to "avoid a dependency". This should be, in this day and age, morally reprehensible.

I'd also point out the irony of the dependency upon javascript for static pages.

> Second, I wanted user interactions within my site to be very fast

A HTML page load from your site with a cold cache 114ms, of which 41ms is connection and TLS overhead, with a fetch time of 70ms. With all of the following requests it's up around 1s before it's rendered (and I'm on a Ryzen-powered gaming computer and fiber). A subsequent fetch of the assets to build one of your other pages is 71 ms (connection re-use means there's no connect time and no TLS time). This time is roughly the same no matter what article or page I pull up.

TL;DR: it's not making your other pages faster. It's just making your first page slower.

I agree with you about avoiding dependencies; I try to reduce dependencies myself. Many projects have a lot of dependencies, but I prefer to reduce dependences instead, I think is better.

I will write documents as plain text, and I agree with your idea to make them accessible as text is good.

I and others will write computer games and other stuff using simpler VMs than the web browser, such as Famicom and Glulx (both of which can also be implemented to work within the web browser, too). (Z-machine is also very portable; there are implementations for many computers, and I even wrote implementation of Z-machine in Glulx and in PostScript, and started (but never completed) writing one for Famicom (which has my own unusual mapper design too, with a bank size of only one byte, and mapper registers overlapping mirrors of internal RAM).)

Another thing can be, if you have a discussion forum, then I think NNTP is good (better than mailing list and web forum), although you can have mailing list and web forum with the same messages as the NNTP too. Even if the web interface requires JavaScripts to work, I would still insist that at least one thing works even without JavaScript and CSS, which is the link to the NNTP, including the message ID or newsgroup name. (It may also be used with the web forum allowing Markdown and then they appear in NNTP with "Content-type: text/markdown", which is something I have seen suggested; however, I think plain text is also fine and is my own preference.) (I also made up "Unusenet", which is a way of making newsgroup names which are not part of Usenet; all Unusenet newsgroup names begin with "un" and one or more digits and then a dot, and then the rest of the newsgroup name.) (Also, like IRC, NNTP can also be used without specialized software for it, although also like IRC, it is more convenient and work better if you do have such software, and it is not as difficult to write as the web browser software.)

Making the files accessible with curl seems good too, and the web browser is too complicated. Actually, I generally make the documents I write available as plain text instead of HTML, in order to support this (and many other uses, some of which might not be immediately known). But at least you added a <noscript> block, so I am glad you did that at least.

Firefox 72.0.1 with no blocking, just private window: still no "Reader view" can be shown.

The page which can't be shown in the "Reader view" is definitely broken for me and everybody with disabilities who depends on Reader view.

(Also, the same browser, when JS blocked by the extension: just black screen)

> TL;DR it's my personal site and I'll do what I want with it. It's for fun.

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

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

Future me. Actually just today in order to publish this post I had to re-learn how I had set up my dependencies, so I switched it to submodules so it won't be a problem again.

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

Believe me, I spent a torturous amount of time trying to achieve the same results with static HTML+prefetching/preloading. First off, Safari is a huge number of users. Plus you can't include HTML from HTML, so this requires a build step (though I've been experimenting with a new tool[0] for mitigating that somewhat). Also, this doesn't allow maintaining state between navigations.

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

Static HTML publishing is a solved problem. Don’t reinvent the wheel. Don’t make me run random JS to display plaintext. Don’t justify said random JS with silly whizbang features that no one actually wants.

It has been fixed so that there is a work around now. At first it was just blank, but now there is a work around. So, you can use that.

> I'll do what I want with it.

As is your right but it's not consistent with calls for simplicity.

> <noscript> should be working now

I've always had JS enabled and your site has still not worked, then or now. Your site is not accessible or simple. Again that's your right, and I agree with you about Smart TVs. Why not start the path to fix things by making your site readible on the screen of common blokes, poor people, and the non-elite that didn't buy something in the last 2 months?