Things you don't need JavaScript for

6) Sending data but staying on the current page.<p>You can make links or forms submit but <i>not cause browser navigation</i> by having your server respond with a 204 No Content.<p>I feel like this is a completely forgotten technique, but we used this a ton pre-AJAX for little one off things to shoot a message to the server without interruption.

1–4 are good, but 5 is not. The checkbox hack is decent in a few places (though I’d say &lt;details&gt; is normally a better choice now, and the checkbox hack should be accompanied by certain ARIA properties and <i>augmented</i> with some JavaScript to twiddle properties as it’s used), but dark mode is not one of them. The checkbox hack is only suitable for transient state that you actively don’t want to persist over page loads. Probably the most popular historical application of it is hamburger menus (but &lt;details&gt; or `:hover, :focus-within` are better for that now). I think a more reasonable solution for dark mode is the media query (prefers-color-scheme: dark), following the browser preference by default and augmented by JavaScript to allow overriding that. <a href="https:&#x2F;&#x2F;chrismorgan.info&#x2F;blog&#x2F;dark-theme-implementation&#x2F;" rel="nofollow">https:&#x2F;&#x2F;chrismorgan.info&#x2F;blog&#x2F;dark-theme-implementation&#x2F;</a> describes my own implementation, which is the most comprehensive and efficient client-side-only implementation that I know of, as perfect as it’s possible to be while being client-side-only and without getting into service workers.

2 (Sidebar) is not usable on mobile, because there is no good hover event. Since mobile-first is almost a necessity, it won&#x27;t work this way.<p>Accordions make most sense as a table of contents, although they are often used in FAQs. But in FAQs, you can&#x27;t use the browser&#x27;s search on page to find collapsed words. So you trade better scrollability for searching on the page. Not sure how many people use &quot;search on page&quot; on mobile devices though.<p>1 + 3 are great though.

This is a very good article: it explains each point clearly and also includes clear and appropriate code examples. I personally love using modern CSS as much as possible, as opposed to javascript, since it allows separating the visualization and functionality from each other. Of course using pure CSS can also offer noticeable performance benefits.<p>The thing the article seems to be missing is an explanation about when <i>not</i> to use CSS. In my experience there&#x27;s a lot of scenarios which could be solved with pure CSS in theory but in the end will be implemented in javascript.<p>The first reason is browser compatibility. If older browsers need to be supported (unfortunately IE is not completely dead yet), many CSS based solutions are just not possible.<p>The second reason is changing requirements and future-proofing. Often only the simplest requirements can be fulfilled with a pure CSS solution. When more requirements are added or the feature needs to be extended in any way, the only possible solution is to just completely scrap the CSS solution and re-implement it in javascript. I feel this happens so often that most web developers just prefer implementing the feature in javascript straight away because they know it will be easier to change later if needed.

&gt; PSA: position: sticky; exists now.<p>I joined this company that has a 10 year old Dojo application as their UI. Before I joined they had a guy come over once a week for some maintenance work. They spent several days trying to solve an issue where a bar with a &#x27;save &#x2F; close&#x27; action would show up at the bottom of a dialog, making users scroll down. This was a complaint that users had for literal years.<p>I added position: sticky and had to figure out how it worked, but the issue was resolved with about ten minutes of work. Not to pat my own shoulder too much, but that was pretty cool. Plus it works gracefully, in that if the browser doesn&#x27;t support it yet, it falls back to (or, should) to the old behaviour.

I mean I hate JS as much as the next person. Also, for my blog I wanted to use as minimal JS as possible. But when it comes to a sidebar I don&#x27;t think adding a few lines like this is soo bad.<p><pre><code> &lt;script&gt; const button_close = document.querySelector(&#x27;#menu-button- close&#x27;); const button_open = document.querySelector(&#x27;#menu-button- open&#x27;); const menu = document.querySelector(&#x27;#menu&#x27;); &#x2F;&#x2F; Menu button_close.addEventListener(&#x27;click&#x27;, () =&gt; { menu.classList.toggle(&#x27;hidden&#x27;); }); button_open.addEventListener(&#x27;click&#x27;, () =&gt; { menu.classList.toggle(&#x27;hidden&#x27;); }); &lt;&#x2F;script&gt;</code></pre>

You shouldn&#x27;t be using a checkbox for dark mode (at least not as the main toggle). You should be using the css prefers-color-scheme media query so that you use the users default with no required interaction and no bright flash of white.<p><a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;CSS&#x2F;@media&#x2F;prefers-color-scheme" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;CSS&#x2F;@media&#x2F;pref...</a>

Also: <a href="http:&#x2F;&#x2F;youmightnotneedjs.com&#x2F;" rel="nofollow">http:&#x2F;&#x2F;youmightnotneedjs.com&#x2F;</a><p>And: <a href="https:&#x2F;&#x2F;kryogenix.org&#x2F;code&#x2F;browser&#x2F;everyonehasjs.html" rel="nofollow">https:&#x2F;&#x2F;kryogenix.org&#x2F;code&#x2F;browser&#x2F;everyonehasjs.html</a>

