Recently, there's been a buzz about a proposal to introduce Signals to JavaScript. But before diving in, what exactly is a signal?
In simple terms, a Signal is like a data cell that can change over time. It can either hold a static value (what we call "state") or compute its value based on other Signals ("computed").
Now, why would anyone want to add Signals to JavaScript? The big idea is that it could make sharing UI logic across different frameworks much easier. Imagine having a single source of truth for your application state, accessible no matter which framework you're using. Sounds pretty neat, right?
But here's the catch: Signals alone won't cut it. To really harness their power, you'd need an effect system. And guess what? That's not part of the proposal. So, if Signals become a thing in JavaScript, you'd still need to rely on libraries or frameworks to handle effects.
And that's where things could get messy. Let's say you build your app using Signals with Framework X. All's well until you need to switch to Framework Y for some reason. But what if Framework Y decides not to support Signals? Suddenly, you're stuck rewriting your logic from scratch.
Okay, you decide going forward you will not use any framework that doesn't use the standard signals API. But how do you find out? You have to scan the entire codebase to find out. Compared to if it were a standard library, you can just check the package.json to see if it has the standard library installed.
Sure, you could argue, "Just use a library that provides an effect system." But what if we flipped the script? What if Signals were left to userland, and frameworks could build on top of a standard Signal library? That way, switching frameworks wouldn't be such a headache.
Moreover, if Signals become part of JavaScript itself, they will rely on polluting the global scope
In my opinion, Signals are powerful, but they should stay in userland. Take s-js, for example. It's been my go-to for handling state for a while now, and it does the job just fine.
I'm not aware of any web API that's exclusive to library and framework authors. Web standards shouldn't bend over backward for frameworks, no matter how popular they are. Let's keep JavaScript clean and focused on what it does best, without cluttering it with unnecessary bells and whistles.
Top comments (1)
Are you familiar with the Observer design pattern and the event emitter in JavaScript?
dev.to/amrelmohamady/why-and-how-t...
There’s an NPM module which adds this for browser support as well. It supports encapsulated events and doesn’t pollute global namespace. I’ve used it before, but I mostly find promise chains more suited to the tasks I have.