[ly]

I disagree with "responsiveness never". Imagine you have a "tabs" component on a page, each tab has some text (for example [1]). With javascript, you can hide the content of the first tab and show the second tab on click, almost instantly.

Without javascript the second tab would be a link to another HTML page where the second tab is shown. Exact same behaviour for the user, however the one with a few lines of javascript will feel way more responsive than the one without, where the user has to wait for a new page to load.

[1] https://getbootstrap.com/docs/4.0/components/navs/#javascrip...

[theandrewbailey]

Without Javascript, the tab can be a label that activates a radio button next to a hidden div that also has a input:checked~div { display: block;} CSS on it. No Javascript required.

https://codepen.io/dhs/pen/diasg

[ly]

Yeah, you're right that simple tabs can also be implemented using css, but I still disagree. Another example: how about a simple search on a table [1].

In this case the search is instant. Without JS you would have to have a submit button and wait for the request. Even if you also added a button the JS version it would still feel more responsive, as again, you're not waiting for the request.

[1] https://www.w3schools.com/howto/tryit.asp?filename=tryhow_js...

[lelandbatey]

I'm not sure I've ever seen a case where I have a data set that's small enough to be quickly searchable (and quickly re-renderable) using client-side JS but big enough that I need dedicated and app-like sort, search, or query functionality. And where such a set of data to exist, that data set would almost certainly be _growing_ with time, meaning even if it started out as something where I can have snappy JS search, as time passes the JS search grows heavier and slower through time.

Additionally, when it comes to client-side spreadsheets I have seen far more terrible half client-side, half server-side implementations (being only able to sort within a page, instead of across all pages of results). If I had to choose one, I'd choose a world were all we had were server side spreadsheets.

[ly]

I’ve implemented front-end (fuzzy) search in multiple projects over the years. When the dataset is known to be small enough it’s great.

I have also seen the horrible half/half implementations you mention where it should have just been implemented on the server side, and I totally agree with you there.

However it was just an example to show that a unsubstantiated blanket statement like “responsiveness never” is just wrong. I’m not saying doing search in JS is always (or even often) better, but it can be sometimes if done well.

[robertoandred]

And that’s absolutely terrible for accessibility. Cute clever hacks are rarely actually good.

[reaperducer]

almost instantly

Or you can do it in CSS actually instantly.

And no, complexity generally doesn't negate this. Earlier this year I built a series of complicated medical forms for a healthcare web site that are all HTML + CSS + < 2K of jsvascript, and they all respond instantly because I did't lean on JS to do everything.

The pages are fast, responsive, work on any device, almost any bandwidth (think oncologists in the basement of a hospital with an iPad on a bad cellular connection), and the clients are thrilled.