Języki, których się nauczyłem lub nie...

W ciągu ponad 20 lat pracy jako profesjonalny programista, nauczyłem się wielu języków i narzędzi. Oczywiście, istnieje wiele innych języków i narzędzi, których unikałem celowo, albo których nigdy nie miałem okazji się nauczyć. Mam jakieś żale? Tak, kilka....

Muszę to przyznać. Czekałem zbyt długo, by przyjrzeć się Reactowi i Angularowi. Kiedy wreszcie dotarłem do celu i dowiedziałem się, o co w nich chodzi, dosłownie wszyscy inni już je znali, a ja byłem z tyłu.

Dla faceta, który zawsze robił wszystko, aby nadążać za wszystkim, co nowe, nie tracąc przy tym czasu na ślepe zaułki, był to swego rodzaju szok.

To było po prostu zły timing. W miarę jak wielka transformacja w dziedzinie rozwoju webowego front-endu nabierała rozpędu, tak się złożyło, że pracowałem nad zespołem, który budował usługi back-end. W Expressie? Nie, nie w Expressie. W Django lub Flask. Nie, bez pythona. Więc ASP.NET? Nie, nie to, ani Go, ani nawet Java lub PHP. Nie będę wnikał w to, jak do tego doszło, ale skończyłem budując usługi SOAP przy użyciu IBM Integration Bus (wcześniej znanej jako Message Broker). I robiłem to jako product owner!

Cofnijmy się trochę: ASP.NET MVC i Razor

Przynajmniej nie byłem całkowicie zaskoczony. Dawno temu w czasach Web 1.0, zacząłem już robić tyle logiki prezentacji w JavaScripcie ile mogłem, na serwerze robiąc logikę biznesową i persystencję. Nie wymyśliłem JAMStacka, ale przecież nikt inny też nie wymyślił. W rzeczywistości, moje pierwsze spotkanie z Angularem - tuż przed wędrówką do dżungli oprogramowania pośredniczącego IBM - to była praca z wczesną (i doskonałą!) wersją Kendo UI. W pewnym momencie dodali wsparcie dla Angulara, więc przyjrzałem się temu i pomyślałem: "Och, to ciekawe, powinienem się więcej o tym nauczyć". Ale wtedy tego nie zrobiłem i to był mój błąd.

W tamtych czasach byłem pod wrażeniem, przynajmniej na początku, silnika szablonów Razor w ASP.NET MVC. Byłem zadowolony z budowania strony kontenera jako szablonu po stronie serwera, a następnie używania jQuery do wciągnięcia dodatkowych fragmentów HTML z serwera. W porównaniu z Angular and React (i Vue), było to brutalne. Ale w porównaniu do formularzy ASP.NET WebForms, czystym JavaScript, XmlHttpRequest i ASHX, było całkiem nieźle.

A ja muszę dać Microsoftowi uznanie za to, że w końcu zaimplementowali przyzwoity system MVC z ASP.NET MVC. Dotarcie tam zajęło im dużo czasu, ale gdy w końcu się udało, ich narzędzia były najwyższej klasy.

Ostatecznie wszystko nabrało sensu: .NET Core

Choć chwale Microsoft za to za co trzeba - to muszę też powiedzieć, że .NET Core wyewoluował w coś zupełnie innego niż się spodziewałem. To znaczy, może byłem trochę głupi, ale po prostu nie zrozumiałem o co chodzi z .NET Core, dopóki wszystko to się nie urzeczywistniło.

Przez lwią część mojej kariery, naprzemiennie opierałem się i bez tego akceptowałem niestrudzone wysiłki Microsoftu, by zamknąć mnie w systemie Windows. Dlaczego ci sami ludzie mieliby teraz aktywnie zachęcać mnie, bym nie przejmował się tym, czy używam Windowsa, Maca czy Linuksa? To po prostu nie miało sensu.

Powinienem też przyznać, że nie rozumiałem sensu Azure. Ale potem wszystko się jakoś ułożyło. Po prostu, Microsoft może zarobić dużo więcej pieniędzy poprzez nakłonienie programistów do kochania Azure niż poprzez robienie wszystkiego by nie nienawidzili tworzenia aplikacji webowych na Windowsie.. Więc obecnie ASP.NET jest wieloplatformowy i jest całkiem niezły jako REST-owy backend, i nadal całkiem przyzwoity do prezentowania treści wygenerowanej przez serwer, jeśli lubisz Razor. Staram się mieć oko na Blazor i WebAssembly, ale po przygodach z Silverlightem - wiem, że to nie to samo, ale jakoś podobnie brzmi - jestem trochę sceptyczny.

