Irony: blank page w/o JS, fails in Outline.com.
<body>
<div id='rain-container'></div>
<div id='root'></div>
<script src='/deps/marked/lib/marked.js'></script>
<script src='/deps/highlight.js/src/highlight.js'></script>
<!-- Start preload for performance -->
<script type='module' src='/components/core.js'></script>
<script type='module' src='/components/tutorials.js'></script>
<script type='module' src='/components/about.js'></script>
<!-- End preload for performance -->
<script type='module' src='/index.js'></script>
</body>Based on this web site, this is a definition of "software engineer" of which I was previously unaware.
Edit: Actually https://raw.githubusercontent.com/anderspitman/anderspitman.... works fine already; can we change the submission URL to that?
JS should not be needed to show five paragraphs of text. And even with the JS the resulting HTML is still unreadable.
FF72, uBlock Origin in medium mode, no whitelisting => site renders just fine both in normal and in reader view.
His "noscript" is also broken as it still doesn't show the darned 5 paragraphs of text. It's that hard for him, as he writes what others should do.
The OP is arguing that the primitive, simple case for this page is to not use any javascript because it's unnecessary for the core functionality of this page. The content here can be displayed simply as a few kilobytes of raw HTML.
Much like the author assumed that javascript is most primitive & simple functionality for internet users, the people who built his TV, assumed that chromecast protocol is the most primitive & simple way to send a video link to the TV.
It entirely fails to render in text-mode browsers (I actually make heavy use of w3m).
It entirely fails to render in https://outline.com/, which otherwise is a good way to get fucked-up JS-dependent sites to render. I consider that stage of fuckwittedness either absolutely deliberate (which it appears to be in this case based on the authors defence of their practices), or utter incompetence. These are not mutually exclusive possibilities.
The fact that the article is apparently (I've still been unable to read it) a plea for base-level compatibility is, as initially noted, arch irony.
View source indicates about half is some Google analytics boilerplate, the other half is a body consisting entirely of non-functional JS pulls.
OP, where is the content stored?
Please make your products work with URLs
I want to tell you about something I was unable to accomplish, after more than 30 minutes of concerted effort. I have video file hosted using a web server. The file is H.264 main-profile encoded at a reasonable bitrate (<5Mbps), uses AAC audio, and is packaged in an MP4 container. The web server supports HTTP range requests. In other words, the video is basically in the least common denominator format for compatibility. It streams great in all major web browers, VLC, and everything in between.
In my living room, I have a Roku "smart" TV. It has tons of apps, full internet connectivity, and is more than capable of both connecting to and playing the video file described above. But I failed to get this to happen, after much googling and trying multiple apps (both on the Roku TV and my Android phone).
The way this type of thing is usually accomplished in 2020 is to open the video on your phone, then tap a "cast" icon and tell it to send the video to your TV. What happens behind the scenes is the phone uses some protocol (Chromecast being the most common I'm aware of) to send the URL to the TV, and the TV then plays it directly, while still letting you play/pause, seek, change volume, etc from the phone. When this works, it's like magic. The YouTube app works particularly well. However, there doesn't seem to be any widely implemented standard for playing plain URLs, only walled gardens like the YouTube app. This whole thing was made much more frustrating by the fact that I knew the TV had all the requisite capabilities to do what I was attempting. The YouTube app is proof of that. There just wasn't any obvious way to find the correct app combination.
Here's the way this should work.
The Roku app for Android allows you to use your phone as a keyboard for the TV, rather than the awful physical remote UX for input. This is a great feature which I appreciate. I should be able to copy a URL from my phone (possibly obtained from scanning a QR code), paste it into the Roku Android app, and the Roku should attempt to play the file at the URL. This is clunky, awkward, and not particularly easy. But it is simple, obvious, and intuitive.
Here is my plea: when you build hardware/software, please make it support the primitive, simple case. By all means, implement the slick Chromecast-style flows. It's great when it works. But there needs to be a fallback for when it doesn't work, or when the user wants to try something slightly different. HTTP is the lingua franca of the internet. When you build stuff, please make it work with simple URLs.
Cloudflare and archive.fo don't play well together. Each blames the other.
I've explicitly coded an exception for the domain on my own networking kit, but that fix hasn't been working for a while, which is ... annoying.
Ordinarily, though, it's a useful fix. If you can point DNS at a provider other than Cloudflare (1.1.1.1), it should work.
Is this site heavy on ads and other malware and won't display without totally naked openness to exploits?
(Note: works for me too, with default uBlock and Pi-Hole blocklists)
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... 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.
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?
Yes, if you're going to have a build process, converting Markdown to HTML server-side makes a lot more sense.
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.
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.
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.
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!
Could you say more about this?
To start with, I'm not on the anti-Javascript hype train. I write Javascript for a living, I think it's the arguably the most important modern language of the last decade. It's made computers more accessible, it has good ideas, it's reasonably well sandboxed. I love Javascript. I do advocate for progressive enhancement for a lot of reasons, but in part because that's the foundation of web architecture, and I think it's still relevant today.
The best web developers I know that I really respect all understand what progressive enhancement really means as an architectural pattern, and they don't dismiss it out of hand.
Also to be clear, the browser is (unarguably) hands down the best consumer-facing sandbox that we've ever built. And I like sandboxes, a lot. I think sandboxing is the future of user-facing application security -- not trusted stores, or signing, or managing dependencies in a special way, or SaaS.
Having said that, I'm also using the web as it exists today. And let's just very quickly list a few major security vulnerabilities that have happened within the past few years in browsers, all of which you would have been effectively immune from if you had disabled Javascript by default on even just most sites you visited:
1. Spectre/Meltdown
2. LastPass's browser extension leaking passwords to any page you visited.
3. Firefox's most recent 0-day (that is being actively exploited)[0].
4. Targeted vulnerabilities in mobile Safari (that went unpatched for years)[1].
On top of the numerous browser vulnerabilities that pop up, disabling Javascript by default will protect you from a nontrivial number of phishing attacks and cookie-hijacking attacks. Yes, you can do these attacks without JS/ajax, but in practice a large number of them use JS/ajax. Disabling JS will also make you effectively immune from crypto-mining attacks.
Even non-malicious pages are usually not coded well in terms of CPU-power. One way you can tell a browser disables JS by default is that the non-JS setup will gracefully handle several hundred tabs at the same time in normal everyday usage for extended periods (>1 month). The other browser will eventually get caught by a rogue tab that freezes everything and forces you to restart the browser.
On the privacy front... I dunno, don't you work at Google? You should know this.
Panoptoclick[2] tells me my current browser setup is leaking about 6.6 bytes of identifying information. That's low enough that with a decent VPN setup, I can browse the web (close to) anonymously in many situations. I would challenge you to get a better result than that without disabling Javascript -- especially if you're starting from the disadvantage of using an uncommon OS like Mac or Linux.
----
So there's an interesting philosophical conflict here, which is that the web is awesome, and browsers are awesome, and Javascript is awesome, but anyone who's both technical and privacy-minded should turn Javascript off by default. And this conflict is because where security is concerned, I am trying very, very hard to be a fox, not a hedgehog.[3]
My general advice, notwithstanding my opinion on sandboxes, is that everyone should install Ublock Origin, no matter who they are. If you're technically inclined and understand the web, you should also install UMatrix, which will at least get rid of the most common attack vectors: third-party scripts. If you're technically inclined and understand the web and you worry a lot about privacy, you should use UMatrix to disable JS by default.
That's not an ideological position about sandboxes or about the web. It's not saying native apps are better (native environments are in most cases objectively worse at security). It's purely an observation that roughly 75% of the sites I visit (including many major news sites) work fine without Javascript. It's based on the fact that I keep on seeing security vulnerabilities pop up where not running Javascript is an effective mitigation. It's based on practical concerns about privacy.
So the foxy perspective on web security/privacy is if there's an easy, effective way to improve my security that works most of the time, why wouldn't I do that? And why wouldn't I encourage developers to make it easier for me to do that?
It's not saying that nothing should run Javascript. It is saying that if you want to run Javascript, you should have a reasonably good justification, and if you're displaying pure text you should probably provide fallbacks when possible.
[0]: https://arstechnica.com/information-technology/2020/01/firef...
[1]: https://googleprojectzero.blogspot.com/2019/08/a-very-deep-d...
[2]: Admittedly, Panoptoclick's usage numbers are skewed towards privacy-conscious users. In the real world, the pool of people like me will be smaller. However, people who use VPNs are also skewed towards privacy-conscious, which tilts that back in my favor a bit.
Excellent response and more patience than I could muster.
> It's not saying that nothing should run Javascript. It is saying that if you want to run Javascript, you should have a reasonably good justification, and if you're displaying pure text you should probably provide fallbacks when possible.
It goes both ways. Yes, turning off JS means that some sites will fail to work. As I said in my comment, I expect this. On the other hand, a well-designed site should fail gracefully, so that turning off JS won't make the site fail to work, but may make certain features unavailable. Sites that don't fail gracefully (with certain exceptions) are poorly engineered sites that are excluding people unnecessarily.
> JS is part of the web platform
JS is an optional part of the web platform.
> and there are tons of amazing things it allows you to do.
Of course. The problem is that JS allows terrible things to be done as well. Just as I won't download and execute binaries from random web sites, I won't allow JS from random websites, for precisely the same reasons. JS is too risky.
> If you choose to browse with IE6 and complain that sites using HTML5 are excluding you, I'm not going to be sympathetic either.
That's a poor analogy because HTML5 will fail gracefully. If I browse to an HTML5 site with IE6, I will (with rare exceptions) still be able to read the page.
Every time someone makes a site they're balancing a bunch of tradeoffs. For example, when I built https://trycontra.com I could have implemented the search server-side, with a query and response, but this would have involved writing active server side code. Instead I implemented the search entirely in client-side javascript. People are free to choose not to run the JS, but I don't feel any obligation to engineer the site differently to accommodate their preference and I don't think the OP should either.
> Just as I won't download and execute binaries from random web sites, I won't allow JS from random websites, for precisely the same reasons. JS is too risky.
Downloading and executing binaries from random websites is far more risky than allowing JS. A binary runs as you can can trivially do anything you could do, from keylogging to subverting your browser. If you can do similar harmful things from JS, on the other hand, you're eligible for very large bounties from browser vendors. JS is heavily sandboxed, and browsers have some of the world's best security engineers working on maintaining an ecosystem where people can freely run other people's JS.
> That's a poor analogy because HTML5 will fail gracefully. If I browse to an HTML5 site with IE6, I will (with rare exceptions) still be able to read the page.
HTML often fails gracefully, but not always. If someone writes a site that doesn't fail gracefully and so is completely unreadable in IE6, I don't think they've done anything wrong.
Rendering the goddamned content is.
If you can't at a minimum give me a title, byline, dateline, main body text and/or some level of summary or description of non-textual content (as with graphics, audio, video, or interactive elements), then you're failing.
(SPAs or web applications should at least provide context for understanding what the application is/does. I'm not calling for all functionality to be rendered in HTML, but sufficient context to determine WTF the site is about.
Your "but I cannot implement search" is a strawman, and really doesn't address the core complaint.
As it stands, I'm looking at options for SSG-based blog posting, and at how it might be possible to support search. JS-based options, plus an extensive tagging / ontological classification, strike me as a reasonable compromise.
The fact that the Web is lacking a usable search-oriented standard which could bypass much of this problem, is one that's seldom noted. If sites could provide a permuted index in accessible format, and a standard mechanism for accessing it via a browser site-search function (or independent third-party search tools) ... well, the present online landscape would look remarkably different.
Sadly, we're not there, and the orientation of the leading browser developer is quite likely not going to support such development.
I'm not going to dismiss this out of hand, but this is a harder problem than you realize. We did have search keywords at one point. The problem was that sites started stuffing them with irrelevant values. Google removed that and started doing their own analysis, because keywords made it too easy to game SEO.
There are certainly ways that keywords could be done better today, I'm not going to say we should give up on the entire concept. But asking websites to self-categorize themselves is a very tricky problem that is very prone to abuse.
Remember that the web (currently) monetizes eyeballs, so until that situation changes there is a strong incentive to show up in every search regardless of whether or not you're relevant.
My example was a domain specific search engine. The only thing the site does is let you run searches, implemented client-side in JS. Without JS the site completely doesn't work.
Perhaps you misunderstand what I'm saying. I am not saying that you, or anyone else, is obligated to do anything in particular. All I did was to point out a factor that should be considered -- if your site does not work without JS, then you are excluding some people. If you don't care, fair enough.
However, I stand by my assertion that sites that do not fail gracefully are (with certain exceptions) poorly engineered sites.
> Downloading and executing binaries from random websites is far more risky than allowing JS
That does not mean that allowing JS is safe.
> JS is heavily sandboxed, and browsers have some of the world's best security engineers working on maintaining an ecosystem where people can freely run other people's JS.
Yes, I'm well aware of that. And yet, JS is commonly used to do all sorts of nefarious things (such as tracking, for instance) anyway.
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.
JS is enabled here and it doesn't render.
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>
Absolutely! Should be working now (or as soon as CloudFlare cache is purged). Thanks for the snippet.
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.
I suggested to have a link (or just instructions, if you don't want it to be customized per post) for accessing the Markdown code for the specific post. However, a link to the Github repository also works perfectly OK, so I am not complaining.
I think that are various levels of proficiency, but in general, most Danes have a very good grasp of it, and it's easy to live here if you only speak English.
With NoScript blocking both the site and Google.
By "w/o JS" do you mean totally disabled? Or just NoScript?
And you're right, I wasn't paying attention. I did temporarily allow the site.