Hacker News Reader

Comment by ly | Hacker News Reader

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

View on HN

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

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

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.

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.

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

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.

Reply on news.ycombinator.com