😂 That's probably the element I used the most back in like 2010...

​@@awesome-coding Ditto, so underrated haha!

@@orderandchaos_at_work Yep! You can fit so much content in there, AND IT MOVES! 🤯🤯🤯

Thank you!

Thank you!

Noted!

Working on a video on PWA. If all goes well, it'll be published next week.

@@awesome-coding Awesome! I mean the adjective not the name.

Yes I am :)

yet* Most of the things in this video have pretty good support these days.

Even popover seems like it's been available in Chrome for the last year. Just depends on the user base you need to build for, but there's a decent chance you can use pretty much all of this stuff. Dang I wish popovers were available the last time I had to build one, those things are such a PITA to get right including accessibility

+1

Noted!

+1

Hmm I'm not sure why people are mentioning memory overhead in this scenario. Are talking about the references to the type embeddings? I'm pretty sure that's highly optimised. When it comes to complexity, the same argument can be made about Inheritace. As I said, Inheritance is not bad, it just has very specific use-cases, and is not a good idea to always use it when code reusability is required.

😂😅

Great idea! I'll look into it - thanks!

😂

This is actually an interesting take.

I'm might be wrong but the main benefits on implementing signals on the runtime level is performance and making interoperability easier between frameworks.

@@ParanoicoBR not really because both solid and svelte 5 will use signal but are in no way interoperable because the abstractions are completely different

@@Lemmy4555 I'm not saying all frameworks will be interoperable, but it'll be EASIER for framework developers to interop between them because everybody should be using the same signal primitives

I think your main error is to underestimate just how much VM nerds will be able to optimize the CRAP out of this if it becomes an Internal feature. As for it becoming obsolete... maybe?? Looks pretty generally useful though, independent of any frameworks that may come up in the future. Automatic data dependency tracking is definitely not a bad thing to have. @Lemmy4555 I don't think anyone is saying Svelte and Solid will be usable in the same project compatibly... the main innovation would be that the user data logic can be written with the same unified signal paradigm, making switching and exploring different frameworks conceptually and technically easier. The exact point in time when effects get called might be a bit different, maybe the framework would add complexity with different change phases too, or something... but the concept of "function that eventually reruns automatically if its inputs change" should carry over really well.

GDScript signals are EXTREMELY different though. The proposal for JS is essentially a data slot that has functionality to let anyone who accesses it (in the right context) know when it changes (and does that automatically as a big depencency graph). GDScript signals are event emitters that you can and need to manually fire and subscribe to. Both are very useful, just make sure not to be confused when coming from another language.

1:48 that code is terrible. It’s going to be everywhere 😢

Ok so I get you don't like the signal paradigm, but the reality is that it's in every major web framework, and VERY widely used. It's also very powerful. And honestly I'm not completely sure what's even so bad about the example you highlighted (I'm actually asking and curious). I agree that I REALLY want Object.watch() or sth like that, and signals could maybe have been a library wrapper around that... but their big innovation isn't the ability for a data slot to report changes, it's the automatic subscription, memoization and dependency tracking. These two really don't try to solve the same problem, even though one might benefit from the other by making the syntax cleaner (maybe).

@@ilonachan Thanks for taking the time to comment and ask questions. I like that Signals has been a convenient paradigm for the DOM to automatically react to code without awkward plumbing of the past. But there are quite a few problems. The Signals syntax is heavy. The existing implementations are libraries. And they’ve merely proposed adding a standardised version of that library to JS. At the very least, a language expert should be employed to simplify the syntax. The syntax is like the “coloured function” problem. I’ll just use a Signal for some state management here. Now I need to compute this, memo that, effect something else. I’m forced to use a very specific pattern everywhere. It’s like a hammer. Nothing is just a variable or a function any more. It’s wrapped, and mocked, and hard to inspect and understand, and the call chain is indirect and hidden and usually harder to debug. It’s easy for things to not be rendered at the right time, or rendered more than they should, or less than they should, or infinitely rendering, or just odd rendering timing. I haven’t seen how they manage dependencies. Currently we have to remember to specify the dependencies, which isn’t accurate unless you have IDE help and a linter. Maybe this proposal does away with explicitly specifying deps? Object.watch() and Object.observe() are much better starting points for reactive software. We get to use the variable as is. Nothing is mocked or wrapped. So inspection of the variable is easy. Nothing is mocked or wrapped, so what you see is what you get. The functions assigned to observer the value changes are your own, there is no intermediary, so it’s easier to follow the call hierarchy. It would be relatively easy to create a Signal library on top of that, which memoises values and tracks dirty state. Obviously, I’m not a fan of Mock either. I’m currently trying to build a JS/HTML native rendering library inspired by HTMX, but with the look and feel of server-side rendered views like you see in ERB or Razor pages, which create Custom Elements, which are then glued together with the style of code you see in React with state and functions passed as props which the internals can then react to. You think I’d be jumping for joy at this proposal. But all I can see is the unnecessary complexity and bloat it brings. Signals don’t help me make my library code easier, or the code that devs will write using my library. Object.watch() and Object.observe() would definitely make the code footprint smaller and easier to understand, and lead to better easier ways for devs to use my library.

