3 ms·

https://raw.githubusercontent.com/anderspitman/anderspitman.net/master/entries/16/entry.md https://raw.githubusercontent.com/anderspitman/anderspitman.... Note

https://raw.githubusercontent.com/anderspitman/anderspitman.net/master/entries/16/entry.md https://raw.githubusercontent.com/anderspitman/anderspitman.... Note for OP: The reason this breaks without Javascript is because it's rendering the Markdown clientside. That could be moved to part of the build process without increasing your hosting requirements at all. I can see that you already have https://github.com/anderspitman/anderspitman.net/blob/master/gen_static https://github.com/anderspitman/anderspitman.net/blob/master... started, so I'm assuming you know this already and that you just haven't had the time to set up rendering on build yet. It's not my intention to preach to the choir. If you're struggling to figure out how to get this working as a SPA while still including content for non-JS users, my advice would be to include the rendered HTML in each index.html and just hide it with CSS during page load. You can still use AJAX for all of your subsequent navigation to avoid reloading the page, but if the static HTML is annotated with the correct links and content, people who request a specific URL without Javascript would still get to read. Or you could even get fancy and skip hiding it on the initial page load, only swapping it out with AJAX for future navigation, and this would make your initial page load even faster than it currently is.

jefftk 7y ago
Rendering markdown client-side seems like a fine way to implement a web page. It's a cheap transformation, and it means you don't need any sort of server-side build process. Yes, some people choose to browse with JS disabled, but anyone who browses that way should expect that many sites won't work and will need to be manually whitelisted.
- danShumway 7y ago
  > you don't need any sort of server-side build process OP is already using a server-side build process to generate the static site. Inserting the HTML at the same time they built the site would add very little extra code to their build process, and nothing to their static hosting requirements. If nothing else, would OP consider inserting a <noscript> tag in each generated index.html that linked to the raw Markdown in their Github repo?
  - jefftk 7y ago
    Ah, you're right: https://github.com/anderspitman/anderspitman.net/blob/master/gen_static https://github.com/anderspitman/anderspitman.net/blob/master... Yes, if you're going to have a build process, converting Markdown to HTML server-side makes a lot more sense.
  - anderspitman 7y ago
    > OP is already using a server-side build process to generate the static site The site doesn't use any build process. The gen_static script was an experiment that I didn't make it very far with. I may eventually get back to that.
- JohnFen 7y ago
  > 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.
  - jefftk 7y ago
    > I wonder if the authors of these badly engineered pages really know that they're excluding people People who choose to turn off JS are excluding themselves. JS is part of the web platform, and there are tons of amazing things it allows you to do. Being able to write a site in markdown with static hosting and have it instantly rendered in user's browsers is one of those things! If you choose to browse with IE6 and complain that sites using HTML5 are excluding you, I'm not going to be sympathetic either.
    - zeveb 7y ago
      > People who choose to turn off JS are excluding themselves. JS is part of the web platform, and there are tons of amazing things it allows you to do. People who choose to turn off JavaScript are protecting themselves, because JavaScript enables all sorts of attacks on one's security and privacy. JavaScript is not part of the web platform. The Web is a web (hence the name) of interlinked documents: the core requirements for a web of interlinked documents are a protocol (we have HTTP) and a document format (HTML); a style format (CSS) is nice too, albeit not strictly necessary (one can read unstyled documents in links, lynx, elinks, eww, w3m or whatever else just fine). There is absolutely no requirement for executing arbitrary, potentially malicious, unverified code from untrusted authors distributed globally. Are there great examples of cool JavaScript applications? Yes, certainly. Is JavaScript a core requirement to support a web of interlinked documents — i.e., the Web? No, not at all. To the contrary, JavaScript is murdering the Web, and this page's misuse is a prime example. JavaScript delenda est!
      - 7y ago
- zeveb 7y ago
  > Rendering markdown client-side seems like a fine way to implement a web page. Requiring readers to execute arbitrary code in order to read content seems like a terrible way to implement a web page. Nor is it cheap: it requires every single reader to execute the same code, burning CPU over and over and over when it could be done once for all readers, by the server. > Yes, some people choose to browse with JS disabled, but anyone who browses that way should expect that many sites won't work and will need to be manually whitelisted. Yes, you can require execute privileges in order to publish content, but anyone who publishes that way should expect that many people won't read what he writes.
- droithomme 7y ago
  > Yes, some people choose to browse with JS disabled, but anyone who browses that way should expect that many sites won't work and will need to be manually whitelisted. JS is enabled here and it doesn't render.
anderspitman 7y ago
Please see my explanation here: https://news.ycombinator.com/item?id=22038862 https://news.ycombinator.com/item?id=22038862
- danShumway 7y ago
  Even without adding a build step, would you be willing to add a <noscript> tag to your index.html that just linked to the Github repo in general? It wouldn't even need to be specific to each individual post. While admittedly some readers here are purely focusing on the irony of supporting "the primitive, simple case", for the most part non-JS users are willing to meet sites halfway on this. I'm totally fine manually navigating a Github repo to get at posts, I wouldn't be irritated at all in that situation, I wouldn't have even commented. Right now, your site offers nothing. Even just the below markup would have been sufficient -- it wouldn't need to be customized per-page. <noscript> <div>This site requires Javascript to function. You can view the raw text of posts on <a href="https://github.com/anderspitman/anderspitman.net">Github</a>.</div> </noscript> Just give users something, literally anything they can use to recover when your expected use-case fails.
  - anderspitman 7y ago
    > Even without adding a build step, would you be willing to add a <noscript> tag to your index.html that just linked to the Github repo in general Absolutely! Should be working now (or as soon as CloudFlare cache is purged). Thanks for the snippet.
    - danShumway 7y ago
      Thanks a ton! It's showing up perfectly on my end. As long as I know how to get to the text in some format, I'm usually fine with the rest, and markdown is a format that's very easy to read.
      - anderspitman 7y ago
        Even so, I'm going to put in some effort to make text-only a 1st-class citizen.

