Hacker News new | ask | show | jobs
by inopinatus 2014 days ago
I was sold on hey.com's UI design already because it's using <details><summary> for dropdown menus.

The really fun part, though: the summary content isn't just a menu icon, it's a trigger for some (currently unpublished) Turbolinks variant. The menu content is loaded (and subsequently 304'd) dynamically as a server-rendered partial (sans layout).

Most tellingly, if you visit the menu content's XHR URL with regular browsing then hey.com renders that menu as the sole content in a page layout.

We can't see the server-side parts yet, but if that becomes an out-of-the-box end-to-end behaviour within Rails, then in conjunction with Stimulus 2 and Action Cable I'm stoked about the possibilities. Especially so since I have a mission to replace all my dropdown & modal boilerplate with <details><summary> and <dialog> elements, and I like to build services that still work if JS is disabled. But it's also good for mundane stuff like progressive form validation in line-of-business apps.

2 comments

Based on my casual browsing of the code I assume that it pushes small HTML fragments via WebSockets whenever the backend state changes on a given ActiveRecord model. It covers things like automatically updating the state of a model on a page, adding, removing, reordering elements etc all without any custom code so long as things are wired up correctly.

Basically, all the "re-activeness" of an SPA but without ever having to worry about the concept of client side state management at all.

Edit: I am a grumpy old man in web-dev years who hadn't ever really looked into Phoenix Live View before now but after watching a video on how it works, yes, my understanding is that it works basically the same way.

That sounds pretty similar to Microsoft's Blazor (server side) model.
> Especially so since I have a mission to replace all my dropdown & modal boilerplate with <details><summary> and <dialog> elements, and I like to build services that still work if JS is disabled.

Can you elaborate on why `<details><summary>` is specifically exciting to you?

It works without Javascript, which means a few things.

Firstly, for customers; it works behind asset-blocking insane corporate firewalls, or for some poor schmuck in the sticks getting one bar of cell data and just enough to load our HTML, or simply to impress anyone running uBlockâ‚€ in Advanced mode.

Secondly; because front-end Javascript bitrots faster than any code I've ever seen in four decades in tech. Reducing the quantity of JS in favour of letting the browser just do its job, is one of the best investments I can make against technical debt. JS can't be abandoned completely, but I measure every kilobyte jealously, and graceful degradation to baseline browser behaviour is my north star; simply using baseline browser behaviour is by definition my optimum limit for long-term productivity.

Thirdly; for folks depending on assistive browsing technologies. Yes, they do work in the face of dynamic web pages & SPAs, but many screen readers are still at their best when tabbing through plain HTML with a sprinkling of ARIA markup.

Finally, it's also a simple yet versatile mechanism. Good for anything from FAQ items to dropdown menus, even with default styles.

You can try inspecting dropdown or button that shows modal on Github.com, they are using it all over the places.