Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
I can understand JS when it makes sense. But I already stopped using JS blockers because almost all pages break somewhere without it for no good reason.
For example gog.com doesn't display thumbnails or system requirements without JS. Who the hell thought this is a good idea? It's static text and pictures. -
Froot75397yServer side rendering has its place but doing it all server side is a horrible idea.
Imagine someone with 500ms ping use your site, it's going to be slow as fuck if all logic is handled server side and there's no JavaScript on the site at all.
Also, cutting out JavaScript completely takes away things like AJAX, lazy loading, etc... SPAs would be completely impossible.
I'm in the opposite camp, I'd gladly load the site with JavaScript and do as much as I can on the spot to give a smooth experience.
Of course the logic you have has to make sense -
My opinion if it isn't a personal project there should always be a proper HTML fallback. If there isn't enough time for one then I think priorities should be reevaluated or the JS frontend version be put on hold. At least the core features and stuff like signing in, signing out, and deleting one's account should be accessible without.
But then again I'm highly biased because most JS frontends I've seen that have no HTML fallback also took a huge dump on accessibility, applying the same argument (and I don't think there is any excuse for not considering accessibility) -
ctwx3617y@robocroque although I like the idea of having a fallback version, I do think that it depends on the target audience. Also, let's take an SPA. To create a fallback you'd probably have to implement everything a second time. Soo... Hmmm. I guess it's just not worth the effort
-
@ctwx like I said, I'm mostly against it cause proper accessibility in a JS application with dynamically updating parts of the page requires a bit more work and effort, and I'd take a properly accessible site over a fancy async dynamic whooshy one any day. And well, most "fancy" projects I've seen so far have had horrible accessibility because there just wasn't time for it, even though the devs on it would've made a pure HTML version properly accessible just through routine and standards alone.
-
Froot75397y@robocroque I take people disabling JavaScript on my site basically as them not wanting to use it. Writing HTML fallbacks is like writing .txt fallbacks for desktop applications. Web is no longer just a collection of static documents. The projects I work on mostly are web apps and there is no way to make them with reasonably with a HYML fallback.
Also, developer time is limited. So if you put time into writing fallbacks you're not writing new features. Basically you're taking away from 99% of the audience to serve the 1% who disable JavaScript for some tinfoil hat reasons.
And then there's marketing. You may not care for the site's looks but most users do. Being a company you will care more about the 99% who likes nice design than the 1% who doesn't.
Of course one should take accessibility into account but that can be done very nicely with JavaScript. And no, making pages work without JavaScript is not accessibility. Making pages so blind people can use them is accessibility
Related Rants
Is client side rendering really that bad? Do you prefer sites without any JavaScript or are you ok with it?
To me it's very convenient to have JS in very dynamic pages. For things like documentation I think server side rendered pages are good enough. I mean it's 2017, right? Do we really need to care for those who deactivate JS? I mean I really like it to separate the front end backend.
What do you think?
undefined
js
vuejs
serverside rendering
noscript
angularjs