jefftk 7y ago

Rendering markdown client-side seems like a fine way to implement a web page. It's a cheap transformation, and it means you don't need any sort of server-side build process. Yes, some people choose to browse with JS disabled, but anyone who browses that way should expect that many sites won't work and will need to be manually whitelisted.

danShumway 7y ago
> you don't need any sort of server-side build process OP is already using a server-side build process to generate the static site. Inserting the HTML at the same time they built the site would add very little extra code to their build process, and nothing to their static hosting requirements. If nothing else, would OP consider inserting a <noscript> tag in each generated index.html that linked to the raw Markdown in their Github repo?
- jefftk 7y ago
  Ah, you're right: https://github.com/anderspitman/anderspitman.net/blob/master/gen_static https://github.com/anderspitman/anderspitman.net/blob/master... Yes, if you're going to have a build process, converting Markdown to HTML server-side makes a lot more sense.
- anderspitman 7y ago
  > OP is already using a server-side build process to generate the static site The site doesn't use any build process. The gen_static script was an experiment that I didn't make it very far with. I may eventually get back to that.
JohnFen 7y ago
> 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.
- jefftk 7y ago
  > I wonder if the authors of these badly engineered pages really know that they're excluding people People who choose to turn off JS are excluding themselves. JS is part of the web platform, and there are tons of amazing things it allows you to do. Being able to write a site in markdown with static hosting and have it instantly rendered in user's browsers is one of those things! If you choose to browse with IE6 and complain that sites using HTML5 are excluding you, I'm not going to be sympathetic either.
  - zeveb 7y ago
    > People who choose to turn off JS are excluding themselves. JS is part of the web platform, and there are tons of amazing things it allows you to do. People who choose to turn off JavaScript are protecting themselves, because JavaScript enables all sorts of attacks on one's security and privacy. JavaScript is not part of the web platform. The Web is a web (hence the name) of interlinked documents: the core requirements for a web of interlinked documents are a protocol (we have HTTP) and a document format (HTML); a style format (CSS) is nice too, albeit not strictly necessary (one can read unstyled documents in links, lynx, elinks, eww, w3m or whatever else just fine). There is absolutely no requirement for executing arbitrary, potentially malicious, unverified code from untrusted authors distributed globally. Are there great examples of cool JavaScript applications? Yes, certainly. Is JavaScript a core requirement to support a web of interlinked documents — i.e., the Web? No, not at all. To the contrary, JavaScript is murdering the Web, and this page's misuse is a prime example. JavaScript delenda est!
    - 7y ago
zeveb 7y ago
> Rendering markdown client-side seems like a fine way to implement a web page. Requiring readers to execute arbitrary code in order to read content seems like a terrible way to implement a web page. Nor is it cheap: it requires every single reader to execute the same code, burning CPU over and over and over when it could be done once for all readers, by the server. > Yes, some people choose to browse with JS disabled, but anyone who browses that way should expect that many sites won't work and will need to be manually whitelisted. Yes, you can require execute privileges in order to publish content, but anyone who publishes that way should expect that many people won't read what he writes.
droithomme 7y ago
> Yes, some people choose to browse with JS disabled, but anyone who browses that way should expect that many sites won't work and will need to be manually whitelisted. JS is enabled here and it doesn't render.

anderspitman 7y ago

Please see my explanation here: https://news.ycombinator.com/item?id=22038862 https://news.ycombinator.com/item?id=22038862

danShumway 7y ago
Even without adding a build step, would you be willing to add a <noscript> tag to your index.html that just linked to the Github repo in general? It wouldn't even need to be specific to each individual post. While admittedly some readers here are purely focusing on the irony of supporting "the primitive, simple case", for the most part non-JS users are willing to meet sites halfway on this. I'm totally fine manually navigating a Github repo to get at posts, I wouldn't be irritated at all in that situation, I wouldn't have even commented. Right now, your site offers nothing. Even just the below markup would have been sufficient -- it wouldn't need to be customized per-page. <noscript> <div>This site requires Javascript to function. You can view the raw text of posts on <a href="https://github.com/anderspitman/anderspitman.net">Github</a>.</div> </noscript> Just give users something, literally anything they can use to recover when your expected use-case fails.
- anderspitman 7y ago
  > Even without adding a build step, would you be willing to add a <noscript> tag to your index.html that just linked to the Github repo in general Absolutely! Should be working now (or as soon as CloudFlare cache is purged). Thanks for the snippet.
  - danShumway 7y ago
    Thanks a ton! It's showing up perfectly on my end. As long as I know how to get to the text in some format, I'm usually fine with the rest, and markdown is a format that's very easy to read.
    - anderspitman 7y ago
      Even so, I'm going to put in some effort to make text-only a 1st-class citizen.