12 ms·

Replacing JavaScript with Just HTML

748 points by soheilpro 10mo ago

theandrewbailey 10mo ago
> Input with Autofilter Suggestions Dropdown 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.
emseetech 10mo ago
When building out a new app or site, start with the simplest solution like the html-only autofilters first, then add complex behavior later. It's good to know these things exist so there are alternatives to reaching for a fat react component as the first step.
- deleted 10mo ago
  [deleted]
- willparks 10mo ago
  It’s great to see practical examples that push us to consider what the platform already offers before adding more layers of complexity.
- zdragnar 10mo ago
  Until your client tells you that it doesn't work in Edge and you find out it's because every browser has its own styling and they are impossible to change enough to get the really long options to show up correctly. 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.
  - deleted 10mo ago
    [deleted]
    - rerdavies 10mo ago
      Have you no sense of craftsmanship?
  - emseetech 10mo ago
    Right, don't add complexity until you have to.
    - abustamam 10mo ago
      I'd argue that adding complexity from the get-go to ensure that all users have a pleasant experience from the get-go is better than simplicity at the expense of some percentage of users. 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.
      - emseetech 10mo ago
        When building out a new app or site, which means a percentage of zero users is zero.
smlavine 10mo ago
The Pentagram at the top of the page does not load without JS enabled.
- bitbasher 10mo ago
  So it's.. fitting, how meta.
superkuh 10mo ago
Some of these new HTML features don't fully work in my "ancient" browser. But all of them partially work (ie opening the accordion element doesn't close others but it still opens and closes) and they still remain functional elements I can read and interact with. This puts them far ahead of any javascript implementation which almost universally fail to nothing.
- ravenstine 10mo ago
  What "ancient" browser are you using?
  - vpShane 10mo ago
    Probably something 300 CVEs ago.
eleventen 10mo ago
The details / summary thing absolutely kills me. There’s basically nothing you can’t do with them. Hiding and replacing markers is easy. But every component library just pretends they don’t exist. It even saves you the effort of all the aria control and expanded tags: these tags don’t need them.
- webstrand 10mo ago
  Details works even when it's set display:contents too, for even more flexibility. Can't animate from open›close, yet, though. That's pretty much my last frustration with it.
  - shakna 10mo ago
    I think the CSS support for that has finally landed, though it means targetting a pseudo element instead. Its been a year, so support is probably good enough you don't care if just the animation doesn't happen. https://developer.chrome.com/blog/styling-details https://developer.chrome.com/blog/styling-details
    - lelandfe 10mo ago
      Note that the transition to `auto` in that post relies on `interpolate-size` which has yet to land on Firefox or Safari, and neither have movement right now.
