by levmiseri
3 subcomments
- 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.
by subdavis
11 subcomments
- 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.
- 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/
by montroser
5 subcomments
- 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...
- 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.
- 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...
- 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
- 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.
by overflowy
4 subcomments
- 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.
by hollowturtle
1 subcomments
- 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
by herpdyderp
2 subcomments
- 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.
by theandrewbailey
0 subcomment
- > 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.
- 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
- 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!
- 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.
- The Pentagram at the top of the page does not load without JS enabled.
- 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.
- 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.
- 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.
- 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
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.
by 1vuio0pswjnm7
0 subcomment
- "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
- 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.
- Nobody tell them about how much stuff can go into SVG. That can even be inlined within HTML source code.
by backtogeek
0 subcomment
- 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.
- Gimme a dark/light mode switch. CSS is allowed.
by iammrpayments
1 subcomments
- 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.
- why are people so obsessed with restricting details/accordion elements to only one open at a time? let me open what I want to
- 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.
by FormerlyEL
0 subcomment
- 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 which encapsulated a lot of the JS concerns into web components.
- 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
by shahzaibmushtaq
0 subcomment
- This is helpful when development revolves around static environment.
- It seems like an oversight that there isn't a native way for a popover to be activated by hovering over the target element.
- The Popover API looks really cool. Could see it for tooltips or lightboxes.
- I love semantic html. It feels so much more modern and efficient than all of these fashion-driven front end tools.
by avodonosov
0 subcomment
- I am reading the CodePen example for summary/details. Especially the CSS part.
Its so easy, like a breeze!
- 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.
- It feels like some variation of this post gets submitted here every week.
by only-one1701
2 subcomments
- 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?
by conception
0 subcomment
- 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.
- In my mind "Just HTML" does not include CSS.
- 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.
- 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.
by vijaybritto
0 subcomment
- 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
- <blink>
- 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/
- 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.
by cantalopes
0 subcomment
- 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
Hacker News