You're looking for `@vue/reactivity`[1] - looks like it provides ref, computed, watch, and some internals.
Honestly, this seems pretty nifty. Most projects I'd do today would likely have more value in Vue as a whole, and it's nice to see these kinds of things exposed and standalone bits
This looks cool, but standalone usage doesn't seem to be documented anywhere. The README for the above package says "For full exposed APIs, see src/index.ts."
So while Vue is not gatekeeping their reactive primitive library, they aren't exactly advertising it like Preact in a way that the average library author (like Mador's author) might even be aware of it.
Also as someone who has built React applications for more than 7+ years, I'm also still not sure what React's reactive primitive package is. Googling or asking ChatGPT has turned up nothing.
I have a handful of mugs that I've had for decades at this point, a couple even from my parents kitchen that they used some 30 years and probably before then.
And then there's thrift store mugs - sure they were almost certainly trucked to _somewhere_ a long time ago.
> a chat window is actually HORRIBLE for many tasks. i really strongly hope this isn't what the future of software looks like
I strongly concur - I don't want to "tell" the app to level the audio between several clips only to have it level everything to 0 and then take five minutes to undo etc
Everyone always views it through the current UX when I say stuff like this. The way I see it is we're in the DOS/UNIX era of LLMs where you're just staring at an empty text input box, it's slow, breaks often, GUI integrations are non-existent or primitive, etc.
I dropped Reddit after the Apollo/API fiasco and came here, and it's been a good change. I still skim Facebook occasionally for niche group stuff, by and large I just don't consider Reddit save for searches that take me there but the constant flood of interstitials has me avoiding it more and more even then
I 100% agree. I've been working on a component library rebuild at work and accessibility is a key focus, granted I don't think that would be the case if some of our contracts didn't mandate it but it's fiiiiiine
I'm someone who enjoys this kind of work, especially when the target is a stylized drop down - I got to spend a week with the MDN page for the ARIA combobox open, trudging through all of the ins and outs of keyboard accessibility and I know I'm still missing a couple things (typing when the control is focused but not open, for example), and having clearly defined specs is something we don't seem to get a lot in webdev
My go to when implementing custom controls that can't be achieved in native HTML is the ARIA Patterns (https://www.w3.org/WAI/ARIA/apg/patterns/) site. That has clear documentation on the roles, states, and keyboard interactions for common UI controls. I've used it for things like a search bar with an autocomplete dropdown to get the keyboard interaction right.
I'm too lazy to look it up, but someone on HN linked a drone test done with an AI pilot that was tasked with destroying surface-to-air missile targets (in a simulation). At one point, the human operator instructed it not to hit certain SAMs, and since the goal was to destroy SAMs, the AI took out the base with the human operator.
On the next run, they instructed it not to take out the human operator in pursuit of its goal, so instead it targeted the radio towers the human used to instruct it.
In world war II testing of homing torpedoes had the same fluke.
I think the problem with automation is seeking general automation. The word can have two opposed meanings: constrained behavior, as in "if X happens, the system will automatically do Y" and flexible behavior, as in "whatever you say to the chatbot, it will concoct a response that engenders a natural flow of conversation".
If you want a system to be autonomous, you need constrained behavior. It takes a lot of time to debug and work out all edge cases. Flexible behavior is bound to run into trouble at some point.
I think that is the fundamental issue with the LLM-chatbot-agents stack approach to AI. It looks autonomous at the surface, but the flexibility is bought at the cost of reliability. When you strain a system based on that stack it breaks. But the illusion of flexible behavior looking autonomous before it breaks is too strong.
1. It's explained in the README [1]. Tl;dr: Maiao is a "remote, sparsely populated volcanic atoll in French Polynesia"
2. I don't think so. The main difference from maiao to other stacked diffs projects is that it _progressively enhances_ GitHub. At the end of the day you just get PRs with branch #3 -> branch #2 -> branch #1 -> main. So, a bit of automation and rebases to do this. Because teams rarely can choose their forge, the intent is to not force org-wide change — e.g., change the VCS to jj — nor introduce more API/UI surface. You can be the only one doing stacked diffs in your team. Nothing breaks.
jj can work with git as its storage, so all of its commits are git commits, so a jj-local and git-remote flow is fully supported. I use it, and as far as I know I'm the only one on my team doing so.
I'm much more attentive in some meetings when my hands aren't on the keyboard. For particularly important meetings I'll get out my knitting so that I can be close by while having something that's not failing unit tests occupying my hands
Honestly, this seems pretty nifty. Most projects I'd do today would likely have more value in Vue as a whole, and it's nice to see these kinds of things exposed and standalone bits
[1] https://github.com/vuejs/core/tree/main/packages/reactivity/...
reply