- raybb 10mo ago
  Do they work well for when you want to preview text? Like show the first 100 characters of a paragraph and then click to expand?
  - veqq 10mo ago
    Of course. That's the summary part
  - zahlman 10mo ago
    Yes. For example, on Codidact (https://codidact.com https://codidact.com), limited HTML access is offered along with Markdown when making posts, and the details and summary tags in particular are whitelisted. I've made extensive use of this in some of my content, for example https://software.codidact.com/posts/289251/289252#answer-289252 https://software.codidact.com/posts/289251/289252#answer-289... . If you have NoScript you can easily verify that the expanding sections work perfectly well without JavaScript. They can even be nested, as they are here; and the summary text can contain some other forms of markup without issue. (When crafting the post, however, I had to do some tricky things with whitespace to avoid confusing the Markdown parser.)
only-one1701 10mo ago
Something I keep thinking about when I consider the trade-offs between building a site with HTML/CSS wherever possible vs JS is what the actual _experience_ of writing and maintaining HTML/CSS is vs JS. JS gets knocked around a bunch compared to "real" languages (although less so in recent years), but at the end of the day, it's a programming language. You can write a loop in it. Writing a web server in C++ is a way to get excellent performance. So why don't most people do it?
- breve 10mo ago
  > 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 https://w3techs.com/technologies/overview/web_server
- yurishimo 10mo ago
  JS got popular because some devs were trying to realize a world where the same code can be shared on the front and backend. I think on the surface, it was a noble goal with good intentions. Having only one programming language to handle is going to create some efficiency gains when you work in a large company with thousands of devs who all need training want to share knowledge as a larger organization. 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.
suprjami 10mo ago
Gimme a dark/light mode switch. CSS is allowed.
- johnisgood 10mo ago
  Checkbox and :checked are your friends.
- adzm 10mo ago
  Use a checkbox, d. Define vars for light mode. Override when checked for dark mode with body:has(#d:checked) and can include the dark mode media query too
- zahlman 10mo ago
  See https://lyra.horse/blog/2025/08/you-dont-need-js/ https://lyra.horse/blog/2025/08/you-dont-need-js/, via https://news.ycombinator.com/item?id=45056878 https://news.ycombinator.com/item?id=45056878 (which discussion contains some deeper explanation).
- deleted 10mo ago
  [deleted]
- tisc 10mo ago
  Why would you build a switch instead of relying on the user’s system settings? The only reason I can imagine is that your dark/light mode is not usable/readable so it forces the user to switch
  - trnglina 10mo ago
    I often use different light/dark settings between apps and my system. Just because I want system UIs to be dark, for example, doesn't mean I want to read long pages of white-on-black prose on your blog.
    - trinix912 10mo ago
      Seconded. Just because I like to have the browser toolbar dark and GitHub dark doesn't mean I also want to read lengthy articles (LWN) in thin white text on a black background.
ronbenton 10mo ago
One thing I am quite hopeful for is customizable selects! It's in WHATWG stage 3 right now. I have seen so many horrors with javascript-based custom dropdowns components. https://developer.chrome.com/blog/a-customizable-select https://developer.chrome.com/blog/a-customizable-select
odie5533 10mo ago
The Popover API looks really cool. Could see it for tooltips or lightboxes.
cantalopes 10mo ago
The problem is that it's difficukt to style or animate those things. Unless you're builsing something for dun or technical where it's not important it's fine but i doubt any real world commercial project would be satisfied with just this
overflowy 10mo ago
HTML and JavaScript serve distinct purposes, making better or worse comparisons logically flawed. Complex/interactive web apps requires JavaScript, period. Attempting to build sophisticated apps solely through HTML (looking at you HTMLX) eventually hits a functional ceiling.
- mcny 10mo ago
  It shouldn't have to be this way though. There is no reason html can't do things it needs to do to build complete apps. We could use reasonable defaults to allow a new type of html markup without JavaScript. All the http verbs. Decent html input controls What else?
- imbusy111 10mo ago
  I assume you mean htmx. It doesn't have to be either/or. You can supplement htmx with Javascript. 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.
- ksec 10mo ago
  I dont think anyone is arguing Google Earth should be pure HTML. But it is equally false you cant do Gmail with HTML only. 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.
  - llmslave2 10mo ago
    Gmail with html only would not be a nice experience. Modern gmail is really bloated but it's actually one of the few web apps I have no problems with.
    - ksec 10mo ago
FormerlyEL 10mo ago
A pleasant surprise to see Aaron's post here, we worked together for a bit on frontend optimization in a multi-tenant international ecommerce platform. That work was a large part of my inspiration for building https://contentblocksjs.com https://contentblocksjs.com which encapsulated a lot of the JS concerns into web components.
dpedu 10mo ago
I didn't know about <datalist>, but how are you supposed to use it with a non-trivial amount of items in the list? I don't see how this can be a replacement for javascript/XHR based autocomplete.
- reed1234 10mo ago
  > If we can hand-off any JS functionality to native HTML or CSS, then users can download less stuff, and the remaining JS can pay attention to more important tasks that HTML and CSS can't handle (yet).
- psnehanshu 10mo ago
  You can't. It's only supposed to be used for a limited list.
- lelandfe 10mo ago
  Don't use it, it totally blows. For another oddity to not use, check out the multiple select: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/select#result_3 https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... Expecting users to press modifiers when clicking on these is so funny.
  - Hendrikto 10mo ago
    > Expecting users to press modifiers when clicking on these is so funny. I mean… 5 year olds can figure out shift-click in Minecraft.
    - lelandfe 10mo ago
      Trying to figure things out in a game is fun! Trying to figure things out on a website is a sign the UI sucks.
      - cardamomo 10mo ago
        Learn it in a game, then use it on a website. It's a UI convention, not merely a quirk to a multi-select list.
econ 10mo ago
I'm so not impressed by the toggle implementation... How nice it could have been. Nesting the elements is a truly hideous choice. The summary is part of the details?? I thought they were opposites. Should we also put the headings in the <p> from now on? Identifying a target should be done by id or by name. That it does use a name because js can't target it without makes it even more stupid. We already had labels for form fields. Inventing a completely different method for something very similar is a dumb idea. The old checkbox hack is more flexible and less ugly for some implementations. Why force the hidden content to be below or above the toggle? We aren't gaining anything with this. What is this nonsense for an element to not just be hidden or displayed but to have some weird 3rd state where only one of its children is shown? How should styling it even work for this new state? If I apply a style to the hidden content it must also apply to the link? The text is hidden but the style is visible??? Preposterous! Don't try style <details> to avoid unexpected behavior. Try wrapping the hidden content in a new element to make it behave normally. What is this ugly arrow? If you find 1000 websites using a toggle I doubt there is one using an ugly arrow like that. The default styling gives no clue about it being clickable? The pointer (awkwardly called the cursor) choice is the text selection????? Blue underlined "more" is what everyone does and everyone is used to. The cursor should be pointer. (This is css speak for "the pointer should be a hand") The number of js toggles you can find online where the button lives inside the hidden text is guaranteed to be zero. Forget about drop in replacement, you will have to reinvent your css. Maybe I'm dense but I also want my url to reflect the state of the page. I would have been impressed if that was supported. Personally I use actual links and disable default action in the listener if js is enabled/working or modify the state on the server if js isn't available/working. It would have been great if the toggle action was implemented as a simple attribute something like toggle="element name" so that anything can be clickable and anything can be toggleable. Have a "closed" as well as an "open" attribute for the target. Doesn't seem very hard. An open/closed attribute would be useful for other things too. Using display:none is terrible as display: is used for many things.
- zahlman 10mo ago
  > Nesting the elements is a truly hideous choice. The summary is part of the details?? I thought they were opposites. It gives them a semantic connection. Last I checked, HTML isn't really based on giving special meaning to combinations of sibling tags. A summary is part of the thing that conceptually requires detailing. > If you find 1000 websites using a toggle I doubt there is one using an ugly arrow like that. I think the default looks fine. But TFA clearly explains right there that it can be styled. (Specifically, by styling ::before on the summary tag.) > The default styling gives no clue about it being clickable? You asked what the arrow is, and then asked about the lack of indication that the summary header is clickable. The arrow is exactly that indication. > Maybe I'm dense but I also want my url to reflect the state of the page. If you scroll, should the fragment automatically update as you scroll past anchors? I think I'd find that quite annoying.
anidsiam 10mo ago
Your blogs have very small amount solution, but the JS use cases are very large. How this little replacement can do more thing? I usually like the idea of being using as lean as possible, if it's can be possible to do more thing just with HTML and CSS that's obviously cool. Is it really possible to replace JS with HTML in near future? BTW the toggle solution (expanding content) is good.
montroser 10mo ago
Most of this is great, except for the input/datalist bits, which are not sufficiently functional to be used in any real scenario. Users expect these interfaces to be tolerant of misspellings, optional sub text under each option, mobile ux niceties, etc -- and so everyone builds this with js...
- kmoser 10mo ago
  My main beef with datalist is that there's no easy way to show and allow only text (e.g. Beverly Hills), but have the actual value selected be a number (e.g. 90210). In other words there's no analogy to <option value="90210">Beverly Hills</option>.
  - swiftcoder 10mo ago
    > Each <option> element should have a value attribute... It can also have a label attribute, or, missing that, some text content, which may be displayed by the browser instead of value (Firefox), or in addition to value (Chrome and Safari)... The exact content of the drop-down menu depends on the browser, but when clicked, content entered into control field will always come from the value attribute This seems... underspecified. Not ideal that Chrome/Safari aren't aligned with Firefox here, and that there is no standard way to only display the label [from]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
  - tosti 10mo ago
    That and there's no HTML way to interactively load results. Or are you really going to serialize half a million records to HTML and transfer it all every time the relevant block is added to a page? What if it sits in the header or footer templates?
    - _heimdall 10mo ago
      This would be possible in XSLT, if only browsers would implement the latest spec rather than abandoning it all together.
65 10mo ago
It feels like some variation of this post gets submitted here every week.
- Y-bar 10mo ago
  And it will continue until node_modules shrinks!
- ozim 10mo ago
  That’s a bit of evergreen topic. “stop bloating web with js” comes up fairly often and there are those people who think they found a solution and everyone should start using whatever they imagine is “best for everyone”. In my opinion most of those people struggle with whatever they encountered in ecosystem and just want to find a way that fits them - while also trying to make others do the same. *“You didn’t want to make things perfect. You just hated things the way they are.”*
- scrame 9mo ago
  yes, because most everyone dreads working with javascript, which is why there is so much tech built around not dealing with it.
Izkata 10mo ago
Does it bother anyone else that it links to Codepen instead of just putting them on the page? Like I get this is a blog system but it still feels odd, especially for a "use this plain HTML"-style post...
- skeptic_ai 10mo ago
  So much about html only that makes me load 2mb of code pen and heavy ui to see the example. Yeah it’s terrible ux. same as most of the examples are bad
- acomjean 10mo ago
  It doesn’t really bother me. It seems to link to the authors codepen. If you us code pen you can bookmark the snippets. Codepen colorizes the html/css etc. Link rot is a thing though, so it’s not always ideal to have dependencies on third party urls staying the same.
- nchmy 10mo ago
  Bothered me greatly. Should have done on-page AND a link to codepen for you to play with
Sephr 10mo ago
I don't see any mention of HTTP 204 or multipart/x-mixed-replace. Those are both very helpful for implementing rich JavaScript-free HTML applications with advanced interactivity.
iammrpayments 10mo ago
I was trying to rewrite some UI library with html sometime ago following the W3C accessibility specs and found out a lot of patterns can’t be done with pure html and require javascript unfortunately.
- scrame 10mo ago
  like what?
  - iammrpayments 10mo ago
    Tabs, accordion, combobox. There is a whole lot more, these are just the ones I can remember now.
    - paulhebert 10mo ago
      Yeah this is true at this point. A lot of more complex patterns require JS to be accessible to screen readers. We still should do more with HTML and CSS! And reach for leaner solutions than React everywhere. But be careful going for a pure CSS solution for things like tabs if you don’t understand the accessibility requirements. (I wish the HTML spec would move faster on these common patterns!)
      - rhdunn 10mo ago
        https://www.w3.org/WAI/ARIA/apg/patterns/ https://www.w3.org/WAI/ARIA/apg/patterns/ is my go to for accessibility requirements of components. And yes, being able to do all of these in pure HTML/CSS would be awesome. Though we are getting there with things like `details` and the newer `popover` features which should make things like rich tooltips, menu buttons, etc. a lot easier to implement. IIRC, there are also several anchor CSS properties to make positioning a lot simpler.
      - wvenable 10mo ago
        > We still should do more with HTML and CSS! And reach for leaner solutions than React everywhere. It's pretty difficult for anyone to completely understand all the nuances in HTML and CSS. It's a big mess that gets bigger and messier every year. We should have just given JavaScript even more power over controlling the viewport and leave HTML and CSS for the history books.
fnord77 10mo ago
<blink>
Dwedit 10mo ago
Nobody tell them about how much stuff can go into SVG. That can even be inlined within HTML source code.
- yurishimo 10mo ago
  And you can target it with css! Slap a class attribute on a path element; it’s fine!
troad 10mo ago
Plain HTML is very cozy to me - I came of age in that era. Marquee tags 4eva. But as much as I hate to admit it, it is very difficult to build something functional today with plain HTML and no/minimal JS. If you want, say, a model form that manages its children as well, you're basically going to end up with a 2003-era ASP-feeling application with way too many views and forms (as seen on your employer's current HR system). Or you use HTMX... and you still end up with just as many (partial) views, but now with so much implicit state that you're veering into write-only code. I dislike modern JS to the extent that I opted for Phoenix LiveView, just so I could achieve interactivity without ever having to touch JS, but in truth it's not a comprehensive solution. Still had to write a web worker, a bridge to handle things like notifications, etc. Plus the future direction of Phoenix, all in on AI, is worrying. Honestly, I should probably just swallow my disdain and learn to appreciate and use modern JS, as painful as that sounds. I want to write and release cool things, not get caught up in navel-gazing language wars.
- faitswulff 10mo ago
  I haven't used it in anger myself, but if you know Elixir and Phoenix you might like Gleam, which compiles to Javascript.
  - troad 10mo ago
    I appreciate the helpful reply, but I think this is precisely the kind of indirection I need to avoid. I'm a sucker for elegance. If left entirely to my own devices I'd probably design a language / write a transpiler of my own, and wind up with exceedingly elegant tooling for websites, and no websites. :)
    - llmslave2 10mo ago
      This is why I don't use Typescript or frameworks in my own projects, I just constantly seek the cleanest abstraction and never get anything done. Using a deliberately messy solution is annoying but at least I accomplish stuff.
