If this ships, it will change JavaScript forever
JavaScript is constantly evolving and improving, with new features and updates being released regularly. However, there is one potential change that has the potential to completely revolutionize the way JavaScript is used.
Imagine a world where JavaScript can ship new features independently of browser releases. This would mean that developers could start using new features as soon as they are available, without having to wait for browser updates to catch up.
Not only would this speed up the development process, but it would also allow for more experimentation and innovation in the world of JavaScript. Developers would be able to try out new features and see how they work in real-world scenarios much faster than they currently can.
Of course, there are still many hurdles to overcome before this dream becomes a reality. Browser compatibility issues, performance concerns, and security risks all need to be addressed before this new way of shipping JavaScript features can become mainstream.
But if this ships, it has the potential to change JavaScript forever. Developers would have more control and flexibility over their code, and the JavaScript ecosystem as a whole would become more dynamic and exciting.
Isn't that just what svelte does?
So, this sounds like OOP without objects…
Imagine the implicit mutations that's not trackable where you can mutate a signal in a different file and it triggers a bunch of changes in many others.
I don't see any difference with calling a function? : const isEven = () => (x % 2 == 0); beside optimisation on JS side ?
So events? ok… yes the observer pattern is good and has been good since Gang of Four (not the Maoist ones)
The thumbnail looks like a deer in the headlights
So…… Vue3? =)
Ok, understood, why not use functions? Why do I need the dependency on a "source" or want a "sink"?
What's wrong with using functions (even lambdas) for that?
I love signals. But. I don't honestly think something like this belongs in a language standard library, at all.
As the proposal itself says: wins in terms of file size and performance are going to be negligible – signal libraries are already small and bundling them isn't actually a problem, at all. So what problem does this proposal solve? The proposal doesn't say.
Libraries like these may need to change in scope and behavior – if you build it into the language standard library, you're creating another instance of the same problems we have with every standard library function and class: they either can't change, or changing them takes many years. That's a serious problem.
So you're making a serious practical/logistical tradeoff for… what?
But it's a stage-0 proposal, so they might still wake up and realize they're only creating more problems.
sounds like reactive value in Meteor
Really cool stuff.
I’ve worked in an environment where this type of acyclic graph dependency triggering behavior led to serious performance issues and unmaintainable spaghetti code where it’s so hard to debug due to having to figure out what triggered something when you’re 10 levels of indirection away from the trigger and a million sources to wade through.
Basically this is a spreadsheet. 😀
why dont you just how that works? 3:43 and of you can go up in hierarchy in react if you pass the components without creating a deathloop
I need some famous YouTuber to make a "Don't use Signals for these" video. I need devs to understand the new shiny thing is not for everything. I have seen people like vue refs so much they used it for every single variable in the whole codebase (imagine a temp variable inside for/while loops etc). I have also seen an Android app use LiveData (signals with lifecycle etc) for internal event delivery. Imagine a class with 200+ public static Signal State attributes (one per event type) instead of a proper event listener. Yes it's a skill issue but I have seen it way too many times.
its rxjs
I think signals can be replaced by ordinary semantics, such as this
let x' = 2 <- this is a signal initalization
let x = 3 <- this is a normal math operation
…Oh shit I reinvent Svelte with $:
Reinventing getters and setters
What browser is that?
Elm had signals too in 2015, then the community collectively got over it – sad to see history repeat in JavaScript