@@br3nto I don't think I can respond well to everything you said (and ofc I do still agree with Object.watch() and so on). The biggest point I'd agree with is probably "this could've been a library", since it has been for... a decade now? not sure how long it's actually been. Of course if this thing became an Internal it could be optimized way more, like Promises have, but still. I agree the syntax for accessing signals has always been clunky, mainly because you can't define a "slot" that reacts to things and pass that around, but instead have to wrap it in an object or sth. What I want is to have a signal holder variable s, and when I do `s = s+1` it automatically does the signal stuff... but that kinda muddles the two semantics of "the signal being a value represented by the variable name, but you can always reassign the variable" and "the variable name IS the signal, and when you assign to it the variable stays the same but the signal gets updated". I think an okay compromise would be to write `s = other_signal` for reassigning the signal itself, and `s() = s()+1` to say we explicitly care about the content of a signal... but that would require s() to return a *value* one can *assign to, * which is not a real thing (and I don't think can be emulated even with Proxies). Maybe it could be called a "slot" and used to unify some conceptual models... but at this point I'm inventing a new experimental language. It'd be really cool though. (for now one could use `s.val`, because getset is already a thing for object properties... but that's exactly what I mean by current signals just using wrapper objects.) One important thing you may not be aware of with signals, which is understandable if you come from React (where dependencies for memoization and effects have to be manually declared): this signal proposal doesn't need that. An Effect/Computed (the latter being the equivalent of useMemo, except as a composed signal itself) is a special context that keeps track of any signal getter as it is called, and (re)constructs the dependency array automatically on first execution. That works perfectly if the function is deterministic, because sure on each execution you only cover one code path... but the only scenario where you would have taken another one is when one of the signal inputs changed, and you're detecting that. It stops working perfectly if your effect is impure (as it almost always will be by design) or if your Computed uses non-signal variables from the outside (which it probably shouldn't, or you just have to live with an untracked variable's changes not being tracked, maybe that's intentional), so there should probably be a way to manually specify dependencies... but that could be a single `forceTrack(sig1,sig2,...)` call first thing in the function (which can still be far more fine-grained, because you can put this at the beginning of a nondeterministic if-branch instead and it can be ignored if that branch isn't used). So yeah, the automatic dependency tracking absolutely just works, with only slight caveats. It's extremely useful tho, and I don't feel it's very confusing either: Signals are the data which can be changed by the user, Computeds are memoized processed computation results on those signal values, and if you want a block of arbitrary code to be rerun whenever one of the signals it uses changes, that's an effect(). And outside of some edge cases, you don't really need to worry about anything. You can still set breakpoints in effects, use one to subscribe to changes and use that to debug when a signal changes too often, etc. The good thing is that this proposal is still very much in the early stages, so if you are actually seeing a hugely prohibitive issue with this, maybe you can bring it up in the discussion! Maybe they've already been brought up and addressed, or maybe they become inspiration for better syntax. It does seem inevitable that signals WILL come, but if you have an idea to make them better, that'd help everyone.

I feel like static type checking probably goes a little bit beyond "linting"

I understand your take. Thanks for mentioning it - I'll keep it in mind moving forward.

@@awesome-coding Thank you so much for the understanding, keep up the good work man ♥

@@awesome-coding FWIW I didn't really find the God reference offensive. Subscribed for the quality content and polished editing.

@@avtargill Thank you!