- wild_egg 10mo ago
deleted 10mo ago
[deleted]
avodonosov 10mo ago
I am reading the CodePen example for summary/details. Especially the CSS part. Its so easy, like a breeze!
hn111 10mo ago
I’ve tried replacing my modal components with the <dialog> element, but had to reverse everything due to this issue: https://github.com/whatwg/html/issues/9936 https://github.com/whatwg/html/issues/9936 In short: you can’t have an interactive popover (e.g. a toast notification) on top of a dialog modal. I’d love to use the new native elements but we’re sadly not quite there yet.
shahzaibmushtaq 10mo ago
This is helpful when development revolves around static environment.
busymom0 10mo ago
I really try not using JavaScript unless absolutely needed. On my latest project, the whole site actually functions without JavaScript and is server side rendered. However, there's some small piece which I really needed JavaScript for couple reasons. Basically, I have a site which collects the top STEAMD posts from places like HN, lobsters, tildes, slashdot, bear, reddit etc and displays them in chronological order. I wanted a way for users to block posts with certain keywords or from specific domains. I didn't want to do this server side for both performance reasons plus privacy reasons. I didn't want users to need signing up or something to block. I also didn't want to collect block lists for privacy reasons. So, I resorted to using JavaScript and local storage. All posts within the filter for the date are sent and JavaScript is used to block posts with keywords before displaying. So my server never knows what keywords are blocked. Site for anyone curious: https://limereader.com/ https://limereader.com/
- petit_robert 10mo ago
  Interesting. Nice way to get headers quickly, I'll have a look. Fun project I'm sure, but out of curiosity, is this something that you can monetize somehow? because the fun only goes so far.
backtogeek 10mo ago
Brilliant I will be adopting a few of these, I have been on a personal quest to reduce js use recently, I feel like I spend more time debugging js than producing the end result.
Theoleff 10mo ago
The interesting part here isn’t “no JavaScript”, it’s that HTML already covers more use cases than people remember (forms, dialogs, validation, navigation). I ran into this repeatedly while writing my book "You Don’t Need JavaScript"[0]: most JS in these cases isn’t adding capability, it’s compensating for forgotten platform features. [0] https://theosoti.com/you-dont-need-js/ https://theosoti.com/you-dont-need-js/
- danieloj 10mo ago
  Agreed! I assume the reason for the forgetting of the features is that at least some were poorly supported when first released so developers create workarounds that then become the de facto standard. It has been amazing to see the speed up in release and support of new CSS features over the last couple of years! Even the masonry layout has finally reached an experimental stage
  - Theoleff 10mo ago
    Yup, at this point it feels more like habit than necessity. People learned to build things like dropdowns in JavaScript years ago, so they keep doing it that way. A lot of devs simply don’t look any further when it comes to what HTML and CSS already provide.
    - freedomben 10mo ago
      That exactly describes me. I'm not a good frontend person. I got really, really good at building desktop GUIs in Swing (Java) back in the day and really imprinted on that way of doing things. When moving to web, I found the the display landscape really challenging to grok. I read a few books and got to where I could get most of what I wanted done, but it always took me way longer than it felt like it should, and certainly much longer than it took my coworkers. In that period I learned the contemporary patterns of the day and got pretty good at using component libraries with frameworks like React and was finally able to make things look and behave more like I wanted them to. Because at that point so much of the focus was on javascript and component libs/frameworks, I didn't (and mostly still don't) really follow browser development. I looked into things like web components when they were first talked about but found their DX to be quite sub-par (it was still pretty early days) and haven't really looked again. I'm personally much more interested in systems, infrastructure, devops, and all things backend, so for me frontend is a necessary evil to enable me to surface controls for my stuff to users. It's not that I don't want to stay up to speed and current, it's more that in my limited bandwidth I'm more focused on what I care about. That leads to exactly the pattern you described: I learned and got comfortable with a certain paradigm in a different time, and those ways are quite engrained. Anyway, thank you for your comment. It really helped me identify a blind spot I previously had (which I intend to rectify) :-)
levmiseri 10mo ago
A missed opportunity to not have all of these examples inline. The page/blog-post would be so much more convincing if it utilized all of these HTML replacements instead (or in addition) to linking to codepen.
- dvh 10mo ago
  Absolutely mind boggling. I've seen it many times before. There's some FooMaker v1.0 announced and you click on it thinking it will allow to easily make Foo and the example is how to disable FooMaker's lights l while AC is running or some other obscure edge case that affects like one in a million people, no examples how to actually use it for most common use case or how the result look like.
- itishappy 10mo ago
  I had assumed this was a 25 year old article at first glance. Those dithered gifs sure are a throwback!
- nfrmatk 10mo ago
  I was also frustrated to find the examples weren't inline, but I think this is a guest blog post which makes it a bit more understandable.
hollowturtle 10mo ago
I don't want to be so negative, but we got details and popover after literally decades, and we still have datalist presented as a plausible option? Html is so underdeveloped and the first we all agree on that the first we'll pretend from committee real advancement
- 6510 10mo ago
  The committee is an unsolved puzzle as old as mankind. That's not to discourage you. If you do solve it it would remedy almost all of our problems. If the solution could be found instantly in 5 seconds someone would have solved it already. This one is going to take some actual thinking and modeling.
  - hollowturtle 10mo ago
    I know for sure that Apple, who has an important seat on the standard committee, holded back innovation for so long, it's not a matter of finding or not finding solutions. They're failing us for different interests
    - 6510 10mo ago
      They are the new Microsoft, if the web died it would be good for them. We've also tried to have elected bureaucrats make the decisions. Systems giving everyone one vote also turned out terrible as expertise and thoughtfulness drowns in superficial noise. It is kind of embarrassing how well the dictator model works. Personally I prefer to do everything alone. There are no meetings, barely any paperwork, I get to own the bad choices. So far I get along well with my past self and my future self. I do consider it a temporary hack until figuring things out in groups is solved. Robot overlords sounds increasingly appealing.
    - alwillis 10mo ago
      > I know for sure that Apple, who has an important seat on the standard committee, holded back innovation for so long, it's not a matter of finding or not finding solutions. They're failing us for different interests Apple isn't the problem. Apple was the first to ship :has(), which developers wanted for 20 years but was thought to be essentially impossible to implement [1]. Apple pushed to get consensus on how to implement masonry layouts in CSS [2]. And they were first to ship the new specification in a browser you can use right now [3]. This dashboard shows Apple slightly ahead in terms of new CSS features being implemented and interoperable with Firefox and Chrome [4]. [1]: https://webkit.org/blog/13096/css-has-pseudo-class/ https://webkit.org/blog/13096/css-has-pseudo-class/ [2]: https://webkit.org/blog/16026/css-masonry-syntax/ https://webkit.org/blog/16026/css-masonry-syntax/ [3]: https://webkit.org/blog/17660/introducing-css-grid-lanes/ https://webkit.org/blog/17660/introducing-css-grid-lanes/ [4]: https://wpt.fyi/interop-2025?stable https://wpt.fyi/interop-2025?stable
vijaybritto 10mo ago
What would make this super easy to adopt? A simple page which shows what native components are available with/without the need for polyfills for a given browserslist config
thayne 10mo ago
It seems like an oversight that there isn't a native way for a popover to be activated by hovering over the target element.
Cort3z 10mo ago
I love semantic html. It feels so much more modern and efficient than all of these fashion-driven front end tools.
bodash 10mo ago
Just been through several frontend interviews in the last few months, where it's clear that they still judge a developer's JS skills (especially React) than being semantically correct on HTML elements. Every question/exercise is centred around how well you know React hooks, effect, memoization, modern css-in-js etc. Given I've been working with Astro recently, in one interview I talked about DOM APIs and I can see the interviewer raise an eyebrow. In later stage, even I that passed the exercises, still didn't get the job.
- oceansky 10mo ago
  Having a separate css file make small components so much cleaner. I am not against tailwind, but I wouldn't want to use it in front-end interviews.
- rokkamokka 10mo ago
  Remember that a large part of hiring is finding someone who fits in an existing team. A team that uses react won't appreciate someone choosing to use native DOM APIs instead of a react component.
  - christophilus 10mo ago
    Eh. I build apps with Preact, but I prefer candidates who know the core web platform. They’ll be more apt to use the right tool for the job and not be baffled by edge cases.
  - abustamam 10mo ago
    In every React team I've been part of we've wanted to use as little react as possible and use native DOM apis when possible. React would be used purely for state management or interactivity. I feel like teams that have used react enough learn that the less React you can use the better :) it's a great tool, but most teams use it because it's all they know and they don't know what they don't know about html.
  - shimman 10mo ago
    Weird comment, I'm a web dev that has been using react for 10+ years and I prefer using native browser features whenever possible. I'd honestly avoid hiring framework specific devs because the skills required are never about just one single framework. Also this is just all JS + HTML here, let's not act like it's impossible to learn the most popular frontend tool at the moment.
