Sygnały, że JS rozwija się w tempie żółwia

Wbrew pozorom ekosystem JavaScriptu wyjątkowo powoli się rozwija. Pamiętacie, jak tworzyłem "alternatywę dla Reduxa"? W zasadzie kilka takich projektów miałem, a to chciałem zrobić alternatywę dla Reduxa, a to dodatek do Reduxa. A to całkowicie niezależną bibliotekę do reaktywności, nawet edytor wizualny zrobiłem, gdzie dało się połączyć boksy strzałkami, żeby zaznaczyć flow danych (tzw. node editor - trochę jak edytor shaderów w Blender czy edytor blueprintów w Unreal Engine). Na potrzeby tego wizualnego edytora zrobiłem bibliotekę do reaktywnych grafów. Inspirowałem się też takimi bibliotekami jak Mobx czy Rx.js.

I cóż, robiłem to gdzieś między 2017 a 2019. Od tego czasu trochę się znudziłem tematem, plus uznałem, że w zasadzie problem "zarządzania stanem" jest już rozwiązany w środowisku JSowców lepiej lub gorzej i że może zbyt się zafiksowałem w ambicjach i rozwiązania małego problemu, a zatraciłem szerszy kontekst tworzenia oprogramowania. Słuchajcie, bo te całe zarządzenie stanem/reaktywność to jest w zasadzie mały problem, który frontendowcy nadmuchują, żeby móc tworzyć kolejne biblioteki open source i gadać kolejne wystąpienia na konferencjach o tym samym.

Od jakiegoś czasu jednak dochodzą mnie głosy, że ekosystem frontendowy dalej nie rozwiązał tego problemu. Np. jakiś czas temu słyszałem, że w Angularze się cieszą, że odkryli "sygnały". Trochę mnie to śmieszyło, bo w ekosystemie Reacta od dawna ludzie korzystają z podobnych rozwiązań. Np. sygnały w Mobx były od dawna, tylko się inaczej nazywały. Plus w przypadku Angulara to dodatkowo śmieszy, że przecież tam już korzystają z reaktywnej libki Rx.js. Więc po co sygnały dodatkowo?

Słyszałem też, że jakiś framework Solid robią, który jest o to oparty. W sumie wtedy sam zacząłem kombinować z własnym frameworkiem w podobnym stylu https://github.com/hex13/nacht. Ale coś tam porobiłem, uzyskałem satysfakcję, że umiem robić frameworki i dałem sobie spokój. Aha, jeszcze próbowałem zrobić reaktywny język kompilowany do JSa, ale też sobie dałem spokój,

Jednak ostatnio zobaczyłem coś absurdalnego. Kolejne dyskusje na temat sygnałów oraz propozycje, żeby dodać sygnały do JSa: https://github.com/tc39/proposal-signals. To już sprawiło, że zacząłem kminić "o co tu w ogóle chodzi? To dalej jest nierozwiązany problem reaktywności na froncie?".

Ale o ile samo dodanie reaktywnych prymitywów do JSa może być krokiem w dobrym kierunku, to mam parę zastrzeżeń.

1. Co z innymi reaktywnymi prymitywami, które już są albo mają być? Mamy już w JS rzeczy, które są reaktywne:
   • natywne eventy (EventTarget)
   • promisy, async/await - to też może posłużyć do stworzenia reaktywności! Tyle, że jednorazowej, co raczej pcha w kierunku bardziej imperatywnego kodu w stylu pull i tworzenia jakichś reaktywnych pętli
   • asynchroniczne generatory - które mogą być alternatywą dla obserwabli
   • mamy proposal Observable

   I teraz, zastanawiam się, czy te "sygnały", będą kompatybilne ze wcześniejszymi rzeczami, czy będzie to XKCD 927 (Standards). W końcu takie async/await jak weszło, to wpasowało się w istniejący klocek pod tytułem "promisy" i dlatego to takie fajne jest. Jeśli będą po prostu sygnały niezależne od niczego, to trochę bez celu (ale spojrzałem tylko pobieżnie na tę speckę, więc poddaję to pod wątpliwość, ale nie znam na tyle tej specki, żeby stwierdzić, że takiej kompatybilności tam nie ma).

2. Przykład w README tego proposala jest trochę bez sensu, bo pokazuje, jak można zaciemnić kod sygnałami.
3. Wszedłem w źródło polyfilla i napaćkane tam kodem bez sensu. Ludzie, to nie jest aż tak trudne, nie wiem, co wy robicie, ale robicie to prawdopodobnie źle. To wygląda na jakieś przeinżynierowanie.
4. Mam wątpliwości, co do computed, zbyt magiczne to jest i przypuszczalnie musiałoby korzystać z globalnego stanu.
5. Pytanie - po co to ma być w ogóle częścią języka? Zanim to przeglądarki zaczną implementować, to minie z kilka lat. Owszem, można używać polyfilla, ale po co, w czym taki polyfill jest lepszy od biblioteki?

Mając pod uwagę te wątpliwości, postanowiłem coś samemu zadziałać w tym temacie i zacząłem robić własną bibliotekę do reaktywności Ampel

Założenia:

• będzie można robić reaktywne prymitywy/pojemniki na wartość (teraz są nazwane State, ale pewnie zmienię nazwę na Signal, skoro teraz taka jest modna)
• pojemniki będą miały operacje odczytu i zapisu, jak również możliwość subskrypcji (wielorazowej lub jednorazowej, jak również możliwość wycofania subskrypcji), teraz są to metody .get(), .set(), .on(), .off(), .once(), ale może się to zmienić.
• pojemniki będą kompatybilne z promisami, będzie można je awaitować (zaimplementowałem metodę .then)
• będzie to kompatybilne (albo wprost albo przez jakiś wrapper) z istniejącymi bibliotekami. W tej chwili robię wrapper do Reacta. Ale myślę o też o innych bibliotekach.
• będą operatory np. .map, .filter czy kilka innych (nie za dużo, bo nie chcę zrobić z tego Rx.js, który ma napaćkane tyle operatorów, że i tak nikt tego nie używa)
• być może będzie jakaś integracja z asynchronicznymi generatorami/iteratorami, które również są wygodne przy tworzeniu reaktywności w JS
• będzie wizualny inspektor, który będzie pokazywał te sygnały tak, żeby było to widoczne, można będzie zobaczyć, co jest zależne od czego
• będę przypuszczalnie robił jeszcze inny projekt, który będzie z tej biblioteki korzystał. Być może będzie to framework do JSa (alternatywa dla Reacta), może własny język kompilowany do JSa, może jeszcze co innego)
• będzie dokumentacja i przykłady

Więc cóż, możecie zobaczyć postępy tutaj: Ampel.js. Nie wiem, czy moja biblioteka stanie się jakimś standardem, ale chcę przynajmniej pokazać ludziom, jak to może być zrobione. Skoro się męczą przez całe lata.