The vulnerable code exists inside of the React Flight wire protocol that is used by Next.js but also Vite, Parcel, Waku and any other custom RSC implementation that exists. Your comment was accurate circa 2019 but not since React released server components.
This POC is not realistic and doesn't work against production builds of Next.js. It requires explicit exposure of gadgets by the user (eg. vm.runInContext) so is invalid as noted on https://react2shell.com
The React Server Components wire format (Flight) is relatively novel and very new (it has existed in React stable for just a year). This is not a simple JSON parsing bug.
Observables and Generators (iterators) are fundamentally different. Observables are push-based (like a promise) whereas iterators are pull-based (like a function).
Glossing over this fact leads to a flawed understanding, not a deeper one.
Things mostly just work. Remember Node.js is mostly APIs on top of JS the language. If those tools compile to JS in the browser, they can compile to Deno. Deno is a more stabdards-based runtime than Node, it's closer to how the browser works.
I don't think Firefox was reading any QR codes, but instead was recrawling the link in the "Recents" list on a new tab or bookmarks screen.
This is in no way a problem. There is precedent for browsers eagerly loading links, it happens all the time in regular webpages. This is most of the reason why anchors should be safe/side-effect free.
Using the Web Platform and using React are not opposites, you can do both. See: Remix as a framework that bakes in these ideas, but using the platform is easily achievable yourself too.
Making this distinction between HTML <form>s and React shows a clear misunderstanding of the programming model that React provides. It targets the platform in a native way. This is how React DOM, React Native, and libraries like Ink[1] work.
I wouldn't agree that Deno showed that, as I said many companies are making a lot of money from non-Node JS runtimes.
The players I mention have built their own runtime, they're mostly all built on V8 isolates (including Deno Deploy).
This is why I struggle to see where Bun fits in the edge JS world, as far as I understand it JSC has no Isolate primitive meaning Bun would have to write this from scratch (or salvage the other parts of WebKit that offer isolation). Otherwise Bun will be limited to using Linux containers on the edge, at which point you re-introduce the startup time you gained by switching from node in the first place.