augustk 10mo ago
Progressive enhancement is the way to go if you care about technical excellence. For some reason it fell out of fashion. https://en.wikipedia.org/wiki/Progressive_enhancement https://en.wikipedia.org/wiki/Progressive_enhancement
- _heimdall 10mo ago
  It fell out of fashion because the entire web was consumed by react.
- petepete 10mo ago
  > if you care about technical excellence Or accessibility.
herpdyderp 10mo ago
Before anyone wastes a lot of time like I did trying to use the popover API: it is not ready yet. You can do very basic things in all browsers but positioning is still different and/or totally broken per browser.
- senfiaj 10mo ago
  Yes, HTML & CSS alone won't replace JS. Of course, for complicated form validation HTML is not sufficient. But IMHO it's very important to provide basic functionality in HTML / CSS as much as possible / reasonable. Moving the functionality to HTML / CSS can potentially improve the SEO. As for positioning, there is an experimental feature @position-try. Here I made a small demo where it handles overflows. https://waspdev.com/articles/2025-06-29/css-features-web-developers-should-know-in-2025#handling_overflows_with_position_try_fallbacks https://waspdev.com/articles/2025-06-29/css-features-web-dev... But yeah, that's kind of limited if you need nice animations or some other complicated thing. Although it's fun.
- extra88 10mo ago
  Yes, popover's uses are limited without CSS anchor positioning but it will be supported in all major browsers very soon. In the meantime, there is a polyfill to load in browsers without support. https://caniuse.com/css-anchor-positioning https://caniuse.com/css-anchor-positioning
Devasta 10mo ago
JavaScript is the primary language of the web, HTML is just the payload carrier. I don't want it to be this way, but HTML has nothing approaching even one tenth the ambition of XSLT and XForms. If HTML were proposed today, you would be laughed out of the room.
nasso_dev 10mo ago
i like the points the article makes, but i really wish it used looping videos instead of actual GIFs i don't really see any reason to use GIFs here; any widely available video codec like H.264, VP8/VP9 or AV1 will result in significantly smaller file sizes, look better, and will allow enabling controls for seeking and play/pause
zaidf 10mo ago
The problem is that CSS continues to be a pain in the ass, even as it evolves. There is no other reason why something like tailwind should have the traction it has.
edwardtay 10mo ago
The <details> and <summary> elements are great, but I think the bigger missed opportunity is the lack of inline examples/demos on the page itself. Would be much more powerful to actually show these working rather than linking to external codepens. A few thoughts on the practicality: 1. Progressive enhancement is the real win here, not "replacing" JavaScript. These HTML features provide a baseline that works without JS, then you enhance with JS for better UX (animations, state persistence, etc.) 2. The details/summary approach breaks down when you need: - Custom animations/transitions - State synchronization across multiple elements - Analytics tracking on user interactions - Keyboard shortcuts beyond basic tab navigation 3. What about the <dialog> element? That's another underutilized HTML feature that could replace a ton of modal/popup JavaScript. 4. Have you explored the Popover API? It's getting broader browser support and handles a lot of common UI patterns without JS. The spirit of "use the platform" is great, but the title feels a bit clickbaity - you're not really replacing JS, just avoiding it where unnecessary. Which is good practice anyway!
conception 10mo ago
The switch from everything tables to everything divs was one of the worst for usability on the web. Every day I run into a table of data that doesn’t sort, copy/paste, search, resize columns or any of the very trivial items to do with tables. It always infuriating.
peesem 10mo ago
why are people so obsessed with restricting details/accordion elements to only one open at a time? let me open what I want to
zenmac 10mo ago
One good thing about NOT having JS is what the page can function in Tor Browser's "Safest" mode! A step down is to have JS only on your domain. "Safer" mode. Try to avoid web site that require "Standard" to view and run properly.
cess11 10mo ago
In my mind "Just HTML" does not include CSS.
hinkley 10mo ago
I was stuck on the backend while CSS3 absorbed most of the functionality of Less and Sass and now I’m trying to play catchup. If there had just been a CSS4 I’d be able to find a tutorial to teach me everything I missed in the interim.
1vuio0pswjnm7 10mo ago
"Nothing against JS, but it has better things to do than setup and manage your accordions or offscreen navigation menus... " Perhaps this is referring to "things" such as data collection, surveillance and ad services It would be interesting to see how Big Tech and other adtech companies would accomplish the same level of data collection, surveillance and ad services without the use of Javascript As for "nothing against JS", I think some web users (cf. "developers") who dislike adtech and the ad-laden web they perpetuate might have something against it
littlecranky67 10mo ago
My personal pet-peeve everytime a "you don't need JS" post comes up on HN, is the disconnect between the interface designers and the developers. In my dayjob as a (mostly react) freelance contractor doing B2B and LoB apps, there are always UX designers coming up with the screen- and interface designs. I don't think any project I ever were, could have matched a screen design I was passed without JS. Whether it being business requirements (has to work in IE, or nowadays has to work in Edge), or simply hard visual design choices. My favorite example is that of a date, date-time or date-range picker. Yes, there are HTML native elements. But they look absolutely ugly, styling only goes so far, and good luck with requirements such as "oh, but in the popup on the date-range picker, add a topbar with 3 buttons that trigger preselection and a dropdown". Now you can argue and communicate back that we save a lot of technical complexity in the stack if we stick to the HTML native solutions. But all those discussions basically end up managers and UX designers having no clue about the actual complexity and savings (time and money wise for future maintenance) and simply don't care. And if I am the one telling them "Look, in the HTML native date-time picker, you can't add custom elements, you can't fully customize every bit and piece of behaviour so change the screen designs" they will just fire up random corporate website XYZ and show a similar version of what they have in mind (and it is always JS-based) and suddenly it looks like me being unable or unskilled to achieve something, that is clearly doable as others have done it. Now not all is nice and shiny in the JS/React world. We use MaterialUI in a current project, and the commercial MUI-X DatePickers. They also come with their limitations, but it is just they are far more powerfull and customizable to actually meet the requirements and demands of UX and management, compared to the HTML versions.
srikanthdotch 10mo ago
Most people think that you should remove JavaScript to load your sites faster or for reasons like that. You have to learn to balance things, always use it if you need some good interactivity, validation etc. Don't try to use HTML only to force things.

