In theory that’s true (although observables are for reactivity too), but Angular uses observables for its http library and http requests are very much not streams. It’s one of the main downsides of working with Angular, the http library is mediocre and does come with the added overhead and complexity that rxjs brings.
Until this release (if you only use stable features) using forms meant dealing with observables too, even if you just want to read data when submitting a form and validating some data on change/blur.
And often you’ll find that your data from promises, observables and signals need to interact with each other, which can be annoying.
Fortunately the situation with signals and their async usage is improving, and iirc the Angular team wants to make rxjs optional, but until it is Angular can be a confusing mess on some points.
I partially agree, there is an overlap between signals and rxjs, however the core business is different- observables are about data manipulation, while signals are about efficient state management.
Regarding angular I agree, rxjs was a bad choice for data management, and before signals arrived I abandoned rxjs in favor of mobx in my angular projects. However you could roll your own http client, we used axios, and using DI it’s a drop in replacement.
But why is push vs pull the definition of reactivity?
I suppose we can say that there are different kinds of reactivity. Signals is one kind. Observables à la rxjs is a different kind (the whole model of programming with rxjs was referred to as "functional reactive programming"). Observables are push-based. Signals, as I heard, are a more complex primitive, which, under the hood, is push-pull.
React's reactivity model may be crap; but this doesn't make it non-existent.
Maybe push pull wasn’t the best metaphor, but the point is that everything can be reactive, it only depends on how much boilerplate you need to write to achieve the desired result.
Since react doesn’t have a true reactive model, you need to subscribe to changes manually (use effect) to create computations, while in signals it’s a primitive (computed).
I actually created a lib that operates signals over reacts state management (https://roypeled.github.io/react-logic/), so I removed the boilerplate to create a true reactive system.
If you want, you can create reactive system just from JS primitives, using callbacks. But that doesn’t make JS reactive by nature.
> you need to subscribe to changes manually (use effect) to create computations
How do you mean? Since the render function reruns during every update to state/props, derived/computed values can be calculated from the updated state/props during rendering.
When all you need is a synchronous operations, yes. When it involves async, batching, buffering, and user input, it becomes much more complicated, and every step needs to be setup manually.
Agreed, the OP said that the r in rxjs stands for reactivity, so my point was the the names have little bearing on the actual design patterns achieved with the libs
Honestly, this is my experience as well. LLMs make it easier to explore other domains, but they do not make you the master of one; you still need expert domain knowledge.
That said, they do make excellent tools to quickly try out new ideas and dive into them; they can even be great learning accelerators if you have a curious mind.
Yes, but the whole point of Wero is that you don't have to type in a bunch of info that can be easily stolen. With Wero (and many other international solutions), you just scan a code with your phone, and your banking app handles the transactions. The existing legacy solutions are just duct tape on an existing system.
If 3DS and chip + PIN card usage were ubiquitous, the value of a stolen card number and even card would be zero, and this entire problem would go away.
Unfortunately, legacy deployments have just proven too pervasive to effect real change, even with substantial incentives, especially in early card adopting markets such as the US.
The QR code just contains a URL to a website, so you can also just use that link and a web browser. That website will let you choose which bank you use, and then redirect to your bank's website which will use your bank account directly. I don't think it works with cards at all.
And authorize yourself with the banking app, and, and...
It's not less complicated than auto filling credit/debit card details with your finger print on your phone or laptop.
For consumers, Wero, Pix, and similar systems only have down sides for online use. The most important down side is that you can't reclaim your funds if you've been the victim of fraud. Which you can when paying by card.
Of course not, since you can just install the Android app on your free software aftermarket OS. Surely banks wouldn't require hardware attestation or monitor your device for being rooted, would they? /s
Irony aside, yeah, this is a significant downside compared to hardware-based standards. Not so much for Android, as Google Pay and most competitors are implemented in software, but on a hypothetical iPhone or Garmin device running an open OS (don't laugh, it's a thought experiment), payment data security would be not much of a concern since all payment keys live in a secure and completely separate chip.
If this system is ubiquitous stealing your card number would be useless. Your card number becomes a user name like jonkoops that you would have no qualms sharing.
Another day, another pre/postinstall script executed that could have easily have been prevented by any sane package manager. NPM really desperately needs an 'allowBuilds' style allowlist [1] and 'approve-builds' command [2].
After I upgraded pnpm to v11, I set all allowBuilds to false and have not observed any failures. Made me wonder why the packages even need build scripts. My guess is for obscure or old platforms, but for most users running on Linux or Darwin build scripts seem to be unnecessary.
Other times it was to avoid shipping binaries due to, erm, safety concerns. The package would include code in a different language, which in turn would compile into a binary library or executable.
If postinstall scripts are restricted the people behind these attacks will switch to something else. Package code is executed automatically by Node when imported, which could be a good replacement. It'll probably run when tests run instead but it's still going to run for most people.
Limiting post install as an attack vector is still a good thing.
Node is working on a similar permission model to Deno that allows explicitly granting certain system resource permissions https://nodejs.org/api/permissions.html. Using it should help reduce impact from malicious code, though if you allow wide permissions it's unlikely to help.
> Limiting post install as an attack vector is still a good thing.
If npm got rid of the post install scripts it would permanently break the install process of packages that use it. Affected systems will need to bypass it, stay on an old npm version, or upgrade the packages to versions that work without post install. Meanwhile, attackers switch to a different attack vector and continue.
I said limit post install, not remove them. Having an allow list in package.json of packages which can run post install would work fine. Pnpm already does this.
Having said that I'm not against full on removal of post install either. It would get more pushback, but would still be possible for people to manually run the post install for the few packages that require it, or to add them as a script in package.json.
Actually, those materials can be MUCH more radioactive in the beginning compared to 'conventional' nuclear waste, the half-life is just so short that you can let them sit for a couple of decades and then deal with it.
I sincerely hope Donut really has an ace up their sleeve, we could really use some domestic competition against China here in the EU. I sincerely hope that the next update from them is something solid (pun intended), and not 'what color is the battery'.
> We have libraries like SQLite, which is a single .c file that you drag into your project
You are just swapping a package manager with security by obscurity by copy pasting code into your project. It is arguably a much worse way of handling supply chain security, as now there is no way to audit your dependencies.
> If you get rid of transitive dependencies, you get rid of the need of a package manager
This argument makes no sense. Obviously reducing the amount of transitive dependencies is almost always a good thing, but it doesn't change the fundamental benefits of a package manager.
> There's so many C libraries like this
The language with the most fundamental and dangerous ways of handling memory, the language that is constantly in the news for numerous security problems even in massively popular libraries such as OpenSSL? Yes, definitely copy-paste that code in, surely nothing can go wrong.
> They also bindings for every language under the sun. Rust libraries are very rarely used outside of Rust
This is a WILD assumption, doing C-style bindings is actually quite common. YOu will of course then also be exposing a memory unsafe interface, as that is what you get with C.
What exactly is your argument here? It feels like what you are trying to say is that we should just stop doing JS and instead all make C programs that copy paste massive libraries because that is somhow 'high quality'.
This seems like a massively uninformed, one-sided and frankly ridiculous take.
> You are just swapping a package manager with security by obscurity by copy pasting code into your project
You should try writing code, and not relying on libraries for everything, it may change how you look at programming and actually ground your opinions in reality. I'm staring at company's vendor/ folder. It has ~15 libraries, all but one of which operate on trusted input (game assets).
> fundamental benefits of a package manager.
I literally told you why they don't matter if you write code in a sane way.
> doing C-style bindings is actually quite common
I know bindings for Rust libraries exist. Read the literal words you quoted. "Rust libraries are very rarely used outside of Rust". Got some counterexamples?
Gamedev is its own weird thing, and isn't a model you want to generalize to other industries. It has to optimize for things a lot of software does not, and that skews development.
Vendoring libraries is almost always a terrible idea because it immediately starts to bitrot and become a footgun.
Sometimes it's necessary, but it's not desirable, and you almost always just want to pin your dependencies instead.
reply