Microsoft, Igalia i Bloomberg Ogłosili to kilka dni temu podjęli inicjatywę włączenia składni dla jawnej definicji typu w specyfikacji JavaScript, podobny do składni używanej w języku TypeScript.
Obecnie prototypowe zmiany proponowane do włączenia do standardu ECMAScript zostały przekazane do wstępnych dyskusji (Etap 0).
Dzisiaj mamy przyjemność ogłosić nasze wsparcie i współpracę nad nową propozycją etapu 0, aby wprowadzić opcjonalną i usuwalną składnię typów do JavaScript. Ponieważ ta nowa składnia nie zmieniłaby sposobu wykonywania otaczającego kodu, skutecznie działałaby jako komentarze. Uważamy, że może to sprawić, że TypeScript będzie łatwiejszy i szybszy w programowaniu na każdą skalę. Chcielibyśmy porozmawiać o tym, dlaczego to robimy i jak ta propozycja działa na wysokim szczeblu.
Wspomniano, że w tPosiadanie wyraźnych informacji o typie zapobiegnie wielu błędom w procesie programowania, zapewni możliwość zastosowania dodatkowych technik optymalizacyjnych, uprości debugowanie i sprawi, że kod będzie bardziej czytelny i łatwiejszy do modyfikowania i utrzymywania przez zewnętrznych programistów.
poza tym Proponuje się zaimplementować obsługę typów jako opcjonalną funkcję: Silniki JavaScript i środowiska uruchomieniowe, które nie obsługują sprawdzania typu, będą ignorować adnotacje z informacjami o typie i przetwarzać kod tak jak poprzednio, postrzegając dane typu jako komentarze. Ale narzędzia do sprawdzania typów będą w stanie, na podstawie dostępnych informacji, wykrywać błędy związane z nieprawidłowym użyciem czcionek.
Tło
Ostatnim trendem, który nasz zespół zauważył w świecie JavaScript, jest zapotrzebowanie na krótszy czas iteracji i skrócenie etapów kompilacji. Innymi słowy, „uczyń to szybszym i prostszym”.W pewnym sensie to już się dzieje. Dzięki sukcesowi przeglądarek evergreen programiści często unikają kompilowania nowszych wersji JavaScript do działania w starszych środowiskach wykonawczych. Do pewnego stopnia to samo dotyczy sprzedaży pakietowej: większość przeglądarek ma wbudowaną obsługę korzystania z modułów, więc sprzedaż pakietowa może być postrzegana bardziej jako krok optymalizacyjny niż konieczność. Dzieje się tak coraz częściej, więc jak wytrzymuje TypeScript?
W tym samym czasie w przeciwieństwie do określonych informacji o typie poprzez adnotacje JSDoc określone w formie komentarzy, bezpośrednia specyfikacja typów bezpośrednio w konstrukcjach definicji zmiennych sprawi, że kod będzie bardziej wizualny, zrozumiały i łatwiejszy do edycji.
Na przykład środowiska IDE obsługujące TypeScript będą mogły natychmiast wyróżniać błędy w napisanym kodzie JavaScript bez dodatkowych przekształceń. Ponadto wbudowana obsługa typów umożliwi uruchamianie programów napisanych w dialektach JavaScript, takich jak TypeScript i Flow, bez transpilacji z jednego języka na inny.
Z typów proponuje się dodanie "string", "number" i "boolean", które mogą być użyte przy definiowaniu zmiennych, parametrów funkcji, elementów obiektowych, pól klas, typowanych tablic ("number[]"). Proponuje się również obsługę typów łączonych („string | number”) i typów ogólnych.
Biorąc to wszystko pod uwagę, planujemy przedstawić tę propozycję dla Etapu 1 na następnym posiedzeniu plenarnym TC2022 w marcu 39 roku. Zrobimy to przy wsparciu i wskazówkach naszych współtwórców tej propozycji, Roba Palmera z Bloomberga i Romulo Cintry z Igalii.
Osiągnięcie Etapu 1 oznaczałoby, że komitet normalizacyjny uważa, że składnia kompatybilnych typów dla ECMAScript jest warta rozważenia. To nie jest pewne: w komisji jest wiele cennych punktów widzenia i spodziewamy się pewnej dozy sceptycyzmu. Taka propozycja spotka się z wieloma komentarzami i odpowiednią analizą. Może to wymagać wielu zmian projektowych po drodze, a uzyskanie wyników może zająć lata.
na następnym spotkaniu z Marca komisji TC39 planowane jest przejście do pierwszego etapu rozpatrzenie wniosku z udziałem społeczności ekspertów ECMA.
W końcu Jeśli chcesz dowiedzieć się więcej na ten temat, możesz sprawdzić szczegóły w następujący link.