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

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

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.

Comments URL: https://news.ycombinator.com/item?id=45035015

Points: 5

# Comments: 0

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.

Comments URL: https://news.ycombinator.com/item?id=43338898

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=39113383

Points: 82

# Comments: 41

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