No, it' because whoever made the site is ignoring the age-old simple practice of showing something (even the text "This website requires javascript") even if not all resources have loaded.

It is entirely unlike the examples you gave. Especially because his browser does show ~99% of the internet properly (with various degrees of functionality, but still something does come up), and that there spiders, proxies, screenreaders, and other useful software which will also see nothing on this page.

All major screenreaders work from the DOM and the accessibility tree nowadays, and have done for a long time at this point. Dynamic content is no problem in and of itself.

Unless you are fetching data async. Google and other will not wait for data.

That's not true. Google indeed waits for async content to load for a given amount of time. You can inspect this from the Google webmaster tools.

I did a lot of tests on this and Google just didn't wait, no matter the configuration. I tested using webmaster tools. The App was built using React, and I ended up implementing SSR to fix the problem. There are a lot of posts that hack this embedding JSON directly on the page. I didn't find any post that figured out a way to make this works through async API requests. I would thank you if you point one in that direction. Maybe I'm doing something wrong.

Were you using react-router by any chance?

I've bookmarked this site: "Testing a React-driven website’s SEO using “Fetch as Google" https://medium.freecodecamp.com/using-fetch-as-google-for-se...

That talks about this. Not had a chance to verify this. just a fyi.

Interesting, never occurred to me that react-router could be the problem, I will investigate that. But this other post [1] didn't use React at all and made API requests to GitHub with the same problem.

[1] http://andrewhfarmer.com/react-seo/

This is why computers become slower and slower, and people have to upgrade. Because lazy developers make idiotic choices.

It's a static list of items. Hardly very efficient to load all that javascript, do a server request, just to display a list is it.

While I totally agree about this site, it's stupid to disregard JS as a whole. Imagine websites like FB without JS - it would be horrible.

You don't have to imagine, you can try: https://mbasic.facebook.com/ - a lot of people prefer it to the standard monstrosity.

I use mbasic.facebook as my main was of interacting with Facebook. I acknowledge that my choice to disable JavaScript is unusual and will jump through some hoops because of that, but it's not excusable for a website to display /nothing/ pre-script like the OP does.

Good example. After getting used to the 1998 feel, it's much more practical than the usual one.

The great thing about this is that it's paginated. You can literally "scroll infinitely" through feeds without creating a ridiculous scroll offset and filling up browser memory (or losing Ctrl-F functionality due to Facebook's complex memory-saving exercises)

Nice but it could use a bit more whitespace, feels crowded.

this makes me miss the OG fb. I dont use facebook much, but I think I would use it quite a bit more if this was the layout.

There is a place for JS but most sites don't need it or at least don't need to drive the entire site. The problem is that Jquery now is 'bad' because it, what was it again, is not suitable for structuring big apps (ofcourse it is not; it's not meant to be an MVC or whatever framework; it's helper library to make Javascript easier to use). So it is obvious (and I see it all around me) that people build sites now like they are building Facebook, even though the site might have only 1 or 2 pages and no interactive functionality to speak off.

Still, this guy did it (took a long time between this site being up and the post on HN that instigated it) while the rest of the readers in that thread who thought it would be a good idea, including me, didn't. So kudos for 'just doing it' anyway.

Edit: I checked hours ago and then it was clean but apparently there is no moderation on it either... So this site would've taken literally less than an hour including hosting setup to put together? Still I didn't do it while I did like FuckedCompany and think it's good to have something like it.

It's a good thing mibbiting didn't disregard JS as a whole, then.

This isn't a website like FB.

Huh? I always use the mbasic Facebook site: it's a much, much better experience.

See http://webassembly.org/ . While not raw assembly, we have to because of the js nonsense. This will ofcourse also increase the jsnonsense, cause now everything will be more efficient so we can put alot more crap.

In future publishers will probably use web assembly for DRM, for example, to render decrypted article text on a canvas so that it cannot be copied, zoomed, read aloud or viewed without advertisement and annoying popups. Maybe you will change your mind about Javascript then.

You jest, but in one of the discussions for EME, that exact case was brought up.

Only they wanted to drm javascript sent to the browser. We got rid of Flash only to see a new hydra head emerge. People clamoring for javascript applications should be careful what they wish for. They just might get it.

