caseyross

Interesting idea. I feel like it could be productive to categorize operations by their result shape as well:

- Row select: From N rows, produce 0-N rows.

- Column select: From N columns, produce 0-N columns.

- Table add: From MxN and OxP tables, produce max M+OxN+P table.

- Table subtract: From MxN and OxP tables, produce min 0x0 table.

This line of thinking reveals some normally hard-to-see similarities, such as `groupby` and `dedupe` sharing the same underlying mechanism. (i.e., both are "collapsing" row selects.)

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.

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.

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.

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.

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.

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 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.