I really wish developers would just ask themselves if a feature is actually necessary before trying to create it without JS<p>For example, you can make an accordion menu with plain HTML, but <i>should you</i>? Accordions are horrible. They just hide information. 20 years ago an accordion was a design pattern that made <i>a bit</i> of sense - scrolling meant moving the mouse to the scrollbar or pressing Page Down which took you out of the reading flow on the page. Not to mention screens were tiny so a long page didn&#x27;t work very well. Today though, users can scroll easily with a mouse wheel or a swipe, and screen are much bigger. Just show the text and let the user scroll past it.<p>CSS-derived dark mode is another example of &quot;Yeah, <i>you can</i>, but it&#x27;s a bit rubbish.&quot; The site won&#x27;t retain the user&#x27;s choice if you use plain CSS which is pretty horrible. Either use JS, or use your build step to bake two versions and serve them on different URLs like &quot;&#x2F;dark&#x2F;page-1&quot; and &quot;&#x2F;weird-bright-mode-wtf&#x2F;page-1&quot;.<p>The off-canvas menu and sticky bar are quite nice, but again it does feel like developing something that could be better without any clever CSS or JS through sensible design choices.

This is what we need , more native functionality instead of insane levels of JavaScript. But we also need sane standards instead of more for no reason. How many CSS units are there now? 20? And things like css grid just don&#x27;t look right. We need to make html and the web approachable by the common man, again

Another one that really bombs UX is using javascript for the site navigation in general. That is, instead of<p><pre><code> &lt;a href=&quot;&#x2F;some&#x2F;path&quot;&gt;Place&lt;&#x2F;a&gt; </code></pre> They will do something like<p><pre><code> &lt;a href=&quot;#&quot; onclick=&quot;window.location.href=&#x27;&#x2F;some&#x2F;path&#x27;&quot;&gt;Place&lt;&#x2F;a&gt; </code></pre> (or whatever the current equivalent is in framework <i>du jour</i>) Making it impossible to right click the link and open a new tab. Yo, I need to be able to reference data from multiple areas of the application and your javascript is making that really hard to do! I know that you can do this properly in javascript, but it would appear that at least some people have not gotten the memo. So I&#x27;m going to say - you don&#x27;t need javascript for navigation.

Meanwhile, many websites decide to deliberately hide their content from you if you don&#x27;t allow them to run JS. Not out of necessity - purely out of spite. Like a div that obscures the content, or styling that makes content invisible by default and requires JS to become visible.

Sidebar and sticky examples don’t work on iOS safari on iPhone. I’m pretty sure sticky can be made to work. Sidebar would need a different technique since “:hover” is not a thing there.<p>In general I like the concept of not using js unless you have to, but it’s important to consider mobile.

Do most frontend devs in 2022 even know CSS?<p>They might know tailwind or bootstrap, but I doubt they even know what kind of HTML their react component library is producing, let alone have the capability to style it.

CSS animation look cool but do we have a way to debug css performance issues? Last time when I had to fix this I found not tool so the solution was look at the CPU usage and remove the elements you think are problematic until CPU usage goes to 0%.<p>Is super easy for someone to screw things up and cause a 25% CPU usage and not notice it on his dev machine.<p>After this incident my rule is to always triple check in code reviews any animation that has &quot;infinite&quot; in it (though I am mostly a backend dev)

Just a pet peeve: Sticky headers or footers that overlay scrolled content are bad, because they interfere with jumping to page search results and anchors, as browsers do not take into account that the target may be hidden by an overlaid element.<p>=&gt; If you use sticky headers&#x2F;footers, lay out the other content so that it isn’t overlaid by those headers&#x2F;footers.

Came here for &quot;things I don&#x27;t need Javascript for&quot;, from there flowed into Lexoral as a product (pretty cool) and then into the architecture behind it which was interesting. Nice ride.

&gt; &quot;3. Sticky Positioning&quot;<p>Yes but javascript can enhance a sticky top nav by watching the scroll position and updating the nav with whatever is intended by design, relative to the scroll position or direction. Such as hiding&#x2F;showing or doing something else in response.<p>Even though it might still function as a basic nav without js, if I made a movie and found out people were watching it with &quot;special effects turned off&quot; it wouldn&#x27;t be fun to learn that about the audience.<p>&gt; &quot;1. Animating SVGs&quot;<p>Cool, but the more interesting animation possibilities are javascript driven. Like when using timing, waiting, chaining multiple animations, and responding to user interaction or other events. Need javascript for dynamic animation.

What about compatibility with browsers? CSS can do a lot that JS can but sometimes it just won&#x27;t work on all browsers. For example the SVG animation on the page doesn&#x27;t seem to work for me?<p>Also for animation it depends on the use-case. Complicated animations are better suited for JS than CSS <a href="https:&#x2F;&#x2F;developers.google.com&#x2F;web&#x2F;fundamentals&#x2F;design-and-ux&#x2F;animations&#x2F;css-vs-javascript" rel="nofollow">https:&#x2F;&#x2F;developers.google.com&#x2F;web&#x2F;fundamentals&#x2F;design-and-ux...</a><p>I recall trying out a complicated SVG animation and it used a decent chunk of CPU time

