Replacing Javascript with Just HTML
Key topics
The debate rages on: can we ditch JavaScript and stick to just HTML for certain tasks? Some argue that starting with simple HTML solutions, like autofilters, is a great way to avoid unnecessary complexity, only adding JavaScript later when needed. However, others counter that this approach can lead to inconsistent user experiences across browsers and devices, and that anticipating potential issues from the start is crucial. As one commenter put it, adding complexity upfront to ensure a smooth experience for all users might be worth it, even if it means deviating from the "simplest solution first" mantra.
Snapshot generated from the HN discussion
Discussion Activity
Very active discussionFirst comment
18m
Peak period
99
0-12h
Avg / period
16
Based on 160 loaded comments
Key moments
- 01Story posted
Dec 27, 2025 at 8:07 PM EST
13 days ago
Step 01 - 02First comment
Dec 27, 2025 at 8:25 PM EST
18m after posting
Step 02 - 03Peak activity
99 comments in 0-12h
Hottest window of the conversation
Step 03 - 04Latest activity
Jan 4, 2026 at 10:10 PM EST
4d ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
It's good to know these things exist so there are alternatives to reaching for a fat react component as the first step.
Then you're stuck with a bugfix's allotment of time to implement an accessible, correctly themed combo box that you should have reached for in the first place, just like what you had to do last week with the native date pickers.
I think it's important for web devs to spend more than two seconds to think if the complexity is necessary from the get-go though.
_*Downvote if you must but it's the truth!!!!_
https://developer.chrome.com/blog/styling-details
I can’t think of a use case for this aside from a “expand/collapse all” button (which I can’t recall ever having seen in the wild for an accordion)
Really don't see what your complaint is.
https://developer.mozilla.org/en-US/docs/Web/API/HTMLDetails...
I hope the command attribute (https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...) will eventually support this out of the box. In the meanwhile you can write a single custom --toggle command which is generic and works with any toggleable element
`open` works just like checked for a checkbox input. You can set the initial state in HTML and CSS can respond to changes in the attribute if a user clicks it. Markup won't have programmatic control over the attribute by design, that's always done in JS by modifying the element instance.
[1] https://developer.mozilla.org/en-US/blog/html-details-exclus...
On a different note, trying to use an accordion this simplistic is quite terrible.
https://jsfiddle.net/8m0t5af6/
Or this?
https://jsfiddle.net/8m0t5af6/1/
Not very nice.
Animating the details element is tricky. By the spec, browsers don’t natively support transitions between display: none and display: block.
In general I find animations on the web overused and unnecessary
Animations are like bass in music: most people notice them only when they're missing or bad.
My iPhone 15 can’t even catch my first 1-2 keystrokes on the keyboard, multiple times a day, but boy howdy does it have the time and the cycles to animate that f*%ker into view. The disrespect for my time and my needs is so obvious.
So far as I can tell, all that the stakeholders want from the UI, animations included, is pizzazz.
I (very derisively, I'll admit) assume people who like UI animations are simpletons who don't actually use computers to do real work.
I stopped being enamored with "cool" UI a long time ago. I just want it to get out of my way and let me get on with getting my damned work done.
Another gotcha you'll run into is animating the height. A couple other new features (`interpolate-size: allow-keywords` and `::details-content`) will let you get around that. [2]
Modern CSS is awesome.
[1] https://developer.chrome.com/blog/entry-exit-animations
[2] https://nerdy.dev/open-and-close-transitions-for-the-details...
The designers I've worked with are fine with these things. We have more important things to work on than small style details. We can go back and change these things later if anyone actually cares, but generally nobody ever does.
I suppose though that we have just had very different life experiences, as that is what the HN guidelines would require of us.
I have also met a lot of completely unreasonable designers that would insist on the most minimal things (even to the detriment of usability), and would act like assholes towards developers.
I have also had situations where developers would beg to work with a certain designer because their experience made development a breeze, even for complex layouts. Funny enough, the projects where this designer worked would always get done, and the visual result was always great.
The biggest gap is Chrome versions > 2 years old.
[1] https://caniuse.com/?search=%40starting-style
You’ve described software.
If you use something enough you'll remember. If you don't, you just look it up when you need it. This is basic programming, nobody remembers everything.
This is the HTML version, it's not susceptible to halted execution, and it is accessible.
<details>
</details>Because I've written my share of javascript-from-scratch in my time - before npm and such. And even if my use-case was limited, in order to get edge-cases and details working - issues long solved by their HTML/CSS counterparts - we needed more and more JS. Many of which handwritten polyfills, agent-detection, etc.
Seriously, things like scrollbars (because the client insisted on them being consistent across user-agents) or dropdowns (because they had to be styled) "visited" state on links, in pure JS are thousands of lines of code. Maybe not today, anymore, IDK, with current APIs like the history API or aria labeling. But back then, just in order to make the dropdown work with screen readers, or the scrollbars react well to touchpads -in the direction the user was used to based on their OS- took us thousands of lines of JS, hacks, workarounds and very hard to follow code - because of the way the "solutions" were spread out over the exact right combination of JS, HTML and CSS. Edit: I now recall we got the web-app back with the comment "When I select "Language" and start typing "Fr" I expect French to be picked and "enter" to then put the language in French". We spent another few days on functions that collect character inputs in memory and then match them with values. All because "flags in front of the names were of crucial importance".
So, maybe this is solved in modern HTML/CSS/JS. But I highly doubt it. I think "some straight-forward ... JavaScript" is either an `import { foo } from foobar` or a pipe-dream in the area of "programmers always underestimate hours"
Now, I think part of the problem is that such elements weren't architectured properly when invented. Like many other HTML elements, they should've had some way to style and/or improve them.
E.g. an H1 Header, I can apply CSS to and change it from the default to something matching the business style. Or an image can be improved with some CSS and JS to load progressively. But most form elements, and the dropdown in particular, is hard to improve.
And, yes, I am aware of the can of worms if "any element is allowed inside an <option>". Or the misuse designers will do if we can add CSS to certain <options> or their contents. Though I don't think "webdevs will abuse" was ever the reason not to hand power to them. It was mostly a disconnect between the "designers of the specs" and the "designers/builders of websites".
Because that "abuse" is never worse than what is still done en-masse: where we simply replace the "select" with hundreds of lines of CSS, divsoup, and hundreds or thousands of lines of JS. Where entire component libraries exist and used all over the place, that completely replicate the behaviour of existing (form) elements but with divs/spans, css and js. And despite the thousands of hours of finetuning, still get details wrong in the area of a11y, on mobile platforms, on obscure platforms, with a plugin, with a slow connection and so on.
Data used to be first class. You would deliver everything in the HTML container and the style sheets or client could do whatever it wanted/needed with that data.
Native search, native copy, no clever javascript tricks to hide or remove information from the document.
The HTML data container should be immutable.
Exactly. We're still pretending that the browser is some kind of document display application when it's an application runtime. We keep adding more HTML tags and infinite number of CSS properties and features (that never get it right) when what we should have as a better application GUI API. Throw all the hardware acceleration and threading into that instead of @starting-style, transition-behavior: allow-discrete, interpolate-size: allow-keywords and ::details-content and breath some sanity into the platform.
We've effectively re-implemented that desktop/mobile GUI using a bunch of cobbled together technologies and continue to get more esoteric and complicated every year. Hell, I'm not even sold on JavaScript -- it's just as clunky and weird as everything else.
Move document rendering into high-level implementation on top of a better designed low-level API much like how PDF display in browsers is done with JavaScript.
I want a hypertext document viewer.
> @starting-style, transition-behavior: allow-discrete, interpolate-size: allow-keywords and ::details-content
This is sane from a declarative document styling syntax.
Word for the web basically, but with support for multimedia.
In that sense the web has failed, there is epub but it's not really good.
2. CSS integrates better with HTML, as it has selectors to automatically bind to elements (yes there custom elements for JS)
It’s still awesome, but it’s becoming increasingly silly to ask someone to know modern HTML, CSS, JavaScript, Typescript, some build tools, a couple of frameworks, etc.
The amount of JS we ship to clients is a reflection of cost-cutting measures at your workplace, not that every FE dev shuns CSS.
** Works badly even on chromium browsers (granted I was doing weird stuff, but the animation did not work properly).
I estimate that in a few years we will have animations working properly and mostly everywhere on details elements. Not before.
You say that like it's a bad thing.
Very hot take; then don't animate them!
Animation in a UI is great - you draw the user's attention to a widget that changed because they might not necessarily notice it otherwise. This improves the UX.
With a details/summary, the animation is not needed and can only make a negative change to the UX. There is no positive change to the UX that animating the details/summary elements would bring. When it is opened it is obvious.
If you really really need to animate the details, instead of animating open/close, instead animate the summary background/text color to indicate that the element has just changed state.
Would I like easy animation of open/close? Sure. Does it improve the UX? Nope.
I'd need to look into what effect this might have on accessibility, but my gut says "very little".
It’s odd and frustrating that such an essential tag is not defined to be accessible, afaik.
There have been bugs in its implementation, particularly in Safari and differing between mobile and desktop Safari.
Thanks for correcting me.
Also I think the event isn't currently emitted consistently on all browsers (and maybe not at all for hidden="until-found"?) so unfortunately you can't quite rely on that yet if you need to sink some JavaScript state to your html. But in general, yeah, this is a really cool feature.
Supporting the behavior was related to changing the user agent CSS when they're closed and the other browsers implemented it and hidden=until-found at the same time.
https://caniuse.com/mdn-html_elements_details_search_match_o...
We can also use pure css to implement tab panels. A demo: http://tmd.tapirgames.com/demos.html#section-demo-4
Modern css is powerful.
While you can make something that visually appears to act as a set of tabs, building it accessibly unfortunately still requires JavaScript.
[1] https://adrianroselli.com/2019/04/details-summary-are-not-in...
- If you're using <details>: tabs should have an ARIA "tab" role [1], but <summary> doesn't accept roles.
- Focusing a tab must activate the corresponding tab panel [2], which requires JavaScript.
- Tabs should be navigable by arrow keys [3], which also requires JavaScript.
[1] https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
[2] https://w3c.github.io/aria/#tab
[3] https://www.w3.org/WAI/ARIA/apg/patterns/tabs/
It supports this now (with JavaScript). If not, try to refresh the page.
rather than not working at all with js disabled
This is a quite recent addition and the modern web is evolving too fast so I wouldn't put it past myself for missing this :)
Yay for progress and for JavaScript free solutions!
Writing a web server in C++ is a way to get excellent performance. So why don't most people do it?
Because they already wrote it in C.
Apache and Nginx are both written in C. Together they run 57.7% of all web servers:
https://w3techs.com/technologies/overview/web_server
In the past decade, we went full JS as an industry and now we’re starting to swing back. Server side interactivity like Phoenix Liveview, C# Blazor, HTMX, PHP/Laravel Livewire, Rails Hotwire, all of these are different abstractions around JS to make interoperability between the frontend and backend more manageable and they’ve come a long way to closing the gap. Advancements in HTML/CSS standards also deserve credit for closing the gap but we’re still not quite there yet.
But at the end of the day, the web is dynamic. As new tools and techniques are discovered, the industry will continue to evolve and certain “hacks” will become new standards and ignorant newcomers will reinvent the wheel again to achieve some crazy interactive design because they didn’t know any better! And it wil work, mostly.
Until the way we interact with browsers changes, I feel that we’ll continue to bolt on new features over time and the web will continue to evolve. Just like the iPhone, a surge of use of smart glasses could change the computing paradigm or perhaps its some other device entirely.
So you can (and should!) try to optimize for today, but trying to optimize for tomorrow will always carry the risk irrelevance if the market pivots quickly. Bleeding edge is risky but so is falling behind.
I want to read it in dark mode and give users that option, but I want to present it in light mode because dark mode suffers poorly from video compression when screen sharing.
I currently have a JS toggle for it which uses local browser storage, but ditching JS would be nice if possible.
There are things that HTML could do, and should be doing, that is not done or not yet possible simply due to hype and trend from browser vendors. We could continue to polish HTML + sprinkle of Javascript to its absolute maximum before hitting JS Apps. Right now this is far from the case.
At the end of the day it isn't really the tech that is the problem. Is how people use the tech. And for thousands of different reasons keeping it simple has always provided better experience evaluated on the whole.
Github's old frontend was mostly HTML with a bit of JS, their new frontend is react. The old UI had its bugs, but it was much better than the react version in my experience. I still commonly find the UI out of sync with itself requiring a reload, but now I also frequently wait for the page to load and viewing large diff's is a performance nightmare.
You could provide multiple image versions for zooming to get to the TB scale.
Computers are really good, performance is astonishing, no reason why we should never be able to use a TB size image. Never is a really long time.
Have epic panoramas, detailed scans from paintings, extremely easy game design and maps that just work.
The core idea with htmx is that you transfer hypertext with controls and structure built in, not just a JSON blob that requires additional context to be useful.
I have just shipped a very useful and interactive app surprisingly quickly for my customer using just htmx with a little Javascript.
All the http verbs. Decent html input controls What else?
It's great until you have a typo in the field, or want to show options that don't start with what you typed in but appear near the end of an option (think Google search's autocomplete). There's no way to filter in Javascript and force it to show certain options with <datalist>. I've resorted to <ol> for search suggestions.
116 more comments available on Hacker News