Po pierwsze - nie zepsuć internetu

Po pierwsze - nie zepsuć internetu

Dynamiczny rozwój przeglądarek oraz technologii działających po stronie klienta sprawia, że każdego roku kolejne zastępy programistów decydują się na pracę w szeroko rozumianym web developmencie. Tworzenie rozwiązań dla internetu przynosi wiele satysfakcji, jednak wiąże się też z wieloma wyzwaniami o których programiści – np. rozwiązań desktopowych – nie mają pojęcia. Jednym z takich wyzwań jest rozwijanie przeglądarek i języków takich jak JavaScript w taki sposób, aby… nie zepsuć internetu. 

Kiedy aktualizacje burzą spokojny sen

Wyobraź sobie aplikację którą tworzyłeś w pocie czoła przez ostatnich kilka miesięcy i która wreszcie wychodzi z okresu intensywnego developmentu. Pojawiają się pierwsi klienci, rozwój aplikacji zaplanowany jest na kolejnych kilka miesięcy, a budżet wygląda lepiej niż przewidywałeś. Projekt dystrybuowany jest w formie Software as a Service, czyli usługi dostępnej poprzez przeglądarkę internetową. Wszystko wygląda pięknie do czasu, kiedy jeden z klientów informuje cię, że po aktualizacji Firefoxa twoja aplikacja nagle przestała działać – połowa interfejsu użytkownika po prostu zniknęła. Kolejni klienci zaczynają zgłaszać ten sam problem – aktualizacja przeglądarki powoduje problem który blokuje korzystanie z twojej aplikacji.

Wszystko wskazuje na problem w warstwie front-endowej. Co mogło go jednak spowodować?

Twoje doświadczenie podpowiada ci, że większość problemów związanych z front-endem powiązana jest z przeglądarkami które nie wspierają najnowszych funkcjonalności języka JavaScript. W tym wypadku problem wygląda jednak inaczej – klient aktualizuje przeglądarkę i w tym momencie twój produkt jest dla niego bezużyteczny. Po obniżeniu wersji przeglądarki twoja aplikacja znowu zaczyna działać poprawnie.

Bajka? Nie – aktualnie świat front-endu zastanawia się nad konsekwencjami wprowadzenia do standardu języka funkcji flatten oraz flatMap, które jak się okazało – nie są tak neutralne jak mogłoby się wydawać. Gra toczy się o sporą stawkę – nikt nie chce zepsuć internetu.

Niekorzystna prognoza pogody

Wszystko zaczęło się kilkanaście godzin temu. W trackerze bugów przeglądarki Firefox pojawił się ticket dotyczący problemów z widgetem na jednej ze stron prezentujących prognozę pogody – bug dostępny jest w tym miejscu. Korzystając z najnowszej wersji przeglądarki Firefox, która implementuje jedne z najnowszych funkcjonalności języka JavaScript (które de facto jeszcze nie znajdują się w standardzie), widget na stronie jest niewidoczny. Problem związany jest tylko z najnowszą wersją przeglądarki.

Powód? Strona o której mowa używa biblioteki MooTools – swego czasu niesamowicie popularnego rozwiązania wykorzystywanego do tworzenia interfejsów użytkownika – która to biblioteka zawiera swoją własną implementację funkcji flatten. Korzystając z przeglądarki która daną funkcjonalność posiada w standardzie, MooTools wykorzystuję tę standardową implementację, która jak się okazuje nie jest kompatybilna z resztą biblioteki. Aktualizując przeglądarkę do wersji która zawiera WIĘCEJ funkcjonalności języka JS, może się okazać, że MNIEJ stron internetowych będzie działać poprawnie.

Przemnażając taki problem przez tysiące stron internetowych okazuje się, że znajdujemy się w kropce. Czy wprowadzenie nowej funkcjonalności do języka usprawiedliwia problemy z korzystaniem ze wybranych aplikacji? W idealnym świecie wprowadzanie nowych funkcjonalności powinno możliwie rzadko łamać interfejsy z których korzystamy (API) – czy w tym przypadku problemu można uniknąć? Sprawa jest nieco bardziej skomplikowana niż się wydaje…