But I don&#x27;t really want that. I hate that my code is spread out over HTML, CSS and Javascript files, it makes it hard to see the whole.<p>Javascript offers ways to do everything only in Javascript. That&#x27;s wonderful.

You can also build all kinds of toggleable things with hidden &lt;input&gt;s, &quot;+&quot; sibling selectors, and &lt;label&gt;s to activate the inputs. For example, an accordion that only has one section expanded at a time can be made with hidden radio buttons next to each item. Or a navigation drawer&#x2F;sidebar can be made with a hidden checkbox. Any kind of spoiler-style &quot;click to reveal contents&quot; sort of thing can also be made with a hidden checkbox, it&#x27;s more flexible than &lt;details&gt;.

Hover doesn’t work with touch screens and I wish &lt;details&gt; state was manageable by CSS for responsive pages.

Something I&#x27;m struggling to implement at the moment is image carousels. I don&#x27;t necessarily need something that has full functionality without JavaScript, but it would be nice to provide some kind of progressive enhancement, and make something that works both on desktop and mobile.

I was consulting for a startup once and the owner asked me to create an examination he could use to screen front-end &quot;developers&quot;. Question #1 asked the applicant to create a modal dialog without using Javascript. He told me that question filtered out several candidates.

You dont need Javascript to add margin on a website, yet this website cuts off the text on mobile.

I understand that the .dev TLD is not supposed to support unencrypted HTTP (i.e. it is HTTPS only), browsers are supposed to know about this, and in fact the main ones supposedly do.<p>I wonder if we could also have a .restricted TLD that doesn&#x27;t support javascript, the more invasive of these CSS hacks, transclusions of any sort except from the same domain, or cookies persisting longer than the browser session. That would make it a lot easier to have reasonable security assurance about pages with private contents, at the expense (or rather, the added benefit) of not being able to have blingy javascript effects on the page.

The dark mode checkbox in this example doesn&#x27;t remember my selection if I refresh the page. So wouldn&#x27;t you need JS for it to follow you both across the domain and also upon page refresh?

I was working on a hobby project recently and wanted to do it without JS. For some reason, I thought there was a way using HTML forms to form a URL.<p>That is, imagine I have two `select` dropdown with a set of numbers in each, and a `submit` button. I thought there was a way to construct a target url based on the values of `select` without using JS. So you might select &#x27;2&#x27; and &#x27;5&#x27; from the dropdowns and hitting submit would send you to &#x27;mysite.com&#x2F;2&#x2F;5&#x27;. As far as I can tell, I was wrong. Anyone disagree?

Can only agree with this article! Details&#x2F;summary, position sticky and the checked toggle are my favorites (position sticky needs some attention though).<p>It pays of to check for new HTML and CSS tags&#x2F;functions once in a while. Have been a (web)developer for some years now, and it&#x27;s only since recently that I found all these things. The amount of JS that I could ditch was astounding to me. Just liberating.

&gt; This isn&#x27;t just a toy example either. The browser will automatically remember the checkbox state, meaning you can save the user&#x27;s preference for free - try ticking the box and refreshing this page!<p>Aside from the typical complaints that you should be using prefers-color-scheme instead… This doesn’t work for me. Is it supposed to leverage autocomplete or something?

Number zero: Reading text.

Worth noting that using `transform` can cause performance issues in some cases, especially if the element being transformed contains many heavy children. This is something that can come back to bite you later on if you rely on `transform` techniques too much.

A bit ironic that 4 out of the 5 don&#x27;t seem to work in Firefox on macOS.

My browser didn&#x27;t remember the dark mode checkbox state after reloading.

One thing you really cannot do with javascript: write an alternative &quot;working&quot; web browser (noscript&#x2F;basic (x)html) as a small team of devs (or an individual) in a reasonable amount of time.

The website is totally broken for me on mobile safari. 1 and 2 don’t work, and the lack of overflow:hidden causes a huge horizontal scrollbar…<p>I’d recommend more testing before using. Though the details element is great.

Why, you don&#x27;t need javascript for anything.<p>Maybe for killing the user&#x27;s battery?

Things you don&#x27;t need on your webpage: accordion menus.

Creating frontends. You can use Java&#x27;s JSF for that (it has js under the belt but you don&#x27;t need to touch it).

No love for classic menus and similar controls using the :target selector? Might be as old as the hills, but still ...

I couldn’t interact with the sidebar on mobile. It kept either reloading the page or scrolling to the top

I can&#x27;t seem to get the firework example working. Is this supported on Firefox?

unreadable on mobile

I love how a page criticising web developers is unreadable on my phone because one centimeter of text is cut off on the right (:

&gt; doesn&#x27;t overdose on javascript<p>&gt; overdoses on css instead