8 ms·

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.

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/

layoutIfNeeded 7y ago
>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.
- anderspitman 7y ago
  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.
Dunedan 7y ago
> 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/ 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_prefetching_FAQ https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefe... [2]: https://en.wikipedia.org/wiki/Link_prefetching https://en.wikipedia.org/wiki/Link_prefetching

layoutIfNeeded 7y ago

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

anderspitman 7y ago
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.

Dunedan 7y ago

> 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/ 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_prefetching_FAQ https://developer.mozilla.org/en-US/docs/Web/HTTP/Link_prefe... [2]: https://en.wikipedia.org/wiki/Link_prefetching https://en.wikipedia.org/wiki/Link_prefetching