[userbinator]

The fact that it used to work perfectly fine without JS is proof enough that it don't need it. But I guess the average web deviloper is more concerned with stuffing one's resume with the latest fads than real accessibility and efficiency.

[pkage]

There's a lot of hostility on HN towards web developers. "Real accessibility" doesn't really have much to do with Javascript or not, it has everything to do with ensuring the site is screen reader accessible, ensuring the site is available for low-vision users, and ensuring that the site is available at slow bandwidths. Given that the site caters to those already (good kb navigation, stated future support for color-blindness, and the site is ~300kb/page) I think that they're in pretty good shape.

Ultimately, choosing not to run JS is your decision—but a vanishingly small percentage of users choose to do that, and as a company your focus is on providing features for the product, and not supporting every single user and their unique configurations. Should Github explicitly support terminal-based browsers like Lynx as well?

Plus, you can avoid 99% of the github website just by using git from the command line (or your favorite client) and using their CLI tool for repo creation/etc.

[arderary]

I really don't understand the glorification of no-js websites on HN. Like, I'd get it if it was Flash or something ('cause that definitely has some real accessibility issues, and required a plugin to be installed), but the web platform is HTML, CSS and JS. Why artificially limit yourself to just two? It seems to have become a matter of pride to say "works without JS", for absolutely no practical reason (it's not like removing JS is some silver bullet for accessibility, no-js sites can and do still absolutely have problems with accessibility)

[httpsterio]

JS is usually what kills performance on lower end devices. If websites were only html and css, my smartphone from 2015 would still be a functional device. I have yet to have a page crash due to too poorly written html and css.

[arp242]

It depends what you're doing with the JavaScript. This is like saying "C kills performance" because you found one slow C program. JavaScript can actually improve performance in quite a few conditions (even on lower end devices) by preventing full page reloads and such, which adds more overhead in the network, HTML parsing, etc.

[httpsterio]

If we're talking about saving bandwidth, JS can be useful, although JS bundles are usually heavier than their HTML and CSS counterparts.

I have yet to see an example where rewriting the DOM would end up being lighter on devices with lower-end CPUs and RAM than doing a full page refresh. Browsers already cache static assets, generally a page refresh only takes a second or two (on reasonable connections)

[boogies]

A great example of this: compare Sourcehut to GitHub or any software forge that requires JS.

https://forgeperf.org/

[pferde]

I have nothing against Javascript when it improves the overall result. However, when I come across a site which consists of text articles interspersed with some static images, and the images do not show with JS disabled, or in extreme cases, the entire page remains empty because it needs JS to even display text, that just screams wrong.

