> March 31, 00:21 UTC: axios@1.14.1 published with plain-crypto-js@4.2.1 injected

> March 31, around 01:00 UTC: axios@0.30.4 published with the same payload

> March 31, around 01:00 UTC: first external detections

> March 31, around 01:00 UTC: community members file issues reporting the compromise. The attacker deletes them using the compromised account.

So it was found out almost immediately.

https://www.youtube.com/watch?v=1sd26pWhfmg

Looks like LLMs are getting good at finding and exploiting these.

The simplest option is to use some basic object storage service and it'll usually work well out of the box (I use DO Spaces with built-in CDN, that's basically it).

To be fair, React is especially wasteful way to solve that problem. If you want to look at the state od the art, something like Solid makes a lot more sense.

It's much easier to appreciate that problem if you actually try to build complex interactive UI with vanilla JS (or something like jQuery). Once you have complex state dependency graph and DOM state to preserve between rerenders, it becomes pretty clear.

Yea, cypress has this in their anti-patterns:

https://docs.cypress.io/app/core-concepts/best-practices#Usi...

Dangling state is useful for debugging when the test fails, you don't want to clean that up.

This has been super useful practice in my experience. I really like to be able to run tests regardless of my application state. It's faster and over time it helps you hit and fixup various issues that you only encounter after you fill the database with enough data.

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

Points: 2

# Comments: 0

In my experience, this heavily depends on the task, and there's a massive chasm between tasks where it's a good and bad fit. I can definitely imagine people working only on one side of this chasm and being perplexed by the other side.

Yea, I'd bet it's that. Ideally, you'd want to stop writing C++ and continue with Rust on all new code, but Rust has stricter semantics, so the interop is somewhat "easy" in one direction, but very hairy in the other direction.

This means that in practice, you want to start porting from leaf components and slowly grow closer to the root, which stays in C++ for quite some time and just calls into Rust through C API (or something close to it).

If you're curious about the topic, there's a interop library called Zngur (https://hkalbasi.github.io/zngur/), which is built on this assumption. They have a pretty good explanation of the concrete problems on the homepage.

You can model these with reference counting, but this turned out unfeasible in browsers. There's a great talk from when Blink (Chrome) transitioned from reference counting to GC, which provides a lot more details about these problems in practice: https://www.youtube.com/watch?v=_uxmEyd6uxo

> I'd get it if they were writing the UI in this, but the rest of this post is about the JS engine.

I think this might be the reason they started with the JS engine and not with some more fundamental browser structures. JS object model has these problems, too, but the engine has to solve them in more generic way. All JS objects can just be modeled as some JSObject class/struct where this is handled on the engine level.

DOM and other browser structures are different because the engine has to understand them, so the browser developers have to interact with the GC manually and if you watch the talk above, you'll see that it's quite involved to do even in C++, let alone in Rust, which puts a bunch of restrictions on top of that.