748 points by soheilpro 10mo ago

> Input with Autofilter Suggestions Dropdown 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.

emseetech 10mo ago

When building out a new app or site, start with the simplest solution like the html-only autofilters first, then add complex behavior later. It's good to know these things exist so there are alternatives to reaching for a fat react component as the first step.

deleted 10mo ago
[deleted]
willparks 10mo ago
It’s great to see practical examples that push us to consider what the platform already offers before adding more layers of complexity.
zdragnar 10mo ago
Until your client tells you that it doesn't work in Edge and you find out it's because every browser has its own styling and they are impossible to change enough to get the really long options to show up correctly. 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.
- deleted 10mo ago
  [deleted]
  - rerdavies 10mo ago
    Have you no sense of craftsmanship?
- emseetech 10mo ago
  Right, don't add complexity until you have to.
  - abustamam 10mo ago
    I'd argue that adding complexity from the get-go to ensure that all users have a pleasant experience from the get-go is better than simplicity at the expense of some percentage of users. 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.
    - emseetech 10mo ago
      When building out a new app or site, which means a percentage of zero users is zero.

smlavine 10mo ago

The Pentagram at the top of the page does not load without JS enabled.

bitbasher 10mo ago
So it's.. fitting, how meta.

superkuh 10mo ago

Some of these new HTML features don't fully work in my "ancient" browser. But all of them partially work (ie opening the accordion element doesn't close others but it still opens and closes) and they still remain functional elements I can read and interact with. This puts them far ahead of any javascript implementation which almost universally fail to nothing.

ravenstine 10mo ago
What "ancient" browser are you using?
- vpShane 10mo ago
  Probably something 300 CVEs ago.

eleventen 10mo ago

The details / summary thing absolutely kills me. There’s basically nothing you can’t do with them. Hiding and replacing markers is easy. But every component library just pretends they don’t exist. It even saves you the effort of all the aria control and expanded tags: these tags don’t need them.

webstrand 10mo ago
Details works even when it's set display:contents too, for even more flexibility. Can't animate from open›close, yet, though. That's pretty much my last frustration with it.
- shakna 10mo ago
  I think the CSS support for that has finally landed, though it means targetting a pseudo element instead. Its been a year, so support is probably good enough you don't care if just the animation doesn't happen. https://developer.chrome.com/blog/styling-details https://developer.chrome.com/blog/styling-details
  - lelandfe 10mo ago
    Note that the transition to `auto` in that post relies on `interpolate-size` which has yet to land on Firefox or Safari, and neither have movement right now.
raybb 10mo ago
Do they work well for when you want to preview text? Like show the first 100 characters of a paragraph and then click to expand?
- veqq 10mo ago
  Of course. That's the summary part