I don't think this is a fair argument. Writing web pages as single page JS apps is _harder_ than writing them as server-side generated html responses. And in many cases (this one as a great example), the user experience is worse for having done so.

This is such a bad example, as JS is actually more low level than a declarative language like HTML.

This point of view forgets the fact that loading 1MB of JS instead of 10KB of HTML is actually a bad thing. It consumes bandwidth and energy, and thus has an effect on the environment, for instance.

Even from a hosting point of view, it would be faster and more efficient to just serve the HTML.

Yeah, but all those things make me happy. Having to wait for a web site to load a full megabyte of useless data for no reason doesn't make me happy.

This is a far stronger argument against JS-driven websites than the environmental argument.

Would you ever make the argument: "this website would be so much easier to use with a little Javascript, but Javascript is bad for the environment, so it should remain without"?

If not, the environment isn't actually a factor in the reasoning process. It's just a club to wield when it supports what you've already decided is the correct answer.

I disagree. The environmental argument is also solid one all other things being equal. It's not just a "club to wield when it supports what you've already decided is the correct answer". Even if JS only website were okay (which they're not) and as just good as plain HTML ones, the fact that the latter is better for the environment totally counts as an argument. And at least for me, trading a 10kB web page against a 1MB JS is not okay if the JS does not bring a solid positive difference.

Now I agree that in the case we're discussing, the JS actually brings a negative difference as it doesn't enhance anything and makes the website unusable without JS and thus a lot less accessible. So here the environmental factor is secondary.

I agree that the environment could in principle be a tie-breaker. But it's such a weak argument that in practice, whenever all other things are not equal, the environment is not going to tip the scales from one side to the other. And all other things are not equal, because the environmental effects don't happen in a vacuum, they're correlated with all sorts of other things. So anyone bringing it up is just using it to support the answer they've already decided on.

Suppose the environmental impacts of the HTML-only page and the JS-driven page were flipped, but the user experience remained exactly the same - the JS-driven page still takes longer to download, uses more memory, and doesn't work unless JS is enabled; but it's marginally better for the environment, by the same amount that the HTML-only page is better in the real world. Do you now think the JS-driven page is preferable?

If not, you don't get to use the environment to argue for the HTML-only page. It doesn't sway you, so you shouldn't use it to sway others.

About your first §: Your way of thinking is worrying to me. Global warming is no joke.

About your second §: your example makes absolutely no sense, and additionally it's not at all an "all other thing being equal" case. But if I had to attempt to answer you anyway, I'd say that in that case the fact that the better environmental impact of the JS-driven version is an argument that it has for it, and at least lessen the difference in the overall evaluations of the two options.

I'm not treating global warming as a joke. I'm treating the environmental impact of javascript-driven webpages as not worth taking seriously.

If you want to take it seriously, I recommend quantifying the impact as a first step. If your calculations show it's worth taking seriously, I'll happily change my mind.

"lessen the difference in the overall evaluations of the two options" is not enough. "This is a serious factor that I care about and you should care about it too, but if it was completely reversed, that wouldn't actually change the outcome": I'm not buying it.

Until you notice that just visiting Facebook keeps a 10-30% load on your CPU while doing nothing. Now imagine how many people are using Facebook.

Of course, but the comparison is a bit unfair. If you need a car to go to your workplace you can't really do otherwise. Here it is mostly trivial to make a better choice, and webpage loading and rendering would be faster, it only has advantages.

That's not an equivalent analogy.

Disabling JS displays nothing at all, while changing text and background color is a progressive enhancement.

Content should still be accessible without JavaScript, even if, perhaps, in a less convenient way, i.e., every click reloads the entire page

It's like saying a company should be present in each and every market. It might or might not make business sense to do that. Same with JS - it might or might not make sense to support non-js browsers, based on your target audience.

The Web was not meant to run on specific markets, platforms or browsers.

It's the World Wide Web. Being accessible to everyone is the whole point.

We have other platforms that target specific markets. That's fine. But we only have one Web.

I quite often use Lynx[1], which does not support JS.

[1] https://en.wikipedia.org/wiki/Lynx_(web_browser)

You and GP are missing the point: the site uses an ocean-liner's worth of JavaScript in order to do anything at all. HTML is also a core web technology and is arguably more "core" than JavaScript.

Does every screen reader have Javascript?

Screen readers integrate with browsers, they don't implement an entire browser on their own, so yes.