JQuery: Niedoceniony bohater

Historia Web developmentu to misternie spleciona tkanina narzędzi, technik i paradygmatów, z których każdy ma swoje własne, niepowtarzalne życie. Niektóre z nich to malutkie nitki, które przyszły i poszły i ledwie zdążyły zabłysnąć. Niektóre, takie jak Java i JavaScript, zmieniły całkowicie kierunek rozwoju stron internetowych, tak jak wtedy, gdy zabraknie jednego koloru przędzy w połowie drogi przez dzierganie szalika i trzeba kontynuować z innym kolorem. Inne po prostu posunęły piłkę do przodu, ale w tak wpływowy sposób, że nawet wtedy, gdy ich czas przeminął, ich spuścizna przetrwała.

Był czas, nie tak dawno temu, kiedy odpowiedź na praktycznie każde pytanie o to, jak coś zrobić w JavaScript brzmiała "użyj jQuery!". Poważnie, spójrz na to meta-pytanie na StackOverflow. Pozycja jQuery była tak mocna.

W pewnym sensie, jest mi smutno, że jQuery nie cieszy się szacunkiem, na jaki zasługuje. Jasne, dla nowoczesnych prac front-endowych, React, Angular, i Vue zapewniają dużo więcej struktury. Dodaj do tego TypeScript i masz poziom weryfikowalności i poprawności, którego nigdy nie uzyskałbyś w jQuery.

Ale spójrz na JQuery w kategoriach tego, co zastąpiło. Pojawił się wcześnie w renesansie z ciemnych wieków IE6. Firefox, Chrome, Opera i, w mniejszym stopniu, Safari, stopniowo tworzyły świat znaczących standardów internetowych, ale nie było to jeszcze możliwe. Babci nie obchodziło, co się stało, gdy kliknęła na niebieskie "e", o ile tylko mogła dostać się na swoją stronę na Facebooku. IT korporacyjne uznało, że aktualizacja do IE7 stanowi ogromne ryzyko, nie wspominając już o Chrome czy innych. jQuery umożliwił nawet programistom tworzenie wspaniałych, elastycznych, angażujących aplikacji internetowych przy znacznie mniejszym wysiłku niż wcześniej. Wypełniło to kluczową potrzebę i uczyniło to z naciskiem na przemyślany, wybiegający w przyszłość projekt.

Nie będę budował nowych aplikacji z jQuery jako główną biblioteką UI. Ale jeśli kiedykolwiek istniało muzeum rozwoju sieci (może istnieje?), jQuery powinno mieć swoje własne skrzydło.

Czemu to wszystko takie MERN-e?

Mówiąc o rzeczach, które mnie trochę zasmucają, chciałbym, żeby MERN było prawdziwym słowem.

Od wielu lat mamy stos LAMP - aplikację PHP działającą za serwerem Apache i posiadającą dostęp do bazy danych MySQL działającej na Linuksie. Oczywiście, wszystkie serwery działają teraz pod kontrolą Linuksa. I Apache jest nadal w pobliżu, ale został w dużej mierze zastąpiony przez Nginx (chciałbym również, aby LEMP było słowem, a Nginx zaczynał się na literę E, ale nie można mieć wszystkiego), a Nginx jest o tyle łatwiejszy w użyciu niż Apache, że nie warto o nim wspominać w swoim "stosonimie". PHP już nie istnieje (z wyjątkiem jakichś 80% stron internetowych na świecie), po zastąpieniu go trzema rzeczami: front-end JavaScript (lub TypeScript) z wykorzystaniem frameworka Angular oraz back-end JavaScript (a nie TypeScript) z wykorzystaniem Express, jako biblioteki wyższego poziomu, na niskopoziomowym serwerze HTTP Node.js. A baza danych to mocarz NoSQLa MongoDB, a nie MySQL, chociaż mylnie oba zaczynają się od M. Więc teraz mamy stos MEAN.

Oczywiście, kiedy wymyślono termin "stos MEAN", A reprezentowało istniejący wówczas Angular, którego wszyscy kochali oprócz Google'a, który go wymyślił. Google najwyraźniej tak bardzo nienawidził tego Angulara, że zmienili jego nazwę na AngularJS - nazwę, która w każdym innym kontekście nie oznaczałaby deprecjacji, ale tutaj wyraźnie tak się dzieje - i skupili swoje wysiłki na nowej wersji Angulara. Nowa wersja Angulara jest szeroko stosowana, szczególnie w korporacjach, ale nigdzie nie jest tak bardzo kochana jak stary AngularJS.