- zahlman 10mo ago
  Yes. For example, on Codidact (https://codidact.com https://codidact.com), limited HTML access is offered along with Markdown when making posts, and the details and summary tags in particular are whitelisted. I've made extensive use of this in some of my content, for example https://software.codidact.com/posts/289251/289252#answer-289252 https://software.codidact.com/posts/289251/289252#answer-289... . If you have NoScript you can easily verify that the expanding sections work perfectly well without JavaScript. They can even be nested, as they are here; and the summary text can contain some other forms of markup without issue. (When crafting the post, however, I had to do some tricky things with whitespace to avoid confusing the Markdown parser.)

only-one1701 10mo ago

Something I keep thinking about when I consider the trade-offs between building a site with HTML/CSS wherever possible vs JS is what the actual _experience_ of writing and maintaining HTML/CSS is vs JS. JS gets knocked around a bunch compared to "real" languages (although less so in recent years), but at the end of the day, it's a programming language. You can write a loop in it. Writing a web server in C++ is a way to get excellent performance. So why don't most people do it?

breve 10mo ago
> 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 https://w3techs.com/technologies/overview/web_server
yurishimo 10mo ago
JS got popular because some devs were trying to realize a world where the same code can be shared on the front and backend. I think on the surface, it was a noble goal with good intentions. Having only one programming language to handle is going to create some efficiency gains when you work in a large company with thousands of devs who all need training want to share knowledge as a larger organization. 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.

suprjami 10mo ago

Gimme a dark/light mode switch. CSS is allowed.

johnisgood 10mo ago
Checkbox and :checked are your friends.
adzm 10mo ago
Use a checkbox, d. Define vars for light mode. Override when checked for dark mode with body:has(#d:checked) and can include the dark mode media query too
zahlman 10mo ago
See https://lyra.horse/blog/2025/08/you-dont-need-js/ https://lyra.horse/blog/2025/08/you-dont-need-js/, via https://news.ycombinator.com/item?id=45056878 https://news.ycombinator.com/item?id=45056878 (which discussion contains some deeper explanation).
deleted 10mo ago
[deleted]
tisc 10mo ago
Why would you build a switch instead of relying on the user’s system settings? The only reason I can imagine is that your dark/light mode is not usable/readable so it forces the user to switch
- trnglina 10mo ago
  I often use different light/dark settings between apps and my system. Just because I want system UIs to be dark, for example, doesn't mean I want to read long pages of white-on-black prose on your blog.
  - trinix912 10mo ago
    Seconded. Just because I like to have the browser toolbar dark and GitHub dark doesn't mean I also want to read lengthy articles (LWN) in thin white text on a black background.

ronbenton 10mo ago

One thing I am quite hopeful for is customizable selects! It's in WHATWG stage 3 right now. I have seen so many horrors with javascript-based custom dropdowns components. https://developer.chrome.com/blog/a-customizable-select https://developer.chrome.com/blog/a-customizable-select

odie5533 10mo ago

The Popover API looks really cool. Could see it for tooltips or lightboxes.

cantalopes 10mo ago

The problem is that it's difficukt to style or animate those things. Unless you're builsing something for dun or technical where it's not important it's fine but i doubt any real world commercial project would be satisfied with just this

overflowy 10mo ago

HTML and JavaScript serve distinct purposes, making better or worse comparisons logically flawed. Complex/interactive web apps requires JavaScript, period. Attempting to build sophisticated apps solely through HTML (looking at you HTMLX) eventually hits a functional ceiling.

mcny 10mo ago
It shouldn't have to be this way though. There is no reason html can't do things it needs to do to build complete apps. We could use reasonable defaults to allow a new type of html markup without JavaScript. All the http verbs. Decent html input controls What else?
imbusy111 10mo ago
I assume you mean htmx. It doesn't have to be either/or. You can supplement htmx with Javascript. 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.
ksec 10mo ago
I dont think anyone is arguing Google Earth should be pure HTML. But it is equally false you cant do Gmail with HTML only. 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.
- llmslave2 10mo ago
  Gmail with html only would not be a nice experience. Modern gmail is really bloated but it's actually one of the few web apps I have no problems with.
  - ksec 10mo ago

FormerlyEL 10mo ago

A pleasant surprise to see Aaron's post here, we worked together for a bit on frontend optimization in a multi-tenant international ecommerce platform. That work was a large part of my inspiration for building https://contentblocksjs.com https://contentblocksjs.com which encapsulated a lot of the JS concerns into web components.

dpedu 10mo ago

I didn't know about <datalist>, but how are you supposed to use it with a non-trivial amount of items in the list? I don't see how this can be a replacement for javascript/XHR based autocomplete.

reed1234 10mo ago
> If we can hand-off any JS functionality to native HTML or CSS, then users can download less stuff, and the remaining JS can pay attention to more important tasks that HTML and CSS can't handle (yet).
psnehanshu 10mo ago
You can't. It's only supposed to be used for a limited list.
lelandfe 10mo ago
Don't use it, it totally blows. For another oddity to not use, check out the multiple select: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/select#result_3 https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... Expecting users to press modifiers when clicking on these is so funny.
- Hendrikto 10mo ago
  > Expecting users to press modifiers when clicking on these is so funny. I mean… 5 year olds can figure out shift-click in Minecraft.
  - lelandfe 10mo ago
    Trying to figure things out in a game is fun! Trying to figure things out on a website is a sign the UI sucks.
    - cardamomo 10mo ago
      Learn it in a game, then use it on a website. It's a UI convention, not merely a quirk to a multi-select list.

econ 10mo ago

I'm so not impressed by the toggle implementation... How nice it could have been. Nesting the elements is a truly hideous choice. The summary is part of the details?? I thought they were opposites. Should we also put the headings in the <p> from now on? Identifying a target should be done by id or by name. That it does use a name because js can't target it without makes it even more stupid. We already had labels for form fields. Inventing a completely different method for something very similar is a dumb idea. The old checkbox hack is more flexible and less ugly for some implementations. Why force the hidden content to be below or above the toggle? We aren't gaining anything with this. What is this nonsense for an element to not just be hidden or displayed but to have some weird 3rd state where only one of its children is shown? How should styling it even work for this new state? If I apply a style to the hidden content it must also apply to the link? The text is hidden but the style is visible??? Preposterous! Don't try style <details> to avoid unexpected behavior. Try wrapping the hidden content in a new element to make it behave normally. What is this ugly arrow? If you find 1000 websites using a toggle I doubt there is one using an ugly arrow like that. The default styling gives no clue about it being clickable? The pointer (awkwardly called the cursor) choice is the text selection????? Blue underlined "more" is what everyone does and everyone is used to. The cursor should be pointer. (This is css speak for "the pointer should be a hand") The number of js toggles you can find online where the button lives inside the hidden text is guaranteed to be zero. Forget about drop in replacement, you will have to reinvent your css. Maybe I'm dense but I also want my url to reflect the state of the page. I would have been impressed if that was supported. Personally I use actual links and disable default action in the listener if js is enabled/working or modify the state on the server if js isn't available/working. It would have been great if the toggle action was implemented as a simple attribute something like toggle="element name" so that anything can be clickable and anything can be toggleable. Have a "closed" as well as an "open" attribute for the target. Doesn't seem very hard. An open/closed attribute would be useful for other things too. Using display:none is terrible as display: is used for many things.

zahlman 10mo ago
> Nesting the elements is a truly hideous choice. The summary is part of the details?? I thought they were opposites. It gives them a semantic connection. Last I checked, HTML isn't really based on giving special meaning to combinations of sibling tags. A summary is part of the thing that conceptually requires detailing. > If you find 1000 websites using a toggle I doubt there is one using an ugly arrow like that. I think the default looks fine. But TFA clearly explains right there that it can be styled. (Specifically, by styling ::before on the summary tag.) > The default styling gives no clue about it being clickable? You asked what the arrow is, and then asked about the lack of indication that the summary header is clickable. The arrow is exactly that indication. > Maybe I'm dense but I also want my url to reflect the state of the page. If you scroll, should the fragment automatically update as you scroll past anchors? I think I'd find that quite annoying.

anidsiam 10mo ago

Your blogs have very small amount solution, but the JS use cases are very large. How this little replacement can do more thing? I usually like the idea of being using as lean as possible, if it's can be possible to do more thing just with HTML and CSS that's obviously cool. Is it really possible to replace JS with HTML in near future? BTW the toggle solution (expanding content) is good.

montroser 10mo ago

Most of this is great, except for the input/datalist bits, which are not sufficiently functional to be used in any real scenario. Users expect these interfaces to be tolerant of misspellings, optional sub text under each option, mobile ux niceties, etc -- and so everyone builds this with js...

kmoser 10mo ago
My main beef with datalist is that there's no easy way to show and allow only text (e.g. Beverly Hills), but have the actual value selected be a number (e.g. 90210). In other words there's no analogy to <option value="90210">Beverly Hills</option>.
- swiftcoder 10mo ago
  > Each <option> element should have a value attribute... It can also have a label attribute, or, missing that, some text content, which may be displayed by the browser instead of value (Firefox), or in addition to value (Chrome and Safari)... The exact content of the drop-down menu depends on the browser, but when clicked, content entered into control field will always come from the value attribute This seems... underspecified. Not ideal that Chrome/Safari aren't aligned with Firefox here, and that there is no standard way to only display the label [from]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
- tosti 10mo ago
  That and there's no HTML way to interactively load results. Or are you really going to serialize half a million records to HTML and transfer it all every time the relevant block is added to a page? What if it sits in the header or footer templates?
  - _heimdall 10mo ago
    This would be possible in XSLT, if only browsers would implement the latest spec rather than abandoning it all together.

65 10mo ago

It feels like some variation of this post gets submitted here every week.

Y-bar 10mo ago
And it will continue until node_modules shrinks!
ozim 10mo ago
That’s a bit of evergreen topic. “stop bloating web with js” comes up fairly often and there are those people who think they found a solution and everyone should start using whatever they imagine is “best for everyone”. In my opinion most of those people struggle with whatever they encountered in ecosystem and just want to find a way that fits them - while also trying to make others do the same. *“You didn’t want to make things perfect. You just hated things the way they are.”*
scrame 9mo ago
yes, because most everyone dreads working with javascript, which is why there is so much tech built around not dealing with it.

Izkata 10mo ago

Does it bother anyone else that it links to Codepen instead of just putting them on the page? Like I get this is a blog system but it still feels odd, especially for a "use this plain HTML"-style post...

skeptic_ai 10mo ago
So much about html only that makes me load 2mb of code pen and heavy ui to see the example. Yeah it’s terrible ux. same as most of the examples are bad
acomjean 10mo ago
It doesn’t really bother me. It seems to link to the authors codepen. If you us code pen you can bookmark the snippets. Codepen colorizes the html/css etc. Link rot is a thing though, so it’s not always ideal to have dependencies on third party urls staying the same.
nchmy 10mo ago
Bothered me greatly. Should have done on-page AND a link to codepen for you to play with

Sephr 10mo ago

I don't see any mention of HTTP 204 or multipart/x-mixed-replace. Those are both very helpful for implementing rich JavaScript-free HTML applications with advanced interactivity.

iammrpayments 10mo ago

I was trying to rewrite some UI library with html sometime ago following the W3C accessibility specs and found out a lot of patterns can’t be done with pure html and require javascript unfortunately.

scrame 10mo ago
like what?
- iammrpayments 10mo ago
  Tabs, accordion, combobox. There is a whole lot more, these are just the ones I can remember now.
  - paulhebert 10mo ago
    Yeah this is true at this point. A lot of more complex patterns require JS to be accessible to screen readers. We still should do more with HTML and CSS! And reach for leaner solutions than React everywhere. But be careful going for a pure CSS solution for things like tabs if you don’t understand the accessibility requirements. (I wish the HTML spec would move faster on these common patterns!)
    - rhdunn 10mo ago
      https://www.w3.org/WAI/ARIA/apg/patterns/ https://www.w3.org/WAI/ARIA/apg/patterns/ is my go to for accessibility requirements of components. And yes, being able to do all of these in pure HTML/CSS would be awesome. Though we are getting there with things like `details` and the newer `popover` features which should make things like rich tooltips, menu buttons, etc. a lot easier to implement. IIRC, there are also several anchor CSS properties to make positioning a lot simpler.
    - wvenable 10mo ago
      > We still should do more with HTML and CSS! And reach for leaner solutions than React everywhere. It's pretty difficult for anyone to completely understand all the nuances in HTML and CSS. It's a big mess that gets bigger and messier every year. We should have just given JavaScript even more power over controlling the viewport and leave HTML and CSS for the history books.

fnord77 10mo ago

<blink>

Dwedit 10mo ago

Nobody tell them about how much stuff can go into SVG. That can even be inlined within HTML source code.

yurishimo 10mo ago
And you can target it with css! Slap a class attribute on a path element; it’s fine!

troad 10mo ago

Plain HTML is very cozy to me - I came of age in that era. Marquee tags 4eva. But as much as I hate to admit it, it is very difficult to build something functional today with plain HTML and no/minimal JS. If you want, say, a model form that manages its children as well, you're basically going to end up with a 2003-era ASP-feeling application with way too many views and forms (as seen on your employer's current HR system). Or you use HTMX... and you still end up with just as many (partial) views, but now with so much implicit state that you're veering into write-only code. I dislike modern JS to the extent that I opted for Phoenix LiveView, just so I could achieve interactivity without ever having to touch JS, but in truth it's not a comprehensive solution. Still had to write a web worker, a bridge to handle things like notifications, etc. Plus the future direction of Phoenix, all in on AI, is worrying. Honestly, I should probably just swallow my disdain and learn to appreciate and use modern JS, as painful as that sounds. I want to write and release cool things, not get caught up in navel-gazing language wars.

faitswulff 10mo ago
I haven't used it in anger myself, but if you know Elixir and Phoenix you might like Gleam, which compiles to Javascript.
- troad 10mo ago
  I appreciate the helpful reply, but I think this is precisely the kind of indirection I need to avoid. I'm a sucker for elegance. If left entirely to my own devices I'd probably design a language / write a transpiler of my own, and wind up with exceedingly elegant tooling for websites, and no websites. :)
  - llmslave2 10mo ago
    This is why I don't use Typescript or frameworks in my own projects, I just constantly seek the cleanest abstraction and never get anything done. Using a deliberately messy solution is annoying but at least I accomplish stuff.
