Spojrzenie na przyszłość JavaScript

Na każdym rynku rządzą pewne wspólne koncepcje, a rozwój JavaScript nie jest wyjątkiem.

Cykl życia produktu to koncepcja, którą można zastosować w kilku różnych środowiskach, aby zrozumieć i przewidzieć ich zachowanie. Jest to koncepcja biznesowa, która pomaga nam zrozumieć etapy, przez które przechodzi produkt w trakcie swojego życia, wyjaśniając wpływ tych etapów na jego miarę popularności — w większości przypadków sprzedaż. Obserwując wzorce zachowań rynkowych, możemy oszacować aktualny stan produktu, a tym samym dokonać pewnych prognoz dotyczących jego popularności.

Istnieją cztery etapy: wprowadzenie, wzrost, dojrzałość i spadek, a na powyższym wykresie możesz zobaczyć wpływ na oczekiwaną sprzedaż produktów dla każdego etapu. Na przykład sprzedaż smartfonów nie rośnie tak, jak pięć lat temu – w rzeczywistości jest wręcz odwrotnie – więc możemy śmiało powiedzieć, że smartfony wchodzą w fazę dojrzałości.

W ciągu ostatnich kilku lat widzieliśmy wprowadzenie wielu nowych technologii w JavaScript, ale potrzebowaliśmy czasu, aby zobaczyć, jak rynek je przyjmie. Nikt nie chce być specjalistą od kolejnej obiecującej technologii, która kończy się zerową adopcją. Teraz jednak nadszedł czas, aby spojrzeć jeszcze raz. W tym artykule przyjrzę się, jak popularny staje się JavaScript i jakie czynniki mogły wpłynąć na tę popularność, a także spróbuję przewidzieć, jak będzie wyglądała przyszłość JavaScript.

Przyszłość funkcji języka JavaScript

Odkąd Europejskie Stowarzyszenie Producentów Komputerów (ECMA) ustanowiło roczny cykl wydawania ECMAScript, standardowej specyfikacji JavaScript, nie widzieliśmy wielu nowych funkcji pojawiających się w języku — tylko kilka każdego roku. To może być jeden z powodów, dla których zauważyliśmy wzrost popularności języków, które kompilują się do ES5, takich jak TypeScript lub ReasonML, które wnoszą do języka funkcje, które są bardzo pożądane przez społeczność. Nie jest to nic nowego — JavaScript przeszedł już przez ten proces (CoffeeScript) i ostatecznie te funkcje zostały włączone do samego standardu językowego i prawdopodobnie jest to przyszłość, której możemy się spodziewać również w przypadku tych nowych funkcji pisanych.

Ale teraz zaczynamy dostrzegać zmiany w grach na rynku kompilacji do js wraz z rosnącą dostępnością WebAssembly w przeglądarkach. Teraz możemy używać prawie każdego języka i skompilować go, aby działał z prawie natywną prędkością w przeglądarce, a co ważniejsze, zaczynamy dostrzegać wsparcie dla przyszłych funkcji, takich jak obsługa wątków, które pozwolą nam korzystać z wielu - architektura procesora, która reprezentuje nieuniknioną przyszłość wszystkich urządzeń.

Oficjalny łańcuch narzędzi dla WebAssembly pomoże Ci skompilować C/C++, ale istnieje wiele kompilatorów udostępnionych przez społeczność dla różnych języków, takich jak Rust, Python, Java i Blazor (C#).

W szczególności społeczność Rusta jest dość aktywna i zaczęliśmy widzieć kompletne front-endowe frameworki, takie jak Yew i Dodrio.

Daje to wiele nowych możliwości aplikacjom opartym na przeglądarce i wystarczy przetestować niektóre z doskonałych aplikacji zbudowanych za pomocą WebAssembly, aby przekonać się, że prawie natywne aplikacje oparte na przeglądarce są teraz rzeczywistością, np. Sketchup lub Magnum.

Przyjęcie języków maszynowych, które kompilują się do ES5, jest wystarczająco dojrzałe, gracze są dobrze ugruntowani i nie znikną (ani nie zostaną połączone z ES) w najbliższej przyszłości, ale zobaczymy powolną zmianę na korzyść języków maszynowych z WebAssembly.

Sieć

Frameworki front-end

Każdego roku widzimy wielką walkę na rynku front-endowych frameworków dla sieci, a React jest niekwestionowanym zwycięzcą przez ostatnie kilka lat – od czasu wprowadzenia ich technologii zmieniania gier, Virtual DOM, widzieliśmy prawie obowiązkowe przyjęcie od ich odpowiedników, aby zachować aktualność w bitwie.

Kilka lat temu widzieliśmy wprowadzenie radykalnie nowego podejścia do tworzenia aplikacji internetowych za pomocą Svelte, „szkieletu kompilatora”, który znika w czasie kompilacji, pozostawiając mały i wysoce wydajny kod JavaScript. Jednak ta funkcja nie wystarczyła, aby przekonać społeczność do przejścia na Svelte, ale wraz z niedawną premierą Svelte 3.0 wprowadzili do frameworka prawdziwe programowanie reaktywne, a społeczność jest zachwycona, więc być może jesteśmy świadkami kolejnej wielkiej rzeczy z przodu -końcowe ramy.

Zainspirowany operatorem przeznaczenia:

 var a = 10; var b <= a + 1; a = 20; Assert.AreEqual(21, b);

Svelte wprowadza reaktywność do JavaScriptu, przeciążając użycie instrukcji etykiet reaktywnością w czasie kompilacji, instruując kod, który ma być wykonywany w kolejności topologicznej:

 var a = 10; $: b = a + 1; a = 20; Assert.AreEqual(21, b);

Jest to radykalnie nowy pomysł, który może pomóc w różnych kontekstach, więc twórca Svelte pracuje również nad svelte-gl, frameworkiem kompilacyjnym, który będzie generował niskopoziomowe instrukcje WebGL bezpośrednio z grafu sceny 3D zadeklarowanej w HTMLx.

Nie trzeba dodawać, że React, Angular i Vue.js nie znikną z dnia na dzień, ich społeczności są ogromne i pozostaną istotne przez kilka lat — nie jesteśmy nawet pewni, czy Svelte będzie faktycznym następcą, ale my możesz być czegoś pewien: prędzej czy później użyjemy czegoś innego.

WebXR i przyszłość wciągającej sieci

Rzeczywistość wirtualna walczyła przez ostatnie 60 lat o znalezienie miejsca w głównym nurcie, ale technologia nie była jeszcze gotowa. Niespełna dziesięć lat temu, kiedy Jon Carmack dołączył do Oculus VR (obecnie część Facebook Technologies, LLC), zaczęła rosnąć nowa fala VR i od tego czasu widzieliśmy wiele nowych urządzeń obsługujących różne typy VR i oczywiście rozprzestrzenianie się aplikacji obsługujących VR.

Producenci przeglądarek nie chcieli stracić tej szansy, więc dołączyli do specyfikacji WebVR pozwalającej na tworzenie wirtualnych światów w JavaScript z WebGL i dobrze ugruntowanymi bibliotekami, takimi jak three.js. Jednak udział w rynku użytkowników z urządzeniami o rozdzielczości 6 stopni nadal był nieznaczny w przypadku masowych wdrożeń internetowych, ale sieć mobilna nadal była w stanie zapewnić wrażenia 3D z interfejsem API orientacji urządzenia, więc zobaczyliśmy kilka eksperymentów i wiele filmów 360 dla chwila.

W 2017 roku, wraz z wprowadzeniem ARKit i ARCore, nowe możliwości zostały wprowadzone do urządzeń mobilnych i wszelkiego rodzaju aplikacji z doświadczeniem AR i MR.

Jednak nadal wydaje się trochę nienaturalne, aby pobrać jedną konkretną aplikację dla jednego konkretnego doświadczenia AR podczas odkrywania otaczającego Cię świata. Gdybyśmy mogli mieć tylko jedną aplikację do odkrywania różnych doświadczeń… Brzmi to znajomo. W przeszłości rozwiązaliśmy ten problem za pomocą przeglądarki, więc dlaczego nie spróbować jeszcze raz?

W zeszłym roku Mozilla wprowadziła specyfikację WebXR Device API Spec (której ostatnia robocza wersja robocza, w momencie pisania tego tekstu, pochodzi sprzed dwóch tygodni), aby wprowadzić do przeglądarki możliwości AR, VR i MR (ergo XR).

Kilku najważniejszych dostawców przeglądarek podążyło za ich wdrożeniem, z ważnym wyjątkiem: Safari mobile, więc aby udowodnić swoją rację, Mozilla wydała przeglądarkę obsługującą WebXR pod platformą iOS WebXR Viewer.

Teraz jest to ważny krok, ponieważ połączenie AR i VR wprowadza 6dof do urządzeń mobilnych i zestawów słuchawkowych opartych na urządzeniach mobilnych, takich jak Google Cardboard lub Samsung Gear VR, jak widać na tym przykładzie, zwiększając udział w rynku urządzeń 6dof o dużą marżę i dającą możliwość wdrożenia webowego na dużą skalę.

W tym samym czasie chłopaki z Mozilli pracowali nad nowym frameworkiem internetowym ułatwiającym tworzenie światów 3D i aplikacji o nazwie A-Frame, deklaratywnym frameworkiem opartym na komponentach ze składnią HTML opartą na three.js i WebGL, mając tylko pamiętaj o jednej rzeczy — aby przywrócić zabawę i łatwość użytkowania w programowaniu internetowym.

Jest to część ich krucjaty do immersyjnej sieci, nowego zestawu pomysłów na to, jak sieć powinna wyglądać w przyszłości. Na szczęście dla nas nie są sami i zaczniemy widzieć coraz bardziej wciągające doświadczenia w sieci.

Jeśli chcesz spróbować, pobierz przeglądarkę WebXR Viewer i odwiedź tę stronę, aby zobaczyć możliwości wciągającej sieci.

Po raz kolejny standardowe aplikacje oparte na przeglądarce nie znikną za rok lub dwa — prawdopodobnie zawsze będziemy je mieć. Jednak aplikacje 3D i doświadczenia XR rosną, a rynek jest gotowy i chętny do ich posiadania.

Natywne wsparcie dla ES6

Prawie każda technologia wynaleziona w JavaScript w ostatniej dekadzie została stworzona w celu rozwiązania problemów generowanych przez podstawową implementację przeglądarek, ale sama platforma bardzo dojrzała w ciągu ostatnich kilku lat i większość z tych problemów zniknęła, jak widać z Lodash, który kiedyś królował w testach wydajności.

To samo dzieje się z DOM-em, którego problemy były kiedyś faktyczną inspiracją do tworzenia frameworków aplikacji webowych. Teraz jest to dojrzały interfejs API, którego można używać bez frameworków do tworzenia aplikacji — w rzeczywistości to właśnie są komponenty internetowe. Są „szkieletem” platformy do tworzenia aplikacji opartych na komponentach.

Kolejną interesującą częścią ewolucji platformy jest sam język. Używamy Babel.js od kilku lat, aby móc korzystać z najnowszych funkcji ECMAScript, ale ponieważ sam standard zaczął nieco stagnować w ciągu ostatnich kilku lat, był to wystarczający czas, aby umożliwić dostawcom przeglądarek zaimplementować większość ich funkcji, w tym natywną obsługę statycznej instrukcji importu. Teraz możemy zacząć rozważać tworzenie aplikacji bez Babel.js lub innych kompilatorów, ponieważ (ponownie) obsługujemy funkcje językowe na samej platformie, a Node.js używa tej samej maszyny wirtualnej V8, co Google Chrome , zaczęliśmy dostrzegać silniejsze wsparcie dla ES6 w Node.js, nawet z instrukcją static import pod flagą expert-modules.

Nie oznacza to, że przestaniemy oglądać aplikacje kompilowane na profesjonalnym poziomie, ale oznacza to, że rozpoczęcie od aplikacji opartej na przeglądarce będzie łatwe i przyjemne, jak kiedyś.

JavaScript po stronie serwera

Chociaż JavaScript zaczął działać po stronie serwera w 1995 roku wraz z Netscape Enterprise Server, dopiero podczas prezentacji Ryana Dahla w 2009 roku JavaScript zaczął być poważnie rozważany w przypadku aplikacji po stronie serwera. Wiele rzeczy wydarzyło się w ciągu ostatniej dekady z Node.js. Bardzo ewoluowała i dojrzała, ponownie stwarzając okazję do przełomów i nowych technologii.

W tym przypadku pochodzi z ręki własnego twórcy, Ryana Dahla, który pracował nad nową perspektywą aplikacji zabezpieczonych po stronie serwera za pomocą Deno, platformy, która natywnie obsługuje najnowsze funkcje językowe, takie jak async/await, oraz także najpopularniejszy język TypeScript kompilujący do js, ​​ukierunkowany na najlepszą wydajność dzięki ich implementacji w Rust i użyciu Tokio, ale co ważniejsze z nową filozofią bezpieczeństwa, która odróżnia go od większości platform serwerowych, takich jak Python, Ruby lub Java). Zainspirowany modelem bezpieczeństwa przeglądarki, Deno pozwoli ci korzystać z zasobów hosta tylko po tym, jak użytkownik jawnie przyznał uprawnienia do procesu, co na początku może wydawać się nieco nudne, ale może mieć wiele implikacji, zezwalając nam do uruchamiania niezabezpieczonego kodu w bezpiecznym środowisku, po prostu ufając platformie.

Node.js nadal będzie dostępny w przyszłości, ale być może zaczniemy widzieć usługi bezserwerowe, takie jak AWS Lambda i Azure Functions, aby zapewnić funkcjonalność Deno jako alternatywę dla niezabezpieczonego wykonywania kodu po stronie serwera w ich systemach.

Wniosek

To ekscytujące czasy w świecie JavaScript — wiele technologii dojrzało na tyle, by pozostawić przestrzeń dla innowacji, aktywna społeczność nigdy nie przestała nas zadziwiać swoimi genialnymi i niesamowitymi pomysłami i oczekujemy wielu nowych alternatyw dla ugruntowanych narzędzi ponieważ ich dojrzałe etapy przychodzą szybko; nie przestaniemy ich używać, ponieważ wiele z nich jest naprawdę dobrych, a na polu bitwy jest mnóstwo dowodów, ale zaczną się pojawiać nowe i ekscytujące rynki, na które lepiej się przygotuj.

Bycie na bieżąco z najnowszym światem JavaScript nie jest łatwe ze względu na tempo rozwoju, ale istnieją pewne źródła, które mogą naprawdę pomóc. Po pierwsze, moim zdaniem najważniejszym źródłem wiadomości jest Echo JS, gdzie co godzinę można znaleźć niesamowitą ilość nowych treści. Jeśli jednak nie masz czasu, newsletter JavaScript Weekly jest doskonałym podsumowaniem tygodnia w JS. Poza tym ważne jest również, aby mieć oko na konferencje na całym świecie, a kanały YouTube, takie jak JSConf, React Conf i Google Chrome Developers, są niezwykle pomocne.

I odwrotnie, jeśli jesteś zainteresowany konstruktywną krytyką kierunku, do którego zmierza JavaScript, polecam przeczytanie Jako programista JS, To jest to, co mnie trzyma w nocy autorstwa kolegi programisty JavaScript, Justena Robertsona.

Dalsza lektura na blogu Toptal Engineering:

• TypeScript vs. JavaScript: Twój przewodnik podstawowy