[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.