wild_egg 10mo ago

deleted 10mo ago

[deleted]

avodonosov 10mo ago

I am reading the CodePen example for summary/details. Especially the CSS part. Its so easy, like a breeze!

hn111 10mo ago

I’ve tried replacing my modal components with the <dialog> element, but had to reverse everything due to this issue: https://github.com/whatwg/html/issues/9936 https://github.com/whatwg/html/issues/9936 In short: you can’t have an interactive popover (e.g. a toast notification) on top of a dialog modal. I’d love to use the new native elements but we’re sadly not quite there yet.

shahzaibmushtaq 10mo ago

This is helpful when development revolves around static environment.

busymom0 10mo ago

I really try not using JavaScript unless absolutely needed. On my latest project, the whole site actually functions without JavaScript and is server side rendered. However, there's some small piece which I really needed JavaScript for couple reasons. Basically, I have a site which collects the top STEAMD posts from places like HN, lobsters, tildes, slashdot, bear, reddit etc and displays them in chronological order. I wanted a way for users to block posts with certain keywords or from specific domains. I didn't want to do this server side for both performance reasons plus privacy reasons. I didn't want users to need signing up or something to block. I also didn't want to collect block lists for privacy reasons. So, I resorted to using JavaScript and local storage. All posts within the filter for the date are sent and JavaScript is used to block posts with keywords before displaying. So my server never knows what keywords are blocked. Site for anyone curious: https://limereader.com/ https://limereader.com/

petit_robert 10mo ago
Interesting. Nice way to get headers quickly, I'll have a look. Fun project I'm sure, but out of curiosity, is this something that you can monetize somehow? because the fun only goes so far.

backtogeek 10mo ago

Brilliant I will be adopting a few of these, I have been on a personal quest to reduce js use recently, I feel like I spend more time debugging js than producing the end result.

Theoleff 10mo ago

The interesting part here isn’t “no JavaScript”, it’s that HTML already covers more use cases than people remember (forms, dialogs, validation, navigation). I ran into this repeatedly while writing my book "You Don’t Need JavaScript"[0]: most JS in these cases isn’t adding capability, it’s compensating for forgotten platform features. [0] https://theosoti.com/you-dont-need-js/ https://theosoti.com/you-dont-need-js/

danieloj 10mo ago
Agreed! I assume the reason for the forgetting of the features is that at least some were poorly supported when first released so developers create workarounds that then become the de facto standard. It has been amazing to see the speed up in release and support of new CSS features over the last couple of years! Even the masonry layout has finally reached an experimental stage
- Theoleff 10mo ago
  Yup, at this point it feels more like habit than necessity. People learned to build things like dropdowns in JavaScript years ago, so they keep doing it that way. A lot of devs simply don’t look any further when it comes to what HTML and CSS already provide.
  - freedomben 10mo ago
    That exactly describes me. I'm not a good frontend person. I got really, really good at building desktop GUIs in Swing (Java) back in the day and really imprinted on that way of doing things. When moving to web, I found the the display landscape really challenging to grok. I read a few books and got to where I could get most of what I wanted done, but it always took me way longer than it felt like it should, and certainly much longer than it took my coworkers. In that period I learned the contemporary patterns of the day and got pretty good at using component libraries with frameworks like React and was finally able to make things look and behave more like I wanted them to. Because at that point so much of the focus was on javascript and component libs/frameworks, I didn't (and mostly still don't) really follow browser development. I looked into things like web components when they were first talked about but found their DX to be quite sub-par (it was still pretty early days) and haven't really looked again. I'm personally much more interested in systems, infrastructure, devops, and all things backend, so for me frontend is a necessary evil to enable me to surface controls for my stuff to users. It's not that I don't want to stay up to speed and current, it's more that in my limited bandwidth I'm more focused on what I care about. That leads to exactly the pattern you described: I learned and got comfortable with a certain paradigm in a different time, and those ways are quite engrained. Anyway, thank you for your comment. It really helped me identify a blind spot I previously had (which I intend to rectify) :-)

levmiseri 10mo ago

A missed opportunity to not have all of these examples inline. The page/blog-post would be so much more convincing if it utilized all of these HTML replacements instead (or in addition) to linking to codepen.

dvh 10mo ago
Absolutely mind boggling. I've seen it many times before. There's some FooMaker v1.0 announced and you click on it thinking it will allow to easily make Foo and the example is how to disable FooMaker's lights l while AC is running or some other obscure edge case that affects like one in a million people, no examples how to actually use it for most common use case or how the result look like.
itishappy 10mo ago
I had assumed this was a 25 year old article at first glance. Those dithered gifs sure are a throwback!
nfrmatk 10mo ago
I was also frustrated to find the examples weren't inline, but I think this is a guest blog post which makes it a bit more understandable.

hollowturtle 10mo ago

I don't want to be so negative, but we got details and popover after literally decades, and we still have datalist presented as a plausible option? Html is so underdeveloped and the first we all agree on that the first we'll pretend from committee real advancement

6510 10mo ago
The committee is an unsolved puzzle as old as mankind. That's not to discourage you. If you do solve it it would remedy almost all of our problems. If the solution could be found instantly in 5 seconds someone would have solved it already. This one is going to take some actual thinking and modeling.
- hollowturtle 10mo ago
  I know for sure that Apple, who has an important seat on the standard committee, holded back innovation for so long, it's not a matter of finding or not finding solutions. They're failing us for different interests
  - 6510 10mo ago
    They are the new Microsoft, if the web died it would be good for them. We've also tried to have elected bureaucrats make the decisions. Systems giving everyone one vote also turned out terrible as expertise and thoughtfulness drowns in superficial noise. It is kind of embarrassing how well the dictator model works. Personally I prefer to do everything alone. There are no meetings, barely any paperwork, I get to own the bad choices. So far I get along well with my past self and my future self. I do consider it a temporary hack until figuring things out in groups is solved. Robot overlords sounds increasingly appealing.
  - alwillis 10mo ago
    > I know for sure that Apple, who has an important seat on the standard committee, holded back innovation for so long, it's not a matter of finding or not finding solutions. They're failing us for different interests Apple isn't the problem. Apple was the first to ship :has(), which developers wanted for 20 years but was thought to be essentially impossible to implement [1]. Apple pushed to get consensus on how to implement masonry layouts in CSS [2]. And they were first to ship the new specification in a browser you can use right now [3]. This dashboard shows Apple slightly ahead in terms of new CSS features being implemented and interoperable with Firefox and Chrome [4]. [1]: https://webkit.org/blog/13096/css-has-pseudo-class/ https://webkit.org/blog/13096/css-has-pseudo-class/ [2]: https://webkit.org/blog/16026/css-masonry-syntax/ https://webkit.org/blog/16026/css-masonry-syntax/ [3]: https://webkit.org/blog/17660/introducing-css-grid-lanes/ https://webkit.org/blog/17660/introducing-css-grid-lanes/ [4]: https://wpt.fyi/interop-2025?stable https://wpt.fyi/interop-2025?stable

vijaybritto 10mo ago

What would make this super easy to adopt? A simple page which shows what native components are available with/without the need for polyfills for a given browserslist config

thayne 10mo ago

It seems like an oversight that there isn't a native way for a popover to be activated by hovering over the target element.

Cort3z 10mo ago

I love semantic html. It feels so much more modern and efficient than all of these fashion-driven front end tools.

bodash 10mo ago

Just been through several frontend interviews in the last few months, where it's clear that they still judge a developer's JS skills (especially React) than being semantically correct on HTML elements. Every question/exercise is centred around how well you know React hooks, effect, memoization, modern css-in-js etc. Given I've been working with Astro recently, in one interview I talked about DOM APIs and I can see the interviewer raise an eyebrow. In later stage, even I that passed the exercises, still didn't get the job.

oceansky 10mo ago
Having a separate css file make small components so much cleaner. I am not against tailwind, but I wouldn't want to use it in front-end interviews.
rokkamokka 10mo ago
Remember that a large part of hiring is finding someone who fits in an existing team. A team that uses react won't appreciate someone choosing to use native DOM APIs instead of a react component.
- christophilus 10mo ago
  Eh. I build apps with Preact, but I prefer candidates who know the core web platform. They’ll be more apt to use the right tool for the job and not be baffled by edge cases.
- abustamam 10mo ago
  In every React team I've been part of we've wanted to use as little react as possible and use native DOM apis when possible. React would be used purely for state management or interactivity. I feel like teams that have used react enough learn that the less React you can use the better :) it's a great tool, but most teams use it because it's all they know and they don't know what they don't know about html.