It's not specifically against JS, it's a matter of parsimony. One shouldn't require more than what's needed for the job. KISS. Of course, most of us fail to perfectly abide by that, but the principle is solid.

But why? Who made the rule that websites should work without JS? Content being accessible without JS is best practice. I get it and it was very valuable a long time ago. It comes in handy sometimes today but for most of the internet accessing world, working without JS is not a requirement. I do not get why people ding products for not working when JS is not enabled.

> Who made the rule that websites should work without JS?

It's not an arbitrary rule, it's just that they always have.

That's the hole point of progressive enhancement, you don't start requiring some technology as soon as it reaches x% market share and ignore the remaining minority. You build on top and offer a better experience to those that can or want.

In the apps world, it's usual to draw a line on a set of minimum system requirements and expect that line to move forward as the years go by.

But this is the Web, being accessible should be a priority.

It's still valuable unless your time is worthless.

Pages load faster with JS disabled, show less advertisement and no popups. Browser processes take less memory. Social network tracking scripts (usually disguised as share buttons) do not work. Annoying fixed headers, footers and sidebar usually don't work without JS too.

I got used to this comfortable way of browsing the web and seeing more sites that don't work without JS doesn't make me happy.

I think the disconnect is that people have conflated websites with web applications. I fully expect an application to use JS because essentially you're providing (or attempting to provide) desktop-analogous functionality in the browser.

However a "website" has the purpose of 'displaying information' -- essentially some form of text + images akin to a newspaper page. In those cases JavaScript is an enhancement but ought not be a requirement.

For a web application though, not using JavaScript is like a car pulled by donkeys. Sure you can sit in it and try to steer but it doesn't provide optimal functionality.

However on the other hand, anyone expecting a good web experience in 2016 without JavaScript is fighting a Quixotic battle.

You are right. There are web applications (like Google Docs) and simple collections of web pages (a typical Wordpress blog). I am not against JS or SPA architecture generally but I am against using complicated solutions for simple problems. Using rich frontend application to display just a list of links is obviously over-engineering.

So you're in a memory-constrained environment, you can't be bothered to block social network tracking scripts by another means (some of those still load as pixels so you haven't gotten rid of them entirely), you don't like fixed headers, footers, or sidebars, and you're taking it all out on this site because the fastest way they could bang out their little idea did not include server-side rendering in the initial iteration.

You're making a conscious decision based on the trade-offs at hand and saying that every website should double down on server side rendering to cater to your intolerance of how modern web browsing works. That's just not feasible.

3 billion people are in a bandwith, memory and CPU-constrained environment. 99% of websites can be written with or a minimum of javascript or not at all without losing any meaningful functionality.

But the website is down right not. Everything is resource constrained environment. With exposure to larger traffic hitting various services comes experience to not do things like that. Somebody had to keep the world running and some of us do care for proper engineering approaches.

I have a feeling that with Chrome any environment gets memory-constrained pretty fast. I have 3 (three) gigabytes of RAM (that can hold over 3 billion bytes inside) available to OS, is that not enough?

Most technologies can be wrangled to do pretty much anything, but that doesn't mean you should use them. Every browser since I was a child has had a download manager of some kind built in, but that didn't stop the last academic paper website I tried to use from writing their own using a java webapp, of all things, and refusing to let me download their pdf's with anything else.

If your site looks like garbage when I turn the javascript off, fair enough. If your site breaks because it needs to do client side process, then that's on me, fair call.

But if your website can't even load text without javascript, then you're using a carpenters square as a hammer. Loading text is what html does. That's it's one and only job, and it's really fucking good at it. Way better at it than javascript is.

If your website cannot load text without javascript, you're a shitty developer, because you're rejecting the objectively correct tool and shoehorning a far more complex tool into it's place. That's how you get security vulnerabilities and high maintenance costs. It's the very definition of over engineering.

Requiring JS support to display a list of links is like requiring a user to download an application to view the site. No sane person would do this, right? Oh wait...

Complaining that pages are black because you disabled CSS is a legitimate complaint. Plenty of people need to modify or disable or ignore CSS for accessibility reasons.

If JavaScript is an essential Web technology to you you are a bad Web developer.

If you're using tons of bloated Javascript "just because" for something that could arguably work with just static pages, you're doing something very very wrong.