This Could Change Web Dev Forever

A new TC39 proposal for native Signals in JavaScript. What does this mean?
💬 Topics:
- What are Signals?
- What is reactivity?
- Signals code example;
- Signals vs composed signals vs effects.
📖 Blog Article - www.awesome.club/blog/2024/ja...
🥇 Become a Member - / @awesome-coding
✉️ Join the Newsletter - newsletter.awesome.club/

[@Fallingstar-yy5iv]

TS as a linter, "Search your feelings, you *know* it to be true."

[@ilonachan]

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

[@tauiin]

I mean if typescript is a linter then pretty much every statically typed language that dosent have types at runtime (which is most of them) just has a "type linter" by that definition lol. its mostly semantics anyways tbh, imo there isnt really much of a difference between a type checker and a linter at the end of the day: a type checker checks your types and your linter checks for common anti-patterns/logic bugs etc

[@eduardoalvarez4457]

Amazing! We will finally have reactivity out of the box!

[@awesome-coding]

Can't wait!

[@poulticegeist]

Reactivity already exists though event handlers

[@antonpieper]

1:29 I don't know why I didn't think of binding document.querySelector to document before. Feels a bit like jQuery

[@awesome-coding]

Yep! It looks more natural like that, right?

[@honkhonkv2236]

I literally exploded seeing that, mind blown 😂

[@harshilparmar9076]

If someone one ask me how global scope pollution can be good. I will show this example. 😍

[@tauiin]

I do something similar but I name it $qs, e.g. I have const $qs = document.querySelector.bind(document); const $qsA = document.querySelectorAll.bind(document); const $id = document.getElementById

[@cyberprompt]

@@tauiin I have something similar, but just found out about bind. not sure if it matters. I cover pretty any kind of selection types, plus a create element. /** UTILITY SELECTOR FUNCTIONS (implicit return) **/ const OQS = (obj, s) => obj.querySelector(s); const OQA = (obj, s) => obj.querySelectorAll(s); const DQS = (s) => document.querySelector(s); const DQA = (s) => document.querySelectorAll(s); const EID = (s) => document.getElementById(s); const DCE = (el) => document.createElement(el);

[@zainuldin9095]

Yes! Please do video on queueMicrotask and JS under the hood topics

[@awesome-coding]

Will do!

[@mohitkumar-jv2bx]

Yes please

[@andyl.5998]

Lydia Hallie on youtube actually has a couple of really good videos on these topics.

[@tawsifhaque9360]

what is the font used in the code snapshots?

[@WLockIV]

I know it might not be your style of content, but it would be insanely useful to have a tutorial of some kind that walks viewers through how to build their own signals system in JavaScript. At the beginning of my career, I gained so much productivity working with REST APIs after making one of my own. I wonder if the same would happen after building my own signals. Maybe I should be sending this to Traversy lol.

[@dkazmer2]

If I never have to learn [another] framework, this will be gold, Jerry, gold!!

[@SinergiasHolisticas]

Love it!!!!!!!!!!! Want Much More!!!!!!!!!!!!!!!!!

[@tithos]

Please further explain the queueMicrotask

[@ahsanabrar880]

I'm interested please make more videos, thanks

[@awesome-coding]

Will do! Thanks!

[@nomoredarts8918]

JavaScript will have proper monads now

[@DEVDerr]

It's just a proposal. It doesn't mean that will be featured in the language itself

[@rawallon]

To be fair you were just a proposal at one point

[@UnderCtrl]

@@rawallonbruh 😭😭

[@Leonhart_93]

Yes, but none of that matters as you can use Signals any time you want. It's a small open source library ATM.

[@yahm0n]

Adding it to the language simply gives it the pope's blessing. The concept itself was already being done in many different ways in different projects/libraries, but by settling on an official way of doing it, you can expect convergence, allowing people who work on many different projects to just have to learn one way of doing it in the future, and libraries will be able to confidently use signals in their public API with all of their usefulness.

[@kkebo]

@@rawallon unexpected

