I've been prototyping a tool for frontend/end-user programming in React, and found myself in need of access to its internals to build the UI I wanted, but found the API for that convoluted. But I recently learned of this little library called hyperapp. Its source code is only a couple hundred lines long and is very straightforward compared to React, and in my case patching in the reflection capabilities I needed was simple(just one line of code). If you're interested in prototyping new ways to build interfaces that rely on the React model it seems like a good starting point: https://hyperapp.dev/

I like the fact that this thing is only 500 lines of code:

Adding to @Kartik Agaram's paragraph: very few people have ever experienced remixability. It's not something you miss if you haven't seen it before.

Popular systems today are most often built by a product team at some company that believes they figured out some core set of feature that will appeal to a wide audience so they get lots of people to subscribe / give away personal data (depending on business models). It has become entrenched in tech culture that that's just how you do things: you build a single product with a single team in control, so the only path available is to find the most common set of features and build those. The long tail of niche requests from smaller segments is effectively impossible and always ignored in today's most common way of building things.

the examples that immediately occur to me for remixability are minecraft and hypercard. things i’ve noticed: both felt like toys, had extremely weird and nontraditional economic incentives, were directed primarily at curious but extremely nontechnical users, originated as hobby projects, and expressly DID NOT have clear use cases

I don't know there is an easy answer. Coming from the perspective of games would I rather have 1000 systems from which I must choose 50-150 and then manually "mix them" (probably man years of work to really understand all the ins and outs of each system). Or do I just want Unreal/Unity which already made the choices and I can start immediately on the core of the experience I'm trying to provide instead of man years of engineering prep first. I'm not saying one is good and one is bad. Only that reasonable people can choose choose either the large system or the individual systems. Individual small flexible systems are not unambiguously better. So, that to me is a counterexample to small mixable pieces. On the other hand, it's rare to find good libraries that don't try to do too much or are flexible and off the top of my head I see at least 2 common reasons. Reason 1, the writer of the library is not experienced enough to write a simple, flexible library. Reason 2, the less experience you have the more you like handrails so there is both the incentive from yourself since you lack experience you think handrails are good and the incentive from the millions of inexperienced developers who will judge your library poorly if they need any coding experience to use it. To give an example of this second issue, imagine any library that processes data. I think the experienced programmer (maybe you'll disagree) might prefer that the only input to this system is a an abstract "Reader" (or a function to read if you want to think in functional terms). The user can then provide a "reader" to read a file, read from memory, read from the network, and probably do that in as little as a 1-3 lines of code. This means the library is easily remixed in any environment. But the inexperienced programmer doesn't know how to write that line of code to provide the reader so they'll hate on your library and prefer the one that takes a filename, or a network address or a binary array, or a websocket, and because of that the library will need to pull in 100k lines of support code for file i/o and networking etc... and therefore tying it to specific implementations of those features and then when someone suggests they need it to work with different implementations they'll hack in some afterthought of a configuration option instead of realizing they shouldn't have tied things together in the first place.

@Garth Goldwater what's super interesting about both Minecraft and Hypercard are the strong and unique cultures of amateur remixing that sprung up around them. I don't think this happens just by accident, nor entirely by the creator's intent(Notch was not very supportive of Minecraft mods at first), I think a lot about what conditions foster it.

definitely! both seem to have been limited in scope enough to both require customization/creativity and also limited enough to make that feasible for hobbyists. another thing is that those mods or hypercard stacks ended up being likewise limited enough that they were amenable to further remixing by other hobbyists for like refinements on refinements

"how can we swing back to a more remix-friendly environment? What creates incentives for that?" errr... pay developers to use a remix-friendly style? Open standards and open source are approaches that (at least to a greater extent than proprietary products) are remix-friendly. Beyond that, we need people to work on platforms designed from the ground up for 'remixing'. But rarely is any private company willing to pay for that sort of thing. The idea I've always had in mind is government funding for "open engineering", the same way science is funded, except that the work products would be FOSS instead of PDFs. To make sure the work products are labors of love ... people working on them should be underpaid, but on the other hand the barrier to entry should be as low as the pay scale. I'd sign up immediately.

I like how your comment talks about government funding but emphasizes underpaying people. That connection needs to be drawn more often.