This is only "overcomplex" from a naive point of view.
Radio buttons, as with all UI controls, have tremendous inherent complexity, which comes to light once requirements ask for something beyond the blessed happy path of the default browser button. Pixel perfect styling, animations, focus behaviors, interactions with external state, componentized branding to fit in with companies' ecosystems, etc.
The baseline <input> paradigm struggles to provide the tools needed to adequately handle this complexity, even today, after many decades of web development.
And of course --- you can also argue that we should all just use the default browser button and everything should be solved. But this is also suboptimal, as it's clear from research that users prefer custom buttons if they provide more "features" than the defaults.
> it's clear from research that users prefer custom buttons if they provide more "features" than the defaults.
Hate to be asking for a "source", but what research? And what "features" can a radio button even have? You click it and it's selected. I suppose accessibility can be considered "features", but I'm strongly suspecting that the overcomplex button has worse accessibility.
> all UI controls, have tremendous inherent complexity
Well, this is true in a sense, but it's not exactly a good argument for re-implementing all that complexity in JS / HTML, instead of simply using the browser's implementation that's written in a real language.
>I suppose accessibility can be considered "features", but I'm strongly suspecting that the overcomplex button has worse accessibility.
Accessibility is incredibly hard to get right, particularly managing screen reader announcements, focus management and form validation. I recently had to build a website that met WCAG 2.1 requirements and it was made significantly easier by using React Aria (https://react-aria.adobe.com/) which is a similarly complex headless component library. To get an idea of the work that goes into making an accessible component, see their blog post about making a combo box where they test 4 different screen readers x 4 different browsers: https://react-aria.adobe.com/blog/building-a-combobox
(I haven't used Radix so I'm unsure how well they do a11y)
Agree, this kind of complexity is there for a reason. I would rather have a complex component that handles all the cases within its usage in the codebase over having a bunch of little hacks/changes in the usage. It's far easier to maintain one complex component than many different usages of that component.
And you don't have to use such a complex component library if you don't need it. For small codebases it often is overkill. But for large codebases it's a massively worthwhile investment.
But handling edge cases is a self-inflicted wound, because you have decided to re-implement something that already has an extremely well tested specification and implementation in the browser. This is almost always a mistake.
Author here. I've implemented all of these with the native radio button and CSS:
> Pixel perfect styling, animations, focus behaviors, interactions with external state, componentized branding to fit in with companies' ecosystems, etc.
Do you have a more specific example of something you've struggled with recently?
The real world is infinitely more standardized than virtual ones.
Physical space itself enforces a set of laws that make any two objects "compatible", regardless of any established interoperability agreements.
However, in software, there is no such constraint. Two randomly chosen software components are, in general, less composable than a chair and a galaxy.
This is the core reason why we have only been able to achieve interoperability in very specific domains. It's not because we're bad at design or planning --- it's because the space of ideas itself is simply so overwhelmingly large that it takes time and incredible coordination to get anything like pre-built IKEA blocks which fit together naturally.
There are for example products like keycloak. OpenID/OAuth2/Token/Security IdP in a box.
Why there is not ticket system in a box? Yeah, we all know Jira and friends, but these are products not building blocks.
Another angle is: Why the hack does everyone rewrite their microservice foundation. Inbox/Outbox/Worker Queue/Throtteling/tracing/..... What happened to the application servers of the past?
I am a big supporter of that narrative. Why do I need to write more than my dedicated business logic and wire up some UI (and do not get me started on UI space).
IMHO, this can be a real differentiator for the language platforms. Ruby has parts of it, but is still far of.
One reason might be that microservice foundations tend to become frameworks rather than building blocks.
Auth is a building block you can slot into your system and the shape of the hole isn't all that complex. A framework is something you need to slot your system into, and it has a lot of twists and turns so it ends up restricting how you do all the other things.
There are lots of microservice-foundation-related building blocks. E.g. I use a library somewhere that just does circuit-breaking. I slot that into my app rather than the other way around, and if I wanted to replace it, it's a fairly isolated thing. I don't use any frameworks for it though
Frameworks also tend to grow more and more complex as they evolve. If I as a user want a different auth for example, that needs to be supported by the framework. Over time, all things become pluggable and configurable, until at some point it's complex enough that someone restarts the process, or makes an opinionated spin of the framework.
_Every_ ticket system with an API (all of them) is a ticket system in a box. You can add that functionality to your application by talking to the API directly.
I think what you are thinking about is a standard API for ticket systems, that would allow you to transparently swap them. Unlike authentication, nobody has bothered to standardize something like that because ticket systems are more varied, not as often integrated into other platforms, and even more rarely replaced.
There exist stable solutions for all of this, at least in the java world. Spring Boot and the exhaustive Spring Boot auto configurations are all about this…
> What happened to the application servers of the past?
It‘s no called kubernetes. With the caveat of it not having first class integration for any language, but second class integration for all languages.
I would disagree. Software has certain constraints, or, for the search of a better concept, certain nature. E.g. I myself would say that one side of it is that you always have a very small tool that is supposed to operate on much larger data and can only manage this by doing many-many steps that have to be perfectly orchestrated. This is true to the low-level CPU, but as we move higher we start inventing things and can invent something that is rather different. E.g. on certain levels it may convincingly look that we send a bunch of elves against a bunch of orks. There is a multitude of such concepts, they are vastly different and, of course, incompatible, and it may look that they're all worth each other and what we choose is a matter of preference. Yet among them there is is a single concept that is special, because it is true to the nature of software; or is closer to that truth than others. It is not to be invented, but to be discovered. If we discover it, we will solve the problem of compatibility.
This doesn't match reality as soon as you start working with things that actually deal with laws and taxation. If physical space was standardised, we wouldn't have 366226723 implementations of asset management systems. Also compatibility depends extremely on the laws - is this chair and that chair the same? Not for taxation purposes because one is rented and the other is still depreciating, so you absolutely cannot say you have 2 of those chairs in the office.
> It's not because we're bad at design or planning
No, it is, code writers are bad at design, testing and debuging.
That's why LLMs are so popular: just throw together some code, see if it compiles.
How many (between them) incompatible GTK or QT versions are there ? Why someone has to come every few years with a new graphics library ? Is the JPEG, TIFF or PNG standard changed ? And who thinks that adding layers of abstractions solve problems ?
Advanced version from early 2000s (US), incorporating several additional lyrical-flow improvements on phrases seen in the Tom Scott video and TFA:
"Dashing through the snow - - on a pair of broken skis - - -"
"Down the hills we go - - - Crashing into trees!"
"The snow is turning red - - I think I'm almost dead - -"
"And now I'm in the hospital with stitches in my head! Oh, -"
"Jingle bells, Batman smells, Robin laid an egg! - - -"
"Batmobile lost a wheel and the Joker played ballet! HEY!"
"Jingle bells, Batman smells, Granny got a gun, - - -"
"? ? ?, and shot a man in 1931! HEY!!!"
Could be, although not that particular completion. The second chorus was rare and I'm kind of unsure about "shot a man". Can't edit previous comment but should have just put it as:
So, building on this, we can view Beat Saber not as a music game, but as a *dance* game that figured out a reliable, precise way to track player movements.
It's interesting to note that similar movement-quantizing systems are at the core of numerous other hit games, most notably in Dance Dance Revolution but also to some extent Rock Band and Taiko no Tatsujin.
I completely agree that's a dance game. Similar way that Guitar Hero is a music playing game. It's not exactly a dance but delivers something close to dance feeling.
My brain can't dance, can't even perceive dance. When I see dancing champions perform, their movements make no sense to me and seem completely unrelated to the music they are dancing to. However when I played Beat Saber occasionally I feel glimpses of the feeling of dancing. That's pretty much as close to dancing as I can get.
To me it's almost more of a meditation game, similar to how Guitar Hero or other rhythm games could get when you got in the zone, but full body. On a hard track you don't have time to think, just move. If you get distracted, you might fail.
While I agree with the spirit of the post, I think that there are better and worse times to start something new, and in retrospect 2014 seems like it was one of those worse times. The period from 2014--2024 was an era where the sheer gravity of the big tech platforms crushed out innovative startups left and right. People with an extreme focus on product polish could succeed, like Slack (est. 2013) and Discord (est. 2015), but it feels like most of the tech-sphere was either just working on half-hearted products towards an inevitable acqui-hire, or fervently trying to mainstream blockchain in a wishful attempt to create an entirely separate, more open ecosystem.
Yeah there are, but it's hard to know where you are in. So best just to have fun & create great stuff. If focused on making people's lives better you never really go wrong in the longterm.
The large IT companies are acting in ways that are completely against innovation and self-improvement. I expect them to freeze-up like the old giant corporations that they are.
But the change only started after the US decided to change its free-money-for-rich-people policy, and that was last year.
Well, a startup (ish…) is threatening Google, and VC money is much much tighter. So I’d say the Silicon Valley era is officially over. I hope y’all enjoyed it! I for one am a bit excited to see what’s the next big consumer idea to capture the zeitgeist.
I am looking forward to software devs being affordable to industries outside of martech and SaaS encumbents.
I think boutique software producs built in house for non-software businesses could provide immense automation and innovation to small/medium businesses. Not everything needs to be a SaaS, highly boutique software could cater for exactly one business and be a really holistic advantage.
Realistically, even if it started to happen, the giants would simply swallow it whole, as they've done very effectively in recent times.
Long gone are the times where a small Google could disrupt a field and debunk everything around it.
OpenAI is half owned by Microsoft already. Without those resources they wouldn't be able to realistically compete against Google. So saying they are a "small startup" for me doesn't compute.
In my view this is a bit of wishful thinking. Today we have so many giants with monopolies that realistically competing in their space can only be done with huge amounts of investment. The one resource that has been dried up recently.
OpenAI. In my eyes, Google’s power is entirely in a) assets, b) an army of geniuses, and c) a brand that lets it maintain ubiquitous monopoly status over search ads. Google does a lot of other cute stuff, and they desperately want another revenue stream, but the simple truth is that the entire core of the company’s whole operation is search ads. Display ads are on the way out due to privacy concerns, and OpenAI has damaged both b and c.
I think that c might be inverted. It's the economic power/performance of their search ads that let them maintain a brand rather than the other way around.
To clarify: I think the reason Google control search is that the public likes Google, so there's no political will to enforce the law. It's starting to crack now with the "google search is bad now" narrative, along with the classic "google is spying on me" -- together, they've emboldened Biden's justice department enough to bring multiple suits.
I think Google's attitude of free products (Gmail, Google Maps, Android, and Chrome especially) has won it insane amounts of goodwill, and that's all that's keeping them at the top. Having worked at Google, I find it incredibly hard to believe that they have any sort of fundamental technical advantage when it comes to building a search engine. I didn't work on search and obviously didn't look for the secret sauce, so that assessment is based on company culture and attitude alone.
The last thing Slack had was an extreme focus on polish. As a chat system, it's hardly functional and far less so than irc which came before. Slack managed to sell chat to big corporations, that was its innovation.
2013 was a great time to join in the fray, I think the clarifying point is that you are working on the machine, you are not embodying the success or failure of the machines of that time.
I wholeheartedly support this. But frameworks exist for one simple reason: HTML has never been powerful enough for the work people do.
The last two decades of web UI framework development has shown, over and over, what people need out of HTML that they're not getting. Componentization is one big area, and fortunately, it's already far along the path of integration into the native web platform. But there's another, bigger, area, which has not seen a single ounce of integration into native HTML: reactivity.
So what if we could just solve that? What is preventing us from adding native reactivity to HTML, a language that already contains numerous interactive elements and hard-coded ties to JavaScript? Seriously, why is this not already implemented when we have things like Shadow DOM out there already?
We could get a huge amount of impact with just minor changes. In my view, HTML could meet 90% of peoples' reactivity needs with just two simple tags:
1. `<sync value='variableName' />`: Renders as a text node that shows the current (live-updated) value of the referenced JS variable. If the value is undefined, renders nothing (special case).
2. `<test if='variableName'></test>`: Renders as its children if the referenced JS variable is truthy, and as nothing if the variable is falsy.
That's it. Just these two almost-trivial tags would solve an incredible amount of use cases. And with sufficiently expanded componentization (say, React-style props for `<template>`), the web platform would be well positioned to cover all others in time as well.
(You can toggle the layers to switch between no/some/many rat data. Sorry about the colors, best I could find. More purple = higher frequency of rat observations.)
Isn't it more likely to be the case that no one was willing to pay for the investigative journalism?
You see this everywhere. The clickbait is a funding source for the real work. Journalists almost never want to push garbage on the public --- they're usually forced to by management, either as an attempt at growth-at-all-costs or as a revenue source of last resort.
The rebuttal to that is that neither worked. They wouldn’t have switched if the original style worked. They wouldn’t have gone bankrupt if the switch worked. They would have gone back to the original style of it worked before the switch.
Yeah my comment wasn't actually intended as "rebuttal" so much as an observation that something is seriously broken in traditional news media.
It is a business, and so it is reasonable to have to just accept that a certain amount of sensationalism, click-bait and other "metric-increasing" tactics will be omnipresent so long as "traditional news media" continues to exist in some form. I've read that this has always been the case anyway, and people complaining about it is as old as people complaining about taxes. But clearly the target audience is just not buying what they are selling these days, no matter what that is.
I suspect that, in addition to the Internet putting serious competitive pressure on print media, social media is also playing a big factor in the demand for traditional news outlets. In current year, everyone is carrying a camera with them at all times and the ability to publish content instantly. When most people are so "connected", such that they can find out what is happening around them the instant it happens in a quick clip or headline, what use is there for long-form articles?
I would just say that, the internet allows for more niche things in general. If you want more sensationalized articles, it’s got that, if you want more rational takes, it’s got that. I can get exactly the flavor I want and in that sense why would I watch something that by definition has to cater to everyone. Similar to music, why listen to the radio when I could listen to the exact music I want 24/7.
Less a bug with news organizations and more a feature that the internet enabled. This same thing has played out in a dozen different industries for the same reason.
The big underlying factor is that so many software prices are artificially low because they're subsidized by collecting and making money off of users' personal data.
Unlike with physical goods, users don't know any "objective" ways to judge the fairness of software pricing. So they see (monetarily) free software everywhere and think that good software is cheap to make.
You can view the subscription/purchase debate as a second-order effect of people just not wanting to pay much for software, because they think that's what it's worth.
For comparison, US median house prices are up by 42% over the same period [1]. Hospitality prices (especially for traditional hotels, which raised rates by about 10%), are actually significantly trailing inflation.
Radio buttons, as with all UI controls, have tremendous inherent complexity, which comes to light once requirements ask for something beyond the blessed happy path of the default browser button. Pixel perfect styling, animations, focus behaviors, interactions with external state, componentized branding to fit in with companies' ecosystems, etc.
The baseline <input> paradigm struggles to provide the tools needed to adequately handle this complexity, even today, after many decades of web development.
And of course --- you can also argue that we should all just use the default browser button and everything should be solved. But this is also suboptimal, as it's clear from research that users prefer custom buttons if they provide more "features" than the defaults.