13 ms·

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

by 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!
    - jefftk 7y ago
      > JavaScript enables all sorts of attacks on one's security and privacy Could you say more about this?
      - dredmorbius 7y ago
        https://duckduckgo.com/?q=javascript+security+privacy+risks&ia=qa https://duckduckgo.com/?q=javascript+security+privacy+risks&...
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.

by jefftk 7y ago

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!
  - jefftk 7y ago
    > JavaScript enables all sorts of attacks on one's security and privacy Could you say more about this?
    - dredmorbius 7y ago
      https://duckduckgo.com/?q=javascript+security+privacy+risks&ia=qa https://duckduckgo.com/?q=javascript+security+privacy+risks&...

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.