- shimman 10mo ago
  Weird comment, I'm a web dev that has been using react for 10+ years and I prefer using native browser features whenever possible. I'd honestly avoid hiring framework specific devs because the skills required are never about just one single framework. Also this is just all JS + HTML here, let's not act like it's impossible to learn the most popular frontend tool at the moment.

augustk 10mo ago

Progressive enhancement is the way to go if you care about technical excellence. For some reason it fell out of fashion. https://en.wikipedia.org/wiki/Progressive_enhancement https://en.wikipedia.org/wiki/Progressive_enhancement

_heimdall 10mo ago
It fell out of fashion because the entire web was consumed by react.
petepete 10mo ago
> if you care about technical excellence Or accessibility.

herpdyderp 10mo ago

Before anyone wastes a lot of time like I did trying to use the popover API: it is not ready yet. You can do very basic things in all browsers but positioning is still different and/or totally broken per browser.

senfiaj 10mo ago
Yes, HTML & CSS alone won't replace JS. Of course, for complicated form validation HTML is not sufficient. But IMHO it's very important to provide basic functionality in HTML / CSS as much as possible / reasonable. Moving the functionality to HTML / CSS can potentially improve the SEO. As for positioning, there is an experimental feature @position-try. Here I made a small demo where it handles overflows. https://waspdev.com/articles/2025-06-29/css-features-web-developers-should-know-in-2025#handling_overflows_with_position_try_fallbacks https://waspdev.com/articles/2025-06-29/css-features-web-dev... But yeah, that's kind of limited if you need nice animations or some other complicated thing. Although it's fun.
extra88 10mo ago
Yes, popover's uses are limited without CSS anchor positioning but it will be supported in all major browsers very soon. In the meantime, there is a polyfill to load in browsers without support. https://caniuse.com/css-anchor-positioning https://caniuse.com/css-anchor-positioning

Devasta 10mo ago

JavaScript is the primary language of the web, HTML is just the payload carrier. I don't want it to be this way, but HTML has nothing approaching even one tenth the ambition of XSLT and XForms. If HTML were proposed today, you would be laughed out of the room.

nasso_dev 10mo ago

i like the points the article makes, but i really wish it used looping videos instead of actual GIFs i don't really see any reason to use GIFs here; any widely available video codec like H.264, VP8/VP9 or AV1 will result in significantly smaller file sizes, look better, and will allow enabling controls for seeking and play/pause

zaidf 10mo ago

The problem is that CSS continues to be a pain in the ass, even as it evolves. There is no other reason why something like tailwind should have the traction it has.

edwardtay 10mo ago

The <details> and <summary> elements are great, but I think the bigger missed opportunity is the lack of inline examples/demos on the page itself. Would be much more powerful to actually show these working rather than linking to external codepens. A few thoughts on the practicality: 1. Progressive enhancement is the real win here, not "replacing" JavaScript. These HTML features provide a baseline that works without JS, then you enhance with JS for better UX (animations, state persistence, etc.) 2. The details/summary approach breaks down when you need: - Custom animations/transitions - State synchronization across multiple elements - Analytics tracking on user interactions - Keyboard shortcuts beyond basic tab navigation 3. What about the <dialog> element? That's another underutilized HTML feature that could replace a ton of modal/popup JavaScript. 4. Have you explored the Popover API? It's getting broader browser support and handles a lot of common UI patterns without JS. The spirit of "use the platform" is great, but the title feels a bit clickbaity - you're not really replacing JS, just avoiding it where unnecessary. Which is good practice anyway!

conception 10mo ago

The switch from everything tables to everything divs was one of the worst for usability on the web. Every day I run into a table of data that doesn’t sort, copy/paste, search, resize columns or any of the very trivial items to do with tables. It always infuriating.

peesem 10mo ago

why are people so obsessed with restricting details/accordion elements to only one open at a time? let me open what I want to

zenmac 10mo ago

One good thing about NOT having JS is what the page can function in Tor Browser's "Safest" mode! A step down is to have JS only on your domain. "Safer" mode. Try to avoid web site that require "Standard" to view and run properly.

cess11 10mo ago

In my mind "Just HTML" does not include CSS.

hinkley 10mo ago

I was stuck on the backend while CSS3 absorbed most of the functionality of Less and Sass and now I’m trying to play catchup. If there had just been a CSS4 I’d be able to find a tutorial to teach me everything I missed in the interim.

1vuio0pswjnm7 10mo ago

"Nothing against JS, but it has better things to do than setup and manage your accordions or offscreen navigation menus... " Perhaps this is referring to "things" such as data collection, surveillance and ad services It would be interesting to see how Big Tech and other adtech companies would accomplish the same level of data collection, surveillance and ad services without the use of Javascript As for "nothing against JS", I think some web users (cf. "developers") who dislike adtech and the ad-laden web they perpetuate might have something against it

littlecranky67 10mo ago

My personal pet-peeve everytime a "you don't need JS" post comes up on HN, is the disconnect between the interface designers and the developers. In my dayjob as a (mostly react) freelance contractor doing B2B and LoB apps, there are always UX designers coming up with the screen- and interface designs. I don't think any project I ever were, could have matched a screen design I was passed without JS. Whether it being business requirements (has to work in IE, or nowadays has to work in Edge), or simply hard visual design choices. My favorite example is that of a date, date-time or date-range picker. Yes, there are HTML native elements. But they look absolutely ugly, styling only goes so far, and good luck with requirements such as "oh, but in the popup on the date-range picker, add a topbar with 3 buttons that trigger preselection and a dropdown". Now you can argue and communicate back that we save a lot of technical complexity in the stack if we stick to the HTML native solutions. But all those discussions basically end up managers and UX designers having no clue about the actual complexity and savings (time and money wise for future maintenance) and simply don't care. And if I am the one telling them "Look, in the HTML native date-time picker, you can't add custom elements, you can't fully customize every bit and piece of behaviour so change the screen designs" they will just fire up random corporate website XYZ and show a similar version of what they have in mind (and it is always JS-based) and suddenly it looks like me being unable or unskilled to achieve something, that is clearly doable as others have done it. Now not all is nice and shiny in the JS/React world. We use MaterialUI in a current project, and the commercial MUI-X DatePickers. They also come with their limitations, but it is just they are far more powerfull and customizable to actually meet the requirements and demands of UX and management, compared to the HTML versions.

srikanthdotch 10mo ago

Most people think that you should remove JavaScript to load your sites faster or for reasons like that. You have to learn to balance things, always use it if you need some good interactivity, validation etc. Don't try to use HTML only to force things.