4 ms·
Warning, website wont load at all unless JavaScript is enabled.
by svnpenn 6y ago
Warning, website wont load at all unless JavaScript is enabled.
- netmare 6y agoNot only that, it also caused the app I'm using (Readability) to go back to the article list. I usually get a blank screen, but this is first time I've seen it fail so spectacularly in years. Does anyone know what the site's JavaScript doing to cause that?
- laumars 6y agoThat explains why I got a loading screen for a page that was just static text. I don’t get why people use those kind of shitty frameworks for sites that don’t require interactive content.
- thefreeman 6y agoBecause it's their website and they can publish their free content however they want? You are always welcome to not consume it.
- hnlmorg 6y agoI do get your sentiment but it's not really addressing what I believe the GPs point to be, which is redundant framework bloat for personal blogs. Take the sites I personally run, one of them is written in markdown and "compiled" to HTML using `pandoc` (a CLI document conversion tool) and then it's pushed to S3. Some of the others are run on dynamic CMSs and have modern frameworks used to "help speed up development". But you know which site was actually the quickest to develop? It's also the site which which loads the quickest, costs the least to host and requires the least upkeep -- it's the one which doesn't use any frameworks at all, just a few lines of hand-crafted CSS. It doesn't even have any Javascript. I'm not saying everyone has to go that minimal but my (and I suspect the GPs) point is that people can get carried away when designing their personal blogs, and in fact sites in general, and miss the point of what their site is actually trying to achieve in the process. If someone feels they need a loading screen to serve a static blog then I suspect they've probably fallen into that trap themselves.
- jwilk 6y agoDisable CSS or use reader mode.
- chrismorgan 6y agoDelete the first element in the body, <section id="preloader">, which sits on top of the rest and blocks it from view. This is one of the two standard failure techniques. (I glom <body style="opacity:0"> and the likes in the same category as this site.) The other category is where the body has no content, and JavaScript injects it. I’m undecided which is worse, but I think that it’s probably this one, because the developer pretty much went out of their way to slow things down in the name of subjective prettiness (and perhaps just because they wrote the rest of the markup/styling/code badly), and thereby broke things. Whereas I can at least understand why you’d do the whole thing in JavaScript, even if it’s not something I’m willing to do.
- StavrosK 6y agoIs that to avoid the FOUC?
- chrismorgan 6y agoTypically, yes. But I just want to be clear on this reason: it’s a fundamentally bad technique that slows things down and harms accessibility, both of which are far more important than your website potentially appearing slightly imperfectly while it loads, like just >99.4% of websites. (And if you’re doing something that means that your page looks worse than most while loading, you’re probably loading your resources in the wrong way somehow, e.g. putting a critical stylesheet at the end of the document rather than in the head.) Other reasons for doing this are: • A splash screen sort of experience. Yeah, there are still some around doing this, though it’s fortunately uncommon. It’s often a precursor to this second reason: • A misguided desire to animate things into place at the right time (kind of an extension of the FOUC, I guess). Gratuitous animating-in of content as you scroll, which this meshes with, is a horrible thing to do, by the way: although it’s decidedly popular on homepages, most people dislike it (ranging from mild displeasure to rage-quitting the site), because it’s distracting, slows things down and adds nothing. Just don’t do it. In short, I see no legitimate reason to ever set document opacity to zero or to put a loading spinner on top of everything else, in CSS. (In JavaScript, maybe—there are defensible reasons; but never in CSS.)