151–160 of 336 posts
Off topic, but I’m wondering if anyone attracted to this topic could help me understand why JavaScript doesn’t have macros. I’m aware of much conversation around dismissing macros, often in the context of bad dev experience — but this sounds like a shallow dismissal to me. At the end of the day, we have some of the results of macros in the JavaScript ecosystem, but rather than being supported by the language they are…
Is dependency tracking problem statically solvable (without calling effect once and subscribing to all .get's)? I don't think this needs to be a language feature, rather abstraction of existing features. In other words, can't this be a library? I know that SolidJS is able to figure out dependent signals, but probably doing so on the first execution.
> In other words, can't this be a library? You answered your own question: > I know that SolidJS is able to It already is, obviously. But how is SolidJS supposed to work with other non-SolidJS code? It can't. Unless every library builds support for every other library, they can't possibly interoperate.
E.g. in Rust it's much more common to rely on existing "building blocks" like futures, tokio, syn, serde even just for basic bindings, favoring interoperability.
Am I the only one that thinks the vanilla js example is actually easier to read and work with? - "The setup is noise and boilerplate heavy." Actually the signals example looks just as noisy and boilerplate heavy to me. And it introduces new boilerplate concepts which are hard for beginners to understand. - "If the counter changes but parity does not (e.g. counter goes from 2 to 4), then we do unnecessary computation…
https://preactjs.com/guide/v10/signals
"In Preact, when a signal is passed down through a tree as props or context, we're only passing around references to the signal. The signal can be updated without re-rendering any components, since components see the signal and not its value. This lets us skip all of the expensive rendering work and jump immediately to any components in the tree that actually access the signal's .value property."
"Signals have a second important characteristic, which is that they track when their value is accessed and when it is updated. In Preact, accessing a signal's .value property from within a component automatically re-renders the component when that signal's value changes."
I think it makes a lot more sense in a context like that.
When I need to signal something across my application, I use events: window.dispatchEvent(new Event('counterChange')); And every part of the application that wants to react to it can subscribe via window.addEventListener('counterChange', () => { ... do something ... }); Anything wrong with that?
Historically, this example is the reason why the Web evolved into jQuery and from there forked into the world of Angular and React mainly. Event handling is getting messy very easily. If you want to get deeper into it, have a look at event bubbling and propagation. Large applications need a robust event handling. This is the nowadays hidden benefit of frameworks like Angular, Vue etc. Believe me, you don’t want to us…
In this example, the event is on the Window. There is no bubbling. It is already at the top level.
>Believe me, you don’t want to use the standard event handling API without a framework. Adding, deleting, cloning, firing, removing, fire once etc on many elements can have serious unwanted side effects.
I don't know what this means. The frameworks do not have much to do with this topic.
When I need to signal something across my application, I use events: window.dispatchEvent(new Event('counterChange')); And every part of the application that wants to react to it can subscribe via window.addEventListener('counterChange', () => { ... do something ... }); Anything wrong with that?
> Anything wrong with that? It only works in browser environments.
See, for instance, https://www.electronjs.org/docs/latest/api/ipc-renderer
Am I the only one that thinks the vanilla js example is actually easier to read and work with? - "The setup is noise and boilerplate heavy." Actually the signals example looks just as noisy and boilerplate heavy to me. And it introduces new boilerplate concepts which are hard for beginners to understand. - "If the counter changes but parity does not (e.g. counter goes from 2 to 4), then we do unnecessary computation…
I agree. But look at Preact's signal documentation - https://preactjs.com/guide/v10/signals "In Preact, when a signal is passed down through a tree as props or context, we're only passing around references to the signal. The signal can be updated without re-rendering any components, since components see the signal and not its value. This lets us skip all of the expensive rendering work and jump immediately to any com…
I have found that passing props makes React-like applications very complex and messy and props are to be avoided as must as practical.
The mechanism for avoiding props is Custom events.
It concerns me to see the concept of signals being passed as props when surely signals/events should be removing the need for props?
Earlier quoted context omitted.
What kind of side effects specifically?
I believe memory leaks to start
For other event listeners, they get removed when the DOM element is removed.
The frameworks do not solve this to any greater degree. They also just make everything invisible and behind-the-scenes and hard to debug due to their declarative nature, but that is another topic.
Earlier quoted context omitted.
Mostly the teardown logic and inevitable memory leaks. A alt proposal would be some kind of auto remove listener if it goes out of context
The new `using` feature handles RAII just fine. This proposal is entirely unnecessary given the existence of `using` and the already-existing event listeners. https://iliazeus.github.io/articles/js-explicit-resource-man...
Earlier quoted context omitted.
Why do you think this is premature memoization? This is an example, boiled down to a simple function. Do you think people just came up with the use case for this without ever having needed it? I think an effort in standardizing signals, a concept that is increasingly used in UI development is a laudable effort. I don't want to get into the nitty gritty about what is too much boilerplate and whether you should build a…
> I don't want to get into the nitty gritty about what is too much boilerplate and whether you should build an event system or not You're basically saying you want this thing, but you don't want to have to justify it
Earlier quoted context omitted.
Historically, this example is the reason why the Web evolved into jQuery and from there forked into the world of Angular and React mainly. Event handling is getting messy very easily. If you want to get deeper into it, have a look at event bubbling and propagation. Large applications need a robust event handling. This is the nowadays hidden benefit of frameworks like Angular, Vue etc. Believe me, you don’t want to us…
>If you want to get deeper into it, have a look at event bubbling and propagation. In this example, the event is on the Window. There is no bubbling. It is already at the top level. >Believe me, you don’t want to use the standard event handling API without a framework. Adding, deleting, cloning, firing, removing, fire once etc on many elements can have serious unwanted side effects. I don't know what this means. The…
Frameworks batch changes so that updates are efficient, and in many cases figures out the "correct" order of doing things. If you do all of those yourself in a large and complex UI, very likely you are updating the DOM less efficiently than what frameworks are doing, and very likely you introduced some subtle bugs. Speaking of that from my first-hand experience.