The post is a tour of things plain HTML can now handle that many developers still associate with JavaScript or UI frameworks, including modal dialogs, popovers, grouped details sections, hidden content that browser search can reveal, datalists, and newer form and media features. The core reaction was enthusiasm that the web platform has finally caught up on a lot of bread and butter UI work, especially for server-rendered apps that want fast load times, less code, and better default accessibility. Several people said they are already shipping production interfaces with dialog and popover APIs, or are ripping out old accordion and modal code because the built-ins are now good enough.
The excitement came with sharp boundaries. The biggest one was forms. Datalist got called out repeatedly as an attractive demo that breaks down for real combobox needs because it does not enforce selection from the list, offers weak search behavior, and still has spotty support and rough edges in practice. Native date and time inputs got a similar verdict. They work, but their UI varies by browser and operating system, localization can be confusing, and many teams still need richer controls than the platform provides. That set the practical line for most readers: native controls are great for simple cases, but the minute you need strong contracts, advanced filtering, custom rendering, or polished cross-browser consistency, you are back in custom component land.
A second thread was that modern HTML makes the old server-rendered web more viable again. People connected these APIs to a broader move away from overbuilt single page apps toward pages that are linkable, bookmarkable, resilient without script, and interactive before JavaScript finishes loading. View Transitions, declarative popover actions, proper form naming, and grouped details were all cited as ways to get that experience without rebuilding everything in client code. The comments were especially hostile to the habit of recreating buttons, selects, and dialogs out of divs plus JavaScript. The consensus was not that JavaScript is obsolete. It was that many teams are still paying complexity costs for problems the browser now solves reasonably well.
If your team is still defaulting to JavaScript for every small interaction, it is worth revisiting what browsers now do natively. Keep native HTML as the baseline, then add custom components only where the product truly needs stronger search, richer date picking, or tighter visual control.
Mostly positive and a little exasperated. People like that modern HTML and CSS finally cover many common UI needs, and they are frustrated that teams still reach for custom JavaScript by reflex. The negative edge comes from native controls still failing in important product cases like comboboxes, date pickers, styling, and uneven browser behavior.
Key insights
01
Popover is real now, positioning is the catch
Popover and dialog are no longer toy APIs. People are using them heavily in production because top-layer rendering, automatic stacking, and cascade-close behavior remove a lot of the brittle plumbing that custom overlays used to need. The remaining pain point is placement near the trigger element. CSS anchor positioning helps, and some say it clicks once you use it, but support is still uneven enough that this is where native UI stops feeling effortless.
Use native popovers and dialogs first for overlays, menus, and confirmations. Budget extra implementation time if precise anchored positioning is central to the interaction, and verify browser support before making it your only path.
Datalist covers the demo version of autocomplete, not the product version. It lets users type arbitrary values, does not give you rich search or typo handling, and in practice still has enough support and behavior problems that teams building serious forms keep swapping it out for custom comboboxes or a small framework island. That changes how to read the original post. Native HTML has advanced, but one of the most common enterprise form widgets is still not solved cleanly.
Do not standardize on datalist for IDs, people pickers, or any field where the user must choose from a controlled set. Treat it as a light enhancement for simple suggestions, not as a replacement for a proper searchable select.
Native pickers are convenient until your product needs consistency. Date controls submit normalized values, but the displayed format follows browser and operating system conventions, which can confuse users in multilingual or cross-region workflows. Color input has the same issue in a different form, with entirely different picker UIs depending on platform. This is where native controls stop feeling like universal building blocks and start exposing the host environment.
If support tickets or internal workflow depend on everyone seeing the same control and same format, test native inputs on real target devices before committing. For admin tools and specialized workflows, a custom picker may still be the lower-risk choice.
Declarative actions for popovers and dialogs were defended not as syntactic sugar, but as infrastructure for pages that are interactive before scripts load and still work under stricter security settings. That fits a broader push back toward server-side rendering, where fast time to interactive, direct links, and graceful degradation matter more than keeping all state in a client runtime. The interesting shift is that newer browser APIs are no longer just competing with JavaScript frameworks. They are making the old multi-page web feel modern again.
If you are rethinking frontend architecture, native HTML features now materially improve the case for server-rendered interfaces. Re-evaluate whether a full client application is buying enough to justify its operational and performance cost.
The hidden-until-found behavior landed as more than a curiosity. It solves a concrete usability problem for accordions, tabs, trees, pricing footnotes, and other collapsed sections that used to disappear from on-page search unless users expanded everything first. People also pointed out that the same reveal-on-find behavior can be controlled on many hidden elements, which makes it a broader content-disclosure tool than the original examples suggest.
If your product hides large amounts of reference content behind tabs or accordions, add reveal-on-search behavior instead of forcing users to manually expand sections. It is a small change that removes a surprisingly common navigation failure.
Several comments pushed past specific APIs and argued that the biggest mistake in frontend remains replacing semantic elements with generic divs. Buttons, links, forms, and disclosure widgets already carry behavior, keyboard support, and accessibility expectations that custom markup has to painstakingly rebuild. The post resonated because it reminded people how much needless complexity starts with throwing away the browser's defaults before the real work even begins.
Audit your design system for components that wrap native elements instead of replacing them. You will usually get accessibility, input handling, and maintenance wins faster from semantic cleanup than from adding another library.
More native features also raise browser complexity
The strongest pushback was not anti-HTML so much as anti-accumulation. Every new browser capability becomes another target that alternative engines have to implement, which raises the cost of maintaining browser diversity and makes new engines less realistic. That does not argue against using mature features already shipped everywhere, but it does challenge the habit of celebrating every platform addition as free progress.
When adopting very new platform features, factor in ecosystem health as well as your own code reduction. If browser engine diversity matters to your users or your organization, wait for broad implementation before leaning on edge features.
One dissenting view was that not every interaction belongs in HTML just because browsers can absorb it. For things like sortable tables, a vendored JavaScript file under your control can be easier to customize than waiting for browsers to standardize a narrow built-in feature. The useful point is not nostalgia for jQuery. It is that native support is only a win when the browser primitive actually matches your product's needs.
Do not force native solutions where a small, stable local script gives you a better fit with less compromise. The right comparison is total complexity over time, not whether a feature can be expressed declaratively.
The platform is still catching up to old desktop UI
A historical counterpoint argued that this apparent progress is really the web clawing back capabilities desktop toolkits had decades ago. From that perspective, the celebration is overdue rather than impressive, and it highlights how much time the industry spent rebuilding basic widgets on a weaker substrate. That framing tempers the triumphalism around modern HTML without denying that the new APIs are useful.
Treat these additions as welcome repairs, not proof that the platform is suddenly complete. If you are building dense, application-like interfaces, keep a realistic view of where browser UI still lags traditional desktop frameworks.
chrisburnell.com