Z drugiej strony, React z czasem tylko się poprawia. Tam, gdzie Angular jest narzucony, React jest pomocny. Gdzie Angular jest monolityczny, React jest modułowy. React jest trudniejszy do nauczenia się, ale ostatecznie łatwiej się z nim pracuje.

Przypomina mi to konflikt Java vs. .NET z połowy 2000 roku. W tamtych czasach, podczas gdy napędzany przez korporację .NET oferował dokładnie jeden sposób działania i ten jeden sposób zawsze działał, (teoretycznie) napędzana przez społeczność Java oferowała co najmniej kilka sposobów działania nawet w najbardziej podstawowych sprawach, z których każda oferowała swoje własne korzyści i wady.

W tamtych czasach model .NET wydawał mi się bardziej atrakcyjny, ponieważ mogłem szybko załatwiać sprawy i być pewnym, że zadziałają. Dzisiaj uważam, że przeciwny model, z Reactem, jest o wiele łatwiejszy w obsłudze. Co się zmieniło? Może być wiele powodów, tak mi się wydaje, ale najbardziej prawdopodobnym wyjaśnieniem jest lepsze zarządzanie pakietami. Node Package Manager (NPM) umieszcza cały kod bibliotek JavaScript w znanym wszechświecie na wyciągnięcie ręki z linii poleceń. Również wtedy wszystkie zależności były binarne i stosunkowo łatwo było utknąć ze złymi zależnościami. To ryzyko nadal istnieje, ale teraz jest o wiele łatwiejsze do opanowania.

Tak więc Angular (który również obsługuje NPM, ale nie ma dla niego tyle zastosowania) robi wiele dla Ciebie, w zamian za ścisłą zgodność. React wymaga nieco dłuższego poznania i nie zapewnia takiej samej ilości narzędzi w głównej bibliotece, ale znajduje się w centrum bogatego ekosystemu narzędzi, które dzieli tylko kilka klawiszy. Spróbowałem uczciwie Angulara i po prostu za nim nie przepadam.

Nie kocham również Vue, ale widzę, dlaczego inni kochają.

Więc mój domyślny "stos" dla nowoczesnych aplikacji internetowych jest usługą typu back-end działającą na Express i Node (lub ASP.NET Core) - wszystkie z nich, oczywiście, działają na Linuksie z Nginx jako proxy, ale nikogo to nie obchodzi - z bazą danych, którą może być MongoDB, ale jest tak samo prawdopodobny MySQL lub PostgreSQL (nie sposób, aby zmieścić to w akronimie), i React na front-endzie. Nazywają to stosem MERN, ale to nie jest słowo, a skróty muszą być prawdziwymi słowami, inaczej są tylko inicjałami, więc gdzie jest w tym spryt.

Czy stąd bliżej masz do chmur?

A gdzie to wszystko się toczy? W chmurze, oczywiście.

Kto by pomyślał, że będziemy serwować pełnowartościowe aplikacje z sieci CDN (Content Delivery Network), a nie z serwera aplikacji? Ale to ma sens. Logika UI dzieje się w przeglądarce. Po prostu podajesz ją jako statyczną treść, znacznie szybciej i taniej.

Oczywiście, back end nadal potrzebuje serwera aplikacji. I, oczywiście, jest on w chmurze, chyba że jest ku temu dobry powód. To brzmi jak temat na kolejny dzień.

I jak to wszystko jest publikowane? Przez GitHub, oczywiście.

Tego też się nie spodziewałem. Zrób push do GitHuba, a silnik do budowania go zbuduje i uruchomi. Jeśli jesteś na Netlify, to dosłownie zajmuje to tylko kilka minut.

Dodaj usługę taką jak Gatsby i powiąż z nim jakiś CMS headless, taki jak Ghost, a otrzymasz pełne środowisko CI/CD przy minimalnym wysiłku. A także zamieniłeś swój stos MERN w JAMStack (co przewraca całą moją koncepcję stosonimu do góry nogami, ale to nadal fajna idea).

Co dalej?

Szczerze mówiąc, jesteśmy w punkcie, w którym naprawdę trudno mi odgadnąć, co może się wydarzyć w rozwoju sieci. Wydaje mi się, że jestem tak zadowolony z obecnych narzędzi, w porównaniu z tym, co kiedyś mieliśmy, że w tej chwili nie mogę sobie wyobrazić, jaki problem będziemy musieli rozwiązać w następnej kolejności.

Może dlatego młodsze pokolenie jest często innowatorem. Nie wiedzą, jak im dobrze, więc starają się to jeszcze ulepszyć. Nie ma w tym nic złego.