[@SiCrip09]

I thought Signals is used in classnames in tailwind

[@br3nto]

Arg. It’s a library at best. They haven’t even bothered to create an elegant and simple language syntax for it. Object.watch() and Object.observe() was a million times better proposal with much more powerful and useful functionality which a signals library could have been built on top of. It’s a thoughtless proposal. If this proposal is implemented, JS libraries and frameworks are going to become so bloated and polluted with Signal style code.

[@br3nto]

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

[@ilonachan]

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).

[@br3nto]

@@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.

[@ilonachan]

@@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.

[@cariyaputta]

Nice, now JavaScript can inch a bit closer to GDScript.

[@ilonachan]

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.

[@codescype]

Your presentation is creative 👏🏾. My best part was the "in the beginning God created"😆.

[@Rtzoor]

very interested in JS internals deep dives

[@awesome-coding]

Noted!

[@silvantonio]

it remembers Meteorjs Tracker

[@awesome-coding]

Meteor JS! 😅. I had such high hopes for "isomorphic JS" 🫠

[@silvantonio]

@@awesome-coding I really miss how easy it was to decide an stack back then 🙃

[@awesome-coding]

@@silvantonio I still believe that the best stack is the stack you know best.

[@lhard123l]

As python dev we are talking for years that signals are antipattern

[@awesome-coding]

Why is that?

[@botondvasvari5758]

20years from now maybe it becomes good

[@sayedulkrm]

Wow

[@Lemmy4555]

It's unlikely that will be implemented because there's no benefit in implenting them in the VM when you can do it effectively in JS. We'll still need frameworks to have nice component syntax and this won't change even if they do implement signals in the VM. Tomorrow another smart guy will came up with an even better way to handle components and template, and even signals will look like old crap.

[@awesome-coding]

This is actually an interesting take.

[@ParanoicoBR]

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

[@Lemmy4555]

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

[@ParanoicoBR]

@@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

[@ilonachan]

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.

[@justafreak15able]

Title should e Javascript will get better!

[@awesome-coding]

Fair enough!

[@ilonachan]

It's a little bit justified because the polyfill already exists and is taken seriously, but yeah

[@naranyala_dev]

vanilla, vanilla, vanilla

[@z0nx]

This is harder than haskell lenses and monad transformers... Good lord help me

[@awesome-coding]

😂

[@omri9325]

Title is misleading :/

[@awesome-coding]

I'm open to suggestions :) Keep in mind that I also have to play the YT game like it or not...

[@omri9325]

@@awesome-coding It's a fine art to get the thumbnail and title right with a touch of click bait without lying.

[@awesome-coding]

@@omri9325 don't I know it? 😅

[@omri9325]

@@awesome-coding I hope you do, this one turned out over that border IMHO.

[@trenwar]

​@@omri9325i think this one is fine

[@joaobarreto5180]

#ThePrimeTime

[@zsmain]

I loved your videos, and you are doing great job, but the last video and this I stopped right on the God jokes, I understand the use for hyperbole for the comedic effect but we can make jokes without involving God, I hope you'll understand, and thank you for your videos man.

[@awesome-coding]

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

[@zsmain]

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

[@avtargill]

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

[@awesome-coding]

@@avtargill Thank you!

[@n8ged8]

It's never god that complains about (harmless) jokes. It's the guys who are (very) sure that a god exists. They get upset because they believe unprovable things (like god) to be true, take themselvers too serious and are not tolerant enough to let others joke and laugh. say it aint so!

[@StingSting844]

There is no point in complaining about the framework hell because they all are effects of being on a platform. No one complains about so many programming languages because they don't see the OS as a platform even though it is. There will never be a single great framework just like there will never be a single great car that we all drive

[@pokefreak2112]

Different programming languages are made to solve different problems. Javascript frameworks are all attempting to solve the same problem: making webdev scalable while keeping the end product somewhat performant

[@StingSting844]

@@pokefreak2112 no there is no one single problem. And all languages are created for a variety of reasons. Why exactly are multiple frameworks an issue for you?

