Good call they’re styled links, I will give that a try!

Are your buttons actually buttons or just styled links? If the latter, try making them actual buttons in a form with method POST. Not a guarantee that rude software won't trigger it, but it's less likely to be done by accident.

Perhaps it should just be a wizard that asks one question at a time as necessary.

You simply can't get most people to accurately and completely express their intent. Most people will express very few necessary details. "Find me a flight" will be what you get. Not "Find me a nonstop flight from Atlanta to Anchorage on September 27th after 4pm". People will leave out the details and you'll have to give them buttons and autocomplete anyway. I agree with simplifying complex processes with simple decisions but expecting average people to accurately express their intent is a fool's errand.

Reading through the article I wasn't sold on the argument until I came to third example:

Many traditional productivity tools require you to manually construct task lists, drag items across Kanban boards, and assign micro-deadlines. Goblin.tools is a free, single-page suite of single-task AI tools designed specifically for neurodivergent users or anyone feeling overwhelmed, requiring zero sign-ups or configuration.

Many interfaces can be too overwhelming, particularly for neurodivergent folk, so it's important to consider different paradigms for interaction.

Rather than expecting our users to learn complex menus and click through elaborate sales funnels, these platforms operate by capturing [INCORRECTLY GUESSING]* high-level human goals and silently executing the grunt work in the background, [LEADING THEM DOWN THE GARDEN PATH]*.

*FTFY

Fucking CAPTURING? JFC, GTFO. The absolute audacious bullshit hidden in corpospeak.

No, thank you. Wipe this shit off and flush it.

They probably consider it "doing a good deed" in exchange for harvesting your content to feed Gemini

A toggle is not the best solution to your problem.

100% correct. Unfortunately I'm far more likely to have access to a toggle than for them to make their dark mode nice.

E.g. I've asked them to add more languages to the code button in their WYSIWYG editor for replying to tickets. I don't use/do any web stuff but I had figured out that they use Froala, and Froala uses prism.js. I asked them to include 5 more languages (bash/sh/shell, batch, ini, json, Powershell) and requested that the list be sorted alphabetically, and told them it should just be a matter of changing the Froala codeSnippetLanguage plugin option. I haven't even had a reply in 5 months.

I also spent some time trying to modify the WYSIWYG editor options myself using a userscript but didn't get anywhere useful.

Why is this so messy? I understand nothing from it.

our ticketing system’s website I put in light mode (even though they have a dark mode) because their dark mode looks like shit.

Once, a client asked me to put a spinner on a page that was slow to load. I made the underlying SQL query 2000 times faster instead.

A toggle is not the best solution to your problem.

When I loaded this page on my phone (Firefox on Android), the colors changed several times during loading, then the layout shifted so that only a third of the screen was used for text. That makes taking the author's thoughts on web design seriously difficult.

Setting aside the fact that WebSockets are a well-defined mechanism for maintaining a persistent long-running connection to a web server...

This is how .NET Blazor works (for one of its modes), where all rendering and processing is done server-side, and the client just has a small JS/WASM bundle that posts updates to the DOM, and sends DOM events to the server. And it's ASS.

Yeah he has rediscovered long polling.

It probably wasn't clear in my post but I'd be happy with the toggle being in the browser (not something I've historically thought about but a great idea), it was more about the existence of a toggle.

I do agree with @jaredwhite@humansare.social that having the toggle in the header is a waste of space. Same with horizontal tabs.

Maybe there's a case to be made for a theme setting on a screen somewhere. Or as others have said, this could be set at the browser level per site.

I just think having a toggle up in the header is sort of a UX waste.

I think the better alternative would be for browsers to have some kind of per-site override instead of relying on every single site building the same system and putting the option in a different place.

If a setting is universally supported by all sites (which dark mode should be, along with the other common accessibility flags), it shouldn't be something that the site needs to control.

if we keep the HTTP connection open indefinitely, we can dynamically update the page from the server, without any JavaScript!

Isn't that what chatrooms did back in the 1990s? I'm 90% sure that's how they did it back then

Do you mean altogether unnecessary, or unnecessary as a persistent toggle on the main screen?

If you're talking about the former I'd disagree, easiest way to explain is with my own real-world example.

I put basically everything in dark mode, but our ticketing system's website I put in light mode (even though they have a dark mode) because their dark mode looks like shit.

Yes. Toggles are unnecessary, a phenomenon of weird nerds. Just match the system settings and you're fine.

High performance ≠ JavaScript

I also know browsers have continuously gotten better at dealing with and adjusting to bad frontend performance

Citation needed

But I would counter that frontend performance is as important now as ever

Citation needed - it certainly feels like frontend performance was rarely seen as important in the past 10+ years.

So, again, anyone have a good ideas or thoughts as to why this field has erupted, and seemingly absorbed frontend?

Probably for the same reason that "programmers" got separated into "backend/frontend", so that it feels like you have more specialists, instead of asking them to do a good job in the first place.

*sweating* I don't need it. I don't need it. I don't need it...

Either this is a poorly written article or it is totally LLM slop.

Developers bragged about scale and beauty, and the brag couldn't be faked; the artifact proved it. Skill was the visible half of a pair. Taste rode along with skill.

huh?

It cannot.

I don't understand where your confidence is coming from, but I'd like to refer you to the proposal:

https://github.com/WICG/email-verification

3.1: The email selection is done through an <input> element. Populating this can be done programmatically.

3.3: The verification consent is out of scope of the proposal, so it can indeed be completely missing.

If you still disagree, then I frankly don't care. The mechanism behind this automatic verification is black-and-white and I've already outlined how it can and most likely will be abused by huge corporations.

Edit: Well would you take a look at that; I'm not the only person seeing this issue: https://github.com/WICG/email-verification/issues/51

Once the browser has discovered the issuer and knows that the user is logged in to the issuer, it is pretty confident that can provide an EVT, so it can choose to ask the user for permission. Each browser implementation is responsible for making their own judgement based on their user’s expectations, so this specification isn’t opinionated about how the interface with the user materializes.

Google has likely chosen to make the permission prompt a one-time thing, which seems fine to me.

However, at that point, the website can in fact check if you’re logged in to a specific email address automatically.

It cannot.