4 ms·

I don't want to discourage you, but I also don't want to encourage the proliferation of websites (web apps---as an alternative to actual desktop software---excl

I don't want to discourage you, but I also don't want to encourage the proliferation of websites (web apps---as an alternative to actual desktop software---excluded) that require JavaScript to function at all. Sites using JS only cannot be parsed by standard tools---I can't cURL the page, use wget, use a text-mode browser, etc. This fundamentally breaks interoperability, and limits users' freedom to use the tool/browsers they want to use the web. Users who wish to disable JavaScript to browse the web---be it for security, privacy, philosophy[0], or all of these things---are forced to either enable JavaScript or not read your website (I fall into the latter). I write more JavaScript than any other language. I understand the community, and the rationale. But I know enough to know that I should disable JavaScript when browsing the web (except for select cases, and the software must be Free), and I still use command-line tools aggressively, even for the web. Please do your best to respect those who use the web as it was intended. Keep hacking, but consider fallbacks, too! [0]: https://www.gnu.org/philosophy/javascript-trap.html https://www.gnu.org/philosophy/javascript-trap.html

dyladan 11y ago
It really depends on the use case. My site[0] works in a very similar fashion to cms.js but if you have javascript disabled it forwards you to the raw markdown file using a simple noscript tag. Sure, it breaks cURL but it's just a personal website so who really cares? [0]: https://dyladan.me https://dyladan.me
- inflam52 11y ago
  Yeah that was kind of my line of thinking. This is definitely not ready for enterprise level blogs yet...more along the lines of personal sites/small blogs you want to get up and running quickly.
- mikegerwitz 11y ago
  I get most of my useful information and perspectives from personal websites---be it various well-respected experts in the fields, or people that nobody really knows about, but have great information or perspectives. In software development especially, our community of hackers is our most valuable asset.
  - dyladan 11y ago
    Which is why I use the noscript fallback. I'm just saying it's not worth my time to worry overmuch about supporting everybody's use case on a personal blog full of half-completed thoughts. Nobody is trying to automate anything using my site and if they are then I feel bad for them. If javascript is on my site is fine, if not then you can see the markdown files. I'm not worried about anybody else.
roblabla 11y ago
I'm pretty sure there's no "intended way" to use the web. The developer of the website dictates this. If he wishes to use JS-only, that is his choice. He may lose you as a user/reader, but he certainly is using the web "as intended". The choice to block JS seems a bit weird to me. JS, to my eyes, is very different to binary code running in userland. It is a sandboxed language with very clear restrictions to what it may do, it is easily read and verified (view source, pass it through a prettifier, and all that's left to fix is the variable names), and even hackable (we get a JS console in browsers). What is it that makes JS so dangerous it must be blocked 100% ?
- dyladan 11y ago
  Many browser exploits that break out of the sandbox take advantage of javascript. Disabling it prevents entire classes of exploits. Also, a lot of ad networks use javascript as a tracking tool.
  - nqzero 11y ago
    citation for your exploits claim ? you've worded it in an awkward manner that makes it sound like a red herring specifically, are there javascript-only (or js+css+html only) exploits in recent chrome or firefox ?
  - dyladan 11y ago
    After about 20 seconds of googling chrome: https://www.cvedetails.com/cve/CVE-2011-1186/ https://www.cvedetails.com/cve/CVE-2011-1186/ firefox: https://www.cvedetails.com/cve/CVE-2015-4509/ https://www.cvedetails.com/cve/CVE-2015-4509/
    - andrewstuart2 11y ago
      I don't think most people would consider 2011 recent.
- PavlovsCat 11y ago
  Going from a web of documents to black boxes that put pixels on the screen is regression plain and simple. Use it when necessary for the things that cannot be otherwise done, but don't ruin a good thing that works fine just because you can. Thanks.
inflam52 11y ago
Thank you I really appreciate your feedback! I definitely understand and respect your view on accessibility for those not using Javascript. I was just trying to approach the problem from a different perspective...seeing if there was a way to do accomplish this using just client-side technologies. I'm definitely going to consider looking into fallbacks if they are possible.

dyladan 11y ago

It really depends on the use case. My site[0] works in a very similar fashion to cms.js but if you have javascript disabled it forwards you to the raw markdown file using a simple noscript tag. Sure, it breaks cURL but it's just a personal website so who really cares? [0]: https://dyladan.me https://dyladan.me

inflam52 11y ago
Yeah that was kind of my line of thinking. This is definitely not ready for enterprise level blogs yet...more along the lines of personal sites/small blogs you want to get up and running quickly.
mikegerwitz 11y ago
I get most of my useful information and perspectives from personal websites---be it various well-respected experts in the fields, or people that nobody really knows about, but have great information or perspectives. In software development especially, our community of hackers is our most valuable asset.
- dyladan 11y ago
  Which is why I use the noscript fallback. I'm just saying it's not worth my time to worry overmuch about supporting everybody's use case on a personal blog full of half-completed thoughts. Nobody is trying to automate anything using my site and if they are then I feel bad for them. If javascript is on my site is fine, if not then you can see the markdown files. I'm not worried about anybody else.

roblabla 11y ago

I'm pretty sure there's no "intended way" to use the web. The developer of the website dictates this. If he wishes to use JS-only, that is his choice. He may lose you as a user/reader, but he certainly is using the web "as intended". The choice to block JS seems a bit weird to me. JS, to my eyes, is very different to binary code running in userland. It is a sandboxed language with very clear restrictions to what it may do, it is easily read and verified (view source, pass it through a prettifier, and all that's left to fix is the variable names), and even hackable (we get a JS console in browsers). What is it that makes JS so dangerous it must be blocked 100% ?

dyladan 11y ago
Many browser exploits that break out of the sandbox take advantage of javascript. Disabling it prevents entire classes of exploits. Also, a lot of ad networks use javascript as a tracking tool.
- nqzero 11y ago
  citation for your exploits claim ? you've worded it in an awkward manner that makes it sound like a red herring specifically, are there javascript-only (or js+css+html only) exploits in recent chrome or firefox ?
- dyladan 11y ago
  After about 20 seconds of googling chrome: https://www.cvedetails.com/cve/CVE-2011-1186/ https://www.cvedetails.com/cve/CVE-2011-1186/ firefox: https://www.cvedetails.com/cve/CVE-2015-4509/ https://www.cvedetails.com/cve/CVE-2015-4509/
  - andrewstuart2 11y ago
    I don't think most people would consider 2011 recent.
PavlovsCat 11y ago
Going from a web of documents to black boxes that put pixels on the screen is regression plain and simple. Use it when necessary for the things that cannot be otherwise done, but don't ruin a good thing that works fine just because you can. Thanks.

inflam52 11y ago

Thank you I really appreciate your feedback! I definitely understand and respect your view on accessibility for those not using Javascript. I was just trying to approach the problem from a different perspective...seeing if there was a way to do accomplish this using just client-side technologies. I'm definitely going to consider looking into fallbacks if they are possible.