[@pokefreak2112]

@@StingSting844 None of the frameworks are actually good, and none of them have actually solved the problem. If they were good they wouldn't change every couple years. I thought svelte was heading in the right direction with their compiler, but now they completely walked it back and became an entirely different framework with svelte 5

[@keith-is-mad]

@@pokefreak2112 The same thing can be said about languages - none of them are actually good (yet). That's the nature of iterative chaos driven development that we humans are exercising at this point in history. The web is just more visually chaosy in that way due to demand. It also progresses much faster than other tech due to that chaos.

[@pokefreak2112]

@@keith-is-mad I agree that no programming language is particularly good, but there is very much progress being made towards something better. In web land people are too obsessed with js and the dom to solve problems from first principles. Reactivity is not even a real problem if your UI can re-render in realtime (very realistic on modern machines). So if you wanted to do some real software engineering you would write this realtime renderer first and then attempt to get it working on the web, pushing for updates to the standard when running into roadblocks. I've done some of this kind of work and you'll quickly realize that browsers are just missing a lot of API's you'd need to write good software. Because of this, from my perspective all userspace innovation will be half-baked. Either you innovate at compile time (by making a compiler), join the W3C and push for the missing API's to be implemented, or just give up on web and do your own thing natively

[@Peacemaker.404]

okay, next you'll say the Earth isn't flat?

[@awesome-coding]

Wait... the Earth isn't flat?!

[@shineymcshine]

I'm just not good at learning from videos like these. It goes in one ear and out the other.

[@awesome-coding]

Why is that? I'm really curious to understand the pain points of your experience.

[@dawidgrden2227]

@@awesome-coding the functions you presentend are quite abstract, it would be nicer to see a simple code and functionality example of such snippet with each line explained, for example what is computed in queueMicrotask ? How does the signal API work exactly ? Is computed global singleton function that actually renders at clock, what if the queue of tasks is too long. In framworks you call async for certain components because you know a certain request is blocking but you video doesn't mention blocking cases

[@awesome-coding]

@@dawidgrden2227 Thank you for your feedback! You are definitely right!

[@viniciusmachadorodrigues1724]

The magic about signal is all about Jsx and rerendering dependecies. Signals in the browder doesnt do this.

[@awesome-coding]

I agree, but it is a first step towards that.

[@edhahaz]

It's not impossible, they just need to bake react into the browser. What a crazy ideeea.... that should've happened 10years ago

[@nomadshiba]

that's not react

[@awesome-coding]

Not sure if React is the best option here though.

[@axMf3qTI]

Someone please send this men to a ward. His thinking is broken.

[@adambickford8720]

Tell me you're a jr dev w/o telling me...

[@ilonachan]

I originally also thought about React, but honestly? I think it doesn't even use REMOTELY the same signal concept. It might end up being one of the only frameworks that won't even have any use for this proposal! Simply because of its whole pure "rerun entire component on change" paradigm being fundamentally different from the kinda-event-listener-like approach of Signal effects... maybe they can be made compatible, maybe React changes course entirely, who knows what the future brings.

[@TheRealLeccho]

here an unpopular opinion: rxjs is better

[@omri9325]

And for a good reason

[@awesome-coding]

I'm not convinced, but I'm open to hear your arguments :)

[@moveonvillain1080]

Rxjs is a necessary evil... Evil non the less.... That shit is hard to wrap your head around

[@adambickford8720]

@@awesome-coding It does everything signals do, async. Its a superset of functionality but there's steeper learning curve most ui devs can't grok.

[@TheRealLeccho]

@@awesome-coding Well they do mostly the same thing, but RxJs can handle async. While using signal might be easier, you will still find that you need to use RxJs. RxJs can do anything signal can. So why learn both librairies when you only need one?

[@gabrielluca8392]

Awful

[@awesome-coding]

😂😅

[@TheOnlyJura]

no, it didnt

[@mulualemtekle6094]

cheap clickbait lie