Kto decyduje o tym, co znajdziemy w najnowszej wersji przeglądarki?

W skrócie – TC39, czyli komitet zajmujący się standaryzacją i rozwojem technologii ECMA Script. Składa się on m.in. z przedstawicieli firm tworzących przeglądarki internetowe oraz osób które w aktywny sposób angażują się w rozwój technologii internetowych. Obrady komitetu to w głównej mierze przegląd wybranych funkcjonalności języka, które mogą znajdować się na jednym z pięciu  etapów – 0, 1, 2, 3 i 4 – od luźnych propozycji do aktualnego standardu. Im dalszy etap, tym bliżej danej funkcjonalności do zamieszkania w naszych przeglądarkach.

Paradoks z tą problematyczną funkcją flatten polega na tym, że znajduje się ona już na etapie trzecim całego procesu – do momentu kiedy stanie się ona oficjalnie częścią standardu języka dzielą nas tygodnie. Społeczność skupiona wokół TC39 do tej pory nie widziała większych przeszkód dla których flatten oraz flatMap nie powinny zostać ustandaryzowane. Funkcje te są doskonale znane programistom innych języków, więc JavaScript był naturalnym kandydatem do otrzymania takiej właśnie funkcjonalności.

Problem jedynie w tym, że wprowadzając do standardu funkcje o których mowa, wiele stron internetowych może po prostu przestać działać poprawnie.

Co teraz?

Jedną z najbardziej kontrowersyjnych propozycji jest zmiana nazw obu funkcji na smoosh oraz smooshMap – pull request w którym taka sugestia została zgłoszona stał się już niemal memem, ponieważ wielu programistów uważa zmianę doskonale znanego flatMap na smooshMap za ponury żart. Drugie z proponowanych rozwiązań dotyczy aktualizacji biblioteki MooTools, jednak tutaj problemem jest dystrybucja aktualizacji – strony korzystające z MooTools nie pamiętają czasów managerów paczek, a większość z nich nie jest zapewne utrzymywana, więc dystrybucja aktualizacji biblioteki jest prawie niemożliwa.

Historia pokazuje, że zmiana nazwy funkcji jest całkiem możliwa – to samo stało się jakiś czas temu z contains (dzisiaj znanym jako includes) którego ustandaryzowanie powodowało takie same problemy na stronach korzystających z konkretnych bibliotek. Mając na uwadze dotychczasowy rozwój internetu i nacisk na zmiany wstecznie kompatybilne wydaje się całkiem prawdopodobne, że nazwa flatten nie będzie tym, czego w niedalekiej przyszłości będziemy używać rozwijając nasze projekty. Czy będzie to jednak smoosh? Wraz z setkami innych programistów trzymam kciuki za coś brzmiącego chociaż trochę poważniej.

Co wy sami myślicie o tym problemie? Czy nowe funkcjonalności ECMAScript’u powinny być za wszelką cenę wstecznie kompatybilne ze stronami które możemy spotkać w dzisiejszym Internecie? Co w przypadku aplikacji których rozwój zakończył się wiele miesięcy temu – czy koszt ich utrzymania nie jest w tym przypadku zbyt duży? Dajcie znać w komentarzach – czekamy też na propozycje nazw zastępujących smoosh 😉

Powiązane

Artykuły o .Net i Javascript – DDZ #4 Paczka wartościowych materiałów, które możecie znaleźć w sieci. Jeżeli chcesz zapoznać się z pozostałymi ciekawymi linkami możesz zrobić to tutaj....
Enhance your development workflow with npm link npm is the most popular package manager in JavaScript ecosystem. I'm sure that huge number of our readers may be familiar with this tool, because ...
Frameworki frontendowe, nauka CSS, git books ̵... Paczka wartościowych materiałów, które możecie znaleźć w sieci. Jeżeli chcesz zapoznać się z pozostałymi ciekawymi linkami możesz zrobić to tutaj....
Jak zmienia się front-end Front-end to stosunkowo młoda dziedzina programowania, która w ostatnich latach niesamowicie przyśpieszyła. W dzisiejszym poście - o nieco innej n...