Node.js mnie zaskoczył

Niby znam Node.js, ale ciągle się czegoś nowego dowiaduję.

I tak niedawno dowiedziałem się, że:

1. Node.js ma wątki. A nie miał przecież. Zawsze się mówiło, że jest jednowątkowy. Jakoś w tamtym roku jednak na jednej z rozmów rekrutacyjnych padło pytanie "czy Node.js jest jednowątkowy?". Powiedziałem, co wiedziałem, że "nie". Patrząc na reakcję osób rekruterskich* już widziałem, że coś chlapnąłem. Dopytywali się "na pewno? Czyli nie ma wątków?". I nie wiem, czy cieszyli się w duchu, że sam się wkopałem, czy może chcieli mi dać wskazówkę, żebym się wycofał z tej opinii? (niczym na egzaminie ustnym profesor pyta się studenta próbując go naprowadzić na właściwy kierunek).

   Ale później "wracając do domu" (w sensie zamykając kartę z rekrutacją w przeglądarce, bo na tym polega teraz "wracanie do domu z rekrutacji"), poczytałem sobie o tym i okazało się, że już od jakiegoś czasu Node.js owszem ma wątki. Patrzcie sami, to dowód: https://nodejs.org/api/worker_threads.html.

   Tylko piszą, że to do operacji zżerających czas procesora(CPU-intensive) i że jak masz operacje, które opierają się mocno na wejściu/wyjściu (I/O-intensive), to lepiej olać wątki i użyć normalnego asynchronicznego (jednowątkowego) kodu, bo to będzie bardziej efektywne.

   Czyli jak rozumiem - jeśli masz zrobić jakieś przeliczenia, to sobie odpal wątek. Ale jeśli chcesz zczytać np. tysiące plików, to niepotrzebne ci wątki, a wystarczy asynchroniczny Node.js, taki jak zwykle.

2. Node.js ma wbudowany test runner. Czyli nie potrzebujesz instalować czegoś w Node.js, żeby mieć testy. To, że ma asserty to już dawno wiedziałem, ale teraz się dowiedziałem, że ma takie coś do definiowania testów (czyli test(), describe(), it()...)

   Tylko, że to eksperymentalne API - https://nodejs.org/dist/latest-v19.x/docs/api/test.html. Więc nie wiem, czy można używać. Ja zacząłem taki projekt i właśnie tego używam, ale chyba zmienię na Mocha, jeśli piszą, że to eksperymentalne. No i ten output jest bardzo surowy, a w Mocha raportowanie tych błędów jakieś ładniejsze jest. Jeszcze jest Jest, ale Jest mi jakoś zamula zawsze, a Mocha się szybciej odpala.

3. Node.js ma wbudowany interpreter WebAssembly. Pytanie - po co? Przecież wydawać by się mogło, że to niepotrzebne, skoro Node.js może odpalać natywne apki bezpośrednio. A jednak! Użycie Wasm ma tę zaletę, że jest to taki sandbox i można pilnować, co ten kod robi, czy nie ma zbyt wielkich uprawnień. Trochę jak kontenery. Nawet twórca Dockera kiedyś powiedział, że, gdyby Wasm i Wasi istniało wcześniej, to w ogóle by nie robił tego Dockera

   Mogę sobie wyobrazić również apkę, która ma system wtyczek opartych na Wasm. Wtedy taka wtyczka jest pod kontrolą i nie narobi niczego niedobrego. A jednocześnie taka wtyczka może być napisana w dowolnym języku, który kompiluje się do WebAssembly. Bo często programy mają swoje zopiniowane języki do robienia wtyczek (np. że musisz pisać w Pythonie, JS, Lua itp.). A tutaj byłyby wtyczki binarne w bajtkodzie.

   Poza tym te apki, co już są w Wasm, możesz se tak odpalić. Bez przeglądarki. Widzę w tym potencjał do testowania modułów Wasm. Pytanie, na którym etapie, do jakich testów? Pisząc swój projekt w Rust (kompilowany do WebAssembly), zacząłem go testować w Rust. Później napiszę jeszcze testy do kodu JS oraz sprawdzające, czy kod JS współpracuje prawidłowo z kodem WebAssembly. Może na tym etapie się to przyda? Jako pewnego rodzaju coś do testów integracyjnych JS<-->Wasm? Rzecz do zbadania i przemyślenia.

*osoba rekruterska - mam na myśli programistów, który prowadzili rekrutację. To nie byli rekruterzy z zawodu, tylko pełnili taką przygodną rolę tylko. Czyli idąc za modą, że każdego teraz się nazywać połączeniem "osoba + przydawka", nazwę ich osobami rekruterskimi.