Web has been able to display well-formatted text and images for decades without Javascript just fine. In fact, that has been its original primary purpose, to display text with hyperlinks and some images. Why bastardize it just because you want your images to load with a cool effect or something equally silly (that won't work well for half of the visitors anyway) ?

[fouc]

> There's a lot of hostility on HN towards web developers.

You're conflating different types of web developers here.

There's only hostility towards the sub-set of web developers that focus only on what is expedient while sacrificing user-friendliness. The ones that hop on the latest and greatest buzzword technologies in order to pad their resumes.

[userbinator]

There's a lot of hostility on HN towards web developers.

Why shouldn't there be, when they're the ones breaking things that used to work perfectly fine, and then reimplementing them half-bakedly while consuming an order of magnitude more resources than before?

Should Github explicitly support terminal-based browsers like Lynx as well?

Why does it have to be "explicitly support"? Whatever happened to using the simplest technology possible for the task? That way you'll end up with a page that will work to the best possible extent for any given user-agent. That is ture accessibility.

I'm not asking for them to go out of their way to try to show images in Lynx or whatever. I'm asking for a sane approach to making sites that does not require running arbitrary code on the client just to show some static text that should've come along directly in the page, something that literally all browsers would be able to, but is being needlessly restricted.

Plus, you can avoid 99% of the github website just by using git from the command line (or your favorite client) and using their CLI tool for repo creation/etc.

That is true, but beside the point.

[SquareWheel]

> they're the ones breaking things that used to work perfectly fine

And it still works perfectly fine. You've purposefully modified your browser to not respect web standards. Any error is your responsibility, not theirs.

[zelon88]

To some extent I agree with this sentiment. Not so much the Javascript aspect, although I've always viewed JS with the "less is more" mentality myself. I understand that it's become a critical part of the web, so that's not really where I agree with you.

I agree with you more on the "breaking things that used to work perfectly fine." To me this has nothing to do with "accessibility." If I recall correctly, a couple years ago the header was white, then they changed it to grey.

While I feel like giving users more theme options and more control over their UI is the right direction to go in and one that adds value, I can't help but think that this is just the design team keeping themselves busy/valid.

I followed their design team on social media for a brief period until I realized that all they do is hold senseless confs with the same people over and over again to discuss the same things over and over again. None of them have real code in their repos, just markdown and HTML and stylesheets. None of them contribute to 3rd party projects. Then they iterate something nobody was complaining about. I just feel like these are resources that would be better spent elsewhere.

[viraptor]

Please take a step back for a moment and imagine that you're one of the blind users of HN running into this comment. Reading that GitHub devs who took the time to actually support some assistive technology on their website (not sure how well, but see the existing aria attributes in the source) and track their support (https://government.github.com/accessibility/) don't care about "real accessibility" by not catering to what technology choices you prefer.

[userbinator]

If they had actually used a sane approach, I bet their accessibility score would be even higher, and even fewer people would be complaining.

[fooey]

The idea that the web should work without JS has been dead for a couple decades now.

It's a barely less laughable demand than expecting everyone to use a CLI over a GUI.

[sneak]

That's not true. The idea that the web should gracefully degrade and continue to display content in browsers of all types has been live for... the entire existence of the web.

There is a new trend to expect all clients to run js, yes, but that is a bad assumption.

[fooey]

I understand that is an ideal, but "browsers of all types" is utterly unrealistic, and hasn't been the case in the wild since the 90's.

Not only does the modern web expect you to be running JS, you're expected to be running a browser that's at most 1 version off the most recently released version. Supporting only evergreen browsers might just be the best thing that's happened in web development.

Graceful degradation was a thing for a very brief period in the lifetime of the web, and hardly anyone actually had the resources or inclination to even pretend to attempt it.

[echelon]

We got conned into this shitty world where HTML shovels ajax and giant JS payloads.

Old web was information and a theme could be written locally and applied to everything.

New web is almost as trashy as the App Store.

edit: my imagination is vivid, and it doesn't end at React and the iPhone. We can do so much better. Semantic information markup without ads and presentation details. Shared p2p, unsiloed. Completely free.

[sneak]

I browse the "modern web" with js off by default, and much of it still works fine.

The only part that doesn't, which saddens me, is that there is no way to do U2F auth without js.

[p1necone]

You seem to be using a different definition of accessibility than the commonly accepted one. What disability precludes the use of javascript?

[userbinator]

Accessibilty and disability are related but not the same.

Making a website more accessible is beneficial to everyone, not only those with disabilities.

[p1necone]

You're arguing semantics. The web development community (and the engineering industry as a whole) uses the term "accessibility" to refer to making things usable by people with disabilities (and has done so for decades).

Pretending that people understand the term to mean a different thing, and then screeching at them for not doing that how you want them to is intellectually dishonest and just makes you look like an asshole.

[userbinator]

I'm talking about the original definition of accessibility, not the one the "community" decided to pervert for its own interests:

https://en.wiktionary.org/wiki/accessibility

    The quality of being accessible, or of admitting approach; receptiveness

As another link posted elsewhere in here shows, it seems accessibility has turned from striving to make sites more accessible to everyone, to doing the bare minimum legally required by disability laws.

[sellyme]

"real accessibility" predominantly involves making it possible for people with disabilities to use a website, it's not about accommodating people who put a blindfold on and complain that it's difficult to see.