WSTECZ
Powszechnie wiadomo, że nowoczesne aplikacje internetowe są z dnia na dzień coraz częściej wykorzystywane. Rozwój jest naprawdę szybki i pozwala na publikowanie aplikacji na wszystkich platformach, gdzie jedynym wymaganiem jest posiadanie środowiska obsługującego dany stos technologiczny. Językiem, który można nazwać królem wszystkich innych w tym środowisku jest JavaScript. Dzisiaj podzielę się z wami kilkoma faktami na temat rozwoju oprogramowania związanego z tym językiem.
Wyrażenie "szybki rozwój" może być interpretowane na wiele niewłaściwych sposobów. Aby tego uniknąć, wyjaśnijmy, jakie są nasze oczekiwania. Cóż, najważniejszą rzeczą jest budżet. Aby zbudować wiele wersji tej samej aplikacji, potrzebujemy wielu programistów z kilku stosów technologicznych i płacimy każdemu z nich. Aby zbudować natywne aplikacje mobilne, musimy zduplikować nasze kod działać dobrze na obu platformach - Android i iOS. Powszechnym podejściem jest utrzymywanie obu aplikacji podobnych, używanie tego samego API, utrzymywanie tego samego zachowania i tak dalej. W rezultacie musimy zduplikować kod, aby zbudować dwie wersje tej samej aplikacji. JS to język, który pozwala nam budować jednocześnie aplikacje mobilne i webowe. Brzmi niemożliwie? Pozwól, że wyjaśnię o czym mówię.
Załóżmy, że chcemy zbudować aplikację korzystającą z biblioteki React. Biblioteka ta może być używana do tworzenia aplikacji internetowych i mobilnych z natywnym React. Logiczne mechanizmy aplikacji, takie jak autoryzacja, obliczanie, filtrowanie danych i tak dalej, można wykonać za pomocą haków React. Chodzi o to, że te haki mogą być współdzielone przez obie wersje aplikacji - webową i mobilną. Dzięki tej opcji mamy następujące oszczędności:
Podsumowując ten akapit - nie chodzi o to, że jedna baza kodu będzie zasilać wszystkie wersje aplikacji, choć możemy podzielić współdzielony kod i wykorzystać go w każdej z nich, aby naprawdę przyspieszyć proces rozwoju.
Wniosek - jeśli chcesz zbudować aplikację webową i mobilną w tym samym czasie, rozważ bibliotekę React, która może współdzielić bazę kodu w mobilnej i webowej wersji aplikacji.
Jeszcze kilka lat temu, mówiąc o backendzie, prawdopodobnie niewiele osób wyobrażało sobie, że jego utrzymanie może być możliwe przy pomocy języka takiego jak JS. Rozwój tego języka jest niesamowity, a jego owoce można zbierać do dziś.
O czym mówię? Jeśli zatrudnisz właściwego Deweloperzy JSOkazuje się, że mogą one pisać nie tylko frontend aplikacji, ale również backend - czyli odpowiadać za przetwarzanie danych na serwerze, komunikację z bazą danych, różnego rodzaju integracje itp. Wciąż się wahasz lub nie jesteś przekonany do tego języka? Nie ma powodu, by mieć takie nastawienie! Backend z wykorzystaniem JS można zaimplementować na dwa popularne sposoby - w trybie rozszerzalnym i konfigurowalnym, który zapewnia nam express.js, oraz w trybie ustrukturyzowanym z wykorzystaniem wzorca DI - nest.js.
Oba rozwiązania są niezwykle popularne i zasilają wiele aplikacji produkcyjnych, których właściciele są "gigantami technologicznymi" w swojej branży. Myślę, że dojrzały one na tyle, by przekonać do wyboru jednego z nich.
Wciąż za mało? Podobnie jak w przypadku współdzielenia kodu pomiędzy aplikacjami webowymi i mobilnymi, backend może współdzielić zasoby zarówno z tymi pierwszymi, jak i drugimi. Kluczowym słowem jest tutaj TypeScript - pozwala on między innymi na współdzielenie bazy kodu, czyli wspólnej definicji typów danych dla wszystkich platform.
Z aplikacjami zbudowanymi wyłącznie na JavaScript / TypeScript stosując monolith, oszczędzamy wiele linii kodu, które musielibyśmy powielać w natywnych językach programowania. Z drugiej strony, używając tego samego języka na wszystkich frontach, możemy współdzielić ogromną ilość logiki między wszystkimi aplikacjami, co zdecydowanie przyspieszyłoby czas, w którym dana aplikacja może zostać zbudowana. Czy to nie brzmi świetnie?
Okazuje się, że technologie budowania aplikacji przeglądarkowych świetnie nadają się do utrzymywania tych aplikacji, z których korzystamy w ich desktopowej formie - dobrym przykładem może być tutaj Slack. Slack to aplikacja służąca do zespół komunikację - poza standardowym przesyłaniem wiadomości, posiada wiele różnych funkcjonalności i różnego rodzaju zewnętrznych integracji. Wszystko to sprawia, że jest to jedna z najpopularniejszych aplikacji wykorzystywanych głównie w branży IT.
Jak się okazuje, Slack również wykorzystuje technologie webowe (a więc i JavaScript) do budowy interfejsu swojej aplikacji. Podstawą, która umożliwia uruchamianie takich aplikacji na pulpicie jest elektron. Tworzenie interfejsów graficznych z wykorzystaniem technologii webowych sprawia, że tworzenie aplikacji na różne platformy w tym samym czasie jest znacznie łatwiejsze, szybsze i ogólnie możliwe.
Opowiadając o frontendowej części aplikacji, nie ma złudzeń, że JS jest jedynym i wyłącznym językiem, który zasila ekosystem tutaj. Na chwilę obecną nie ma realnych alternatyw, które mogłyby zastąpić tę część aplikacji (choć myślę, że WebAssembly może nas zaskoczyć w przyszłości). Mówiąc więc o dojrzałości JS na frontendzie - nie ma wątpliwości, że jest on jedynym królewskim.
Mówiąc o backendzie, wielu programistów może wydawać się zszokowanych lub natychmiast zaprzeczyć, że JS nadaje się jako język programowania na zapleczu. Sprawę należy jednak przeanalizować obiektywnie.
Wielu dostawców usług w chmurze udostępnia pakiety SDK, które umożliwiają bezpośrednie korzystanie z chmura metody. Co dziwne, jedną z najpopularniejszych zakładek, tuż obok C#, Go i Javajest Node.js. Okazuje się, że platforma ta jest idealna do skalowania i budowania aplikacji opartych na architekturze mikroserwisów lub serverless. Wniosek - JS jest jednym z najpopularniejszych języków do tworzenia aplikacji opartych na architekturze mikroserwisów/serverless. Na poniższych screenach widzimy, że święta trójca (Google Computing Services, AWS, Azure) dostawców chmury pozwala nam na budowanie aplikacji z wykorzystaniem węzeł.js.
Jeśli chodzi o ekosystem node.js, to chyba każdy zna bibliotekę o nazwie express.js - jest to proste i nieskomplikowane narzędzie, które pozwala na definiowanie ścieżek, a następnie podawanie im odpowiednich danych, które zostały odpowiednio przetworzone po stronie JS. Co więcej, wzorzec wykorzystywany wśród żądań HTTP obsługiwanych w express.js stał się jednym z najpopularniejszych w całym ekosystemie i jest swego rodzaju wzorcem dla różnych innych bibliotek wykorzystujących np. architekturę serverless.
Podsumowanie - JS jest językiem na tyle dojrzałym, że można w nim postawić wszystkie karty i zbudować zarówno frontend, jak i backend. Ponadto jest to dość świeży język, który z łatwością odnajduje się w nowoczesnych architekturach aplikacji. To wspaniałe, że programista znający jeden język może opanować obie strony (pełny stos) aplikacji.
Cóż, najczęściej używanym silnikiem do wykonywania kodu JS jest v8, oparty na języku C++. Ten silnik opracowany przez Google jest przeznaczony do uruchamiania aplikacji na platformy internetowe. Ciekawostką jest to, że silnik ten nie interpretuje kodu JS. Zamiast tego robi coś, co nazywa się "JIT" - "just in time compilation". Dzięki temu nie musimy interpretować kodu JS linijka po linijce, tylko go kompilujemy i wykonujemy. Jest to jeszcze szybsze i daje nam naprawdę niezłe wyniki wydajności.
Czy JS jest wystarczająco uczciwy w kwestii wydajności? Tak, jest. Tak długo, jak algorytmy są wystarczająco uczciwe, nie ma problemu z używaniem JS po stronie serwera. Inną rzeczą jest utrzymanie asynchroniczności kodu. Dzięki tym praktykom kod może obsługiwać równoległe żądania bez żadnych problemów. Nie musisz przejmować się zamianą technologii ze względu na wydajność - zwłaszcza gdy architektura aplikacji jest skalowalna.
Wydajność i testy porównawcze omówiłem już szczegółowo w tym artykule.
Cóż, są to dziesiątki opinii, że język JS zachowuje się dziwnie w niektórych przypadkach, a jego obsługa jest czymś, co sprawi, że głowa eksploduje podczas procesu programowania. Nie mogę się z tym zgodzić 🙂 Tak jak każdy inny język, ma kilka wzorców/zachowań, które nie są eleganckie, ale przy zrozumieniu jak działają i jakie są ich cele tworzenie aplikacji z JS nie jest nieprzyjemne.
Zwłaszcza uwaga "asynchroniczny" tuż przed JS wywołuje dreszcze u niektórych programistów. Trudno to zrozumieć, gdy nie ma się z tym żadnego doświadczenia. Jest to jednak część JS, która pozwala nam budować nowoczesne rozwiązania w łatwy sposób. Przyjrzyjmy się websocketom: ponieważ są one oparte na zdarzeniach - każda z połączonych jednostek - użytkownik i serwer mogą emitować i odbierać zdarzenia równolegle. Jeśli kod zasilający aplikację jest wystarczająco asynchroniczny i nie blokuje głównego wątku, możemy z łatwością obsłużyć tysiące żądań w krótkim czasie.
Porównajmy JS i PHP w kontekście websocketów. PHP jest synchronicznym językiem programowania, więc rozwiązywanie tematów związanych z websocketami przyprawia o ogromny ból głowy. Widzimy, że PHP czerpie wzorce z JS do budowania interaktywnych aplikacji backendowych, które mogą wykorzystywać nowoczesne technologie, takie jak webrtc czy websockets.
Zbierając wszystkie akapity razem, możemy stwierdzić kilka faktów:
JavaScript to język, który może być używany do tworzenia wszelkiego rodzaju aplikacji - od internetowych, przez mobilne, po desktopowe;
Aplikacje napisane w JS mogą współdzielić ze sobą różne fragmenty kodu, takie jak te odpowiedzialne za formatowanie danych lub typy w Typescript;
Dzięki rozwojowi sieci, wydajność oferowana przez JS jest wystarczająco dobra, aby zdecydować się zarówno na tworzenie aplikacji frontendowych, jak i backendowych;
Dzięki swojej nietypowej konstrukcji, JavaScript jest w stanie obsługiwać nowoczesne infrastruktury aplikacji, takie jak websockets i WebRTC;
Zatrudniając odpowiednio wykwalifikowanego programistę, jesteś w stanie wykorzystać jego potencjał na każdym dostępnym frontendzie, który obsługuje ten język;
JS to język, który od kilku lat pnie się w rankingach popularności i nic nie wskazuje na to, by miało się to w jakikolwiek sposób zmienić.
Wyrażając moją, co prawda nieobiektywną, opinię - skorzystanie z opcji JavaScript polegającej na ponownym wykorzystaniu tego samego kodu na wszystkich dostępnych frontach jest czymś, co z pewnością przyspieszy rozwój aplikacji i zmniejszy liczbę programistów zaangażowanych w utrzymanie backendu aplikacji napisanych w innych technologiach. Jako potwierdzenie niech posłuży fakt, że ogromna liczba tak zwanych gigantów IT podąża za tym wzorcem i dzieli się sporą ilością kodu na różnych platformach. Pomimo różnych opinii na temat tego języka, należy wziąć pod uwagę fakt, że statystyki użycia i zadowolenia z użytkowania JS rośnie z roku na rok, a jego programiści mogą łatwo podłączyć się do trendu pełnego stosu.
Czytaj więcej:
Dlaczego (prawdopodobnie) powinieneś używać Typescript
Polish 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
French 
Arabic 
Italian 
Japanese 
Korean