Walka Dart vs JavaScript – nokaut podczas ważenia
Myślałem, że nie napiszę nic o Darcie, bo cała historia z nim związana z początku nie wywoływała we mnie żadnych specjalnie negatywnych czy pozytywnych emocji. Dzięki Zbyszkowi Branieckiemu i Markowi Stępniowi trochę szerzej spojrzałem na temat, biorąc pod uwagę też historie o których, czy to z racji mojego krótkiego życia, czy braku wiedzy o pracach komitetów i producentów przeglądarek, nie wiedziałem i… sami przeczytajcie. Załączam poniżej coś co miało stać się przydługim komentarzem na forum Goldenline.
Pożal się Google
To co zrobiło Google, to żart. Cała historia z wewnętrznymi, nie do końca miłymi mailami z Google’a, które wyszły na światło dzienne, sam Dart i otoczka PR-owa jaką ma, to jedno wielkie nieporozumienie. Google się nie popisało i, moim skronym zdaniem, wyjdzie to tylko na dobre open webowi.
Wyobraźmy sobie, co by się stało gdyby Dart rzeczywiście powalał na kolana i miałby świetnie zaimplementowaną, super wydajną i dostępną out of the box w Chrome maszynę. Szybko znalazłoby się grono fan boy’ów, którzy bez zastanowienia zaczęliby pisać aplikacje „only for Chrome”, bądź „works best with Chrome”, z ewentualną, wątpliwej jakości, kompilacją do powolnego i starego JavaScriptu dla „gorszych przeglądarek”. (BTW. hello world w Dartcie skompilowany do JS to 17000 linii kodu :D).
Po chwili okazałoby się, że Google, wykorzystując swoją pozycję lidera na wielu rynkach, zaczyna (pośrednio – przez zadowolonych użytkowników) wymuszać na innych producentach implementację Darta. No dobra – wygrał, ale w czym problem, pytacie? W tym, że Google nie raczy podzielić się odpowiedniej jakości specyfikacją języka i Mozilla, MS, czy Opera zostają zmuszone do reverse engineeringu z Chrome’a. Brzmi jak głupia apokaliptyczna wizja? Problem w tym, że ten przypadek już mieliśmy z protokołem SPDY, ponieważ Mozilla została zmuszona przez Google do zgadywania jak on w szczegółach działa. Koniec końców, po wykonaniu nieprzyjemnej pracy, pozostali producenci i tak kończą z „gorszą” implementacją. Innymi słowy – wracamy do czasów wojny przeglądarek i nieczystych zagrań. W dodatku pieczę nad specyfikacją języka sprawuje Google i wcale nie mamy pewności, czy się nią podzieli.
Dalej brzmi to jak bajka? Ciekawostka – opublikowana „specyfikacja” (wczesny draft oczywiście) Darta ma 70 stron, a specyfikacja wiele razy mniej złożonego ES5 250 stron. I nie, nie z powodu wielkości fonta. Mówicie – są języki, które radzą sobie bez specyfikacji – Python, Ruby – i są świetne (ktoś wymienił PHP – strzał w stopę w tej dyskusji :D). Tak, ale implementuje je jeden producent. W webie to nie działa i nigdy nie działało. Chcecie żeby przeglądarki miały spójne implementacje, to nie cofajcie się teraz o krok wstecz (prawie jak cofać się do tyłu :P). Nie po to wielokrotnie straciliśmy włosy na głowie (a i twarz też, bo czasami głupio się przyznać – „jestem programistą JavaScript”), by zapominać czego nauczyła nas historia. Nie po to został włożony i nadal jest wkładany ogromny trud w to, by ujednolicić i dogłębnie dospecyfikować wykorzystywane przez nas technologie, byśmy teraz tę pracę skreślili i zaczęli od początku. W szczególności, że…
Na poważnie, czyli z forkowaniem za pan brat
… nie ma takiej potrzeby. Wiele osób, w tym i ja, narzeka na JavaScript. Niektórzy wciąż nie wiedzą ile naprawił ES5 ze strict modem, niektórzy też nie zdają sobie sprawy ile jeszcze problemów jest do rozwiązania. Większość jednak narzeka i moim zdaniem słusznie. Na szczęście trwają prace nad ES6 aka Harmony aka ES.next (w których oczywiście Google uczestniczy). O ile, co smutne, ale racjonalne, ES5 nie wprowadził żadnych (może poza strict modem) przełomowych zmian w JavaScriptcie, o tyle ES6 takie zmiany ma wprowadzić, włącznie z dużymi w składni (choć Marcoos mi ostatnio powiedział, że myślą o wydaniu pośrednim, bez zmian składniowych, stąd pośrednie nazwy – oby pomysł upadł – miejcie jaja, Panowie!).
Na pewno jednak ten właściwy ES6 zrywa ze wsteczną zgodnością. Jest więc pole do popisu i czas, by, jeśli ktoś się postara, niemal od nowa projektować pewne aspekty języka. Można mieć tylko jeden zarzut do Harmony – nic nie wiemy o planowanym terminie zakończenia prac. Jednym z argumentów zwolenników strategii Google jest to, że „nie chcieli czekać, aż się powolny komitet naprodukuje i jako największy gracz wzięli sprawy w swoje ręce”. Brzmi niemal przekonująco. Poza tym, że Darta też szybko w wersji stabilnej i szeroko dostępnej nie zobaczymy (jeśli w ogóle). W dodatku praktyka odległej wersji finalnych HTML5 i CSS3 pokazuje, że dzięki wczesnym prototypom częściowym możemy raz, że wiele poprawić jeszcze podczas prac nad specyfikacją, dwa że płynnie przejść pomiędzy wersjami i szybko z nowych ficzerów korzystać. Co prawda JavaScript, to nie CSS, gdzie możemy sobie pozwolić na graceful degradation, jednak gracze typu Google bez problemu mogą serwować inne źródła w zależności od zdolności przeglądarki (a i tak mówimy o kompilacji ES6 do ES3, bo polyfilli to nie będzie). W dodatku wiele osób pisze aplikacje w JavaScript na w miarę przewidywalne środowiska (intranet, komórki, serwer), gdzie problemu nie ma w ogóle.
Stąd przechodzę do pytania – dlaczego Google zamiast forkować istniejące rozwiązania, nie zdecydowało się na wczesną, testową implementację ES6 w V8 (choć zdaje się chodziły takie słuchy)? Dzięki temu mogłoby wpływać na prace komitetu (wprowadzać ficzery w V8 i pokazywać, że świetnie się przyjmują wśród developerów, bądź po prostu dobrze działają), przyspieszyć je i poprawić zawczasu wiele wątpliwych kwestii. Spotkałem się też z argumentem, że konkurencja jest przecież dobra. Owszem, mamy na szczęście kilku producentów i stosunkowo równomierny ich udział w rynku. Moim zdaniem to wystarcza, co widać choćby na przykładzie wcześniej przeze mnie wspomnianych HTML5 i CSS3 (kontrargument swoją drogą, to to, że wyścig rodzi kiepskie implementacje – vide koszmarne formsy).
Bawi mnie niezmiernie jeszcze jedna kwestia. Dart wcale nie jest fajny. Wygląda jak Java, jest toporny, nie ściągnie gawiedzi jak laska z cycem na wierzchu zwana CoffeeSkryptą (BTW. uroda z inteligencją w parze nie idzie – to może ten Dart taki zły nie jest? Małżeństwo z rozsądku? ;). Nie jest też wybitnie rewolucyjny, ani… odległy od ES6. Koncepcje, które znalazłem w Dartcie widywałem też w materiałach o ES6. Jego implementacja też póki co nie powala na ziemię pod względem wydajności, a był to przecież podobno jeden z powodów porzucenia JS. W dodatku pokazuje to jak wiele pracy jest do wykonania, by dogonić już wiele lat rozwijany engine V8. To jest kolejny powód dla którego nie rozumiem decyzji Google’a.
Jest też plus
Jest jednak jedna rzecz, która mi się podoba w Dartcie – szersza biblioteka standardowa (włączając w to sensowną implementację DOM-a). Uważam, że w tej chwili jednym z największych problemów JavaScriptu, jest brak ustandaryzowanych (mniej, lub bardziej formalnie) podstawowych narzędzi. Ja np. w najświeższym projekcie postanowiłem wykorzystać deferred i es5-ext skompilowane do niecommonjsowej postaci. Zastanawiałem się jednak, czy nie wolę underscore’a. Ale zaraz – deferred i tak korzysta z es5-ext, więc ten kod i tak załaduję (tutaj ukłon w kierunku Medikoo – na szczęscie es5-ext jest 100% zmodularyzowane, więc konfigurowalne). Potrzebowałem jeszcze czegoś do DOM-a. Z jQuery nie skorzystam, bo nie potrzebuję 90% (dosłownie!) tej biblioteki, w dodatku pokrywa mi się z deferred i trochę es5-ext, no i szukałem czegoś lekkiego. Trafiłem na xui.js, które okazało się niedopieszczone. Szukałem czegoś do single page apps – Backbone? Nieee… ktoś wymyślił, że dla XHR-a, delegate’a i deferred (i czegoś jeszcze?) skorzysta z jQuery. Jeszcze gorzej chyba ze Spine.js, gdzie znalazłem jakoś z 5 odniesień do jQuery, ale zaszytych głęboko w kodzie, bez możliwości łatwej podmiany. Przy całym tym śmietniku idiotycznych decyzji twórców tych (i wielu innych) narzędzi, są myślące osobniki, które wyprodukowały takie mini biblioteki jak Crossroads, czy js-signals. Robiące dokładnie jedną rzecz i nie zawierające zbędnych zależności.
Żalę się generalnie, ale nie bez powodu. Dart rozwiązałby połowę moich problemów. Mamy i promise’y, i wygodniejszego DOM-a. Dużo więcej ciekawych rzeczy niestety nie znalazłem, ale początek jest dobry. Uważam, że to jest aspekt języka, na który powinny zwrócić uwagę osoby pracujące nad ES6. Wiem na pewno, że jeden problem zostanie rozwiązany – zostaną wprowadzone natywne moduły. Trochę martwi mnie ich rozbieżność w stosunku do CommonJS-owej wersji (i trochę niezrozumiała dla mnie decyzja o wprowadzeniu nowej składni), ale może uda się to zgrabnie rozegrać.
Podsumowując
Nie wierzę, a przynajmniej nie chcę wierzyć, w sukces Darta. Póki co niczym mnie nie zainteresował i nie zamierzam się w niego zagłębiać. Mam nadzieję, że byłaby to strata czasu.
Zauważyliście pewnie, że brakuje w treści linków do źródeł. Tak – nie chce mi się. Google w tym wypadku pomoże :). Poza tym, nie chcę być wyrocznią, nie chcę napisać pracy doktorskiej, nie chcę nikogo zniszczyć, wypunktowując go bezlitośnie. Co więcej, możliwe, że sam niedługo zmienię na co poniektóre tematy zdanie, bo i nie mam pełnej wiedzy o tym co się dzieje i co się stanie. Powyższa opinia rodziła się we mnie jednak już kilka tygodni, więc nie jest też pisana pod wpływem wielkich emocji. Może więc jest racjonalna :).
Podobne wpisy:
Osoby pracujące nad ES6 (ECMA, TC39) i osoby pracujące nad nowym DOM-em (W3C / WHATWG) to są (niestety) dość rozłączne zespoły… Na szczęście jednym z założeń dla DOM4 / DOM Core jest „[a]lign [the specification] with the needs of ECMAScript where possible”.
http://www.w3.org/TR/domcore/
DOM4 nie będzie jednak tak kompletną rewolucją jak to, co zaproponowano w Dart DOM.
Jedną rzecz, którą chyba trzeba wziąść pod uwagę przy Dart’owych rozważaniach, to to że Google nie do końca mówi jednym głosem. Google to przede wszystkim programiści i wiele różnych działów, często pracujących nad dość eksperymentalnami rozwiązaniami. Dart to raczej głos programistów Javy, którzy nie chcą pisać w JavaScript. Głos, który Google traktując jako jeden ze swoich eksperymentów wypuścił na zewnątrz.
Java jest można powiedzieć zaprzeczeniem języka funkcyjnego, czym nie jest JavaScript, w obydwu językach piszemy zupełnie inaczej. JavaScript nie ma i nie potrzebuje klas, Java bez klas nie istnieje, dwa różne światy, jeśli próbujemy w jednym żyć według zasad drugiego to mamy problem, i mam wrażenie, że Dart jest właśnie próbą rozwiązania takiego problemu, to głos programistów Jav’y, którzy nie godzą się na JavaScript ;-)
Tak przynajmniej ja tę sytuację rozumiem
Nic z Darta nie będzie. Do powodów jakie wymieniłeś dochodzi to, że jest bardzo mocna i zgrana druga strona, strona ludzi, którzy rozumieją JavaScript, wiedzą jak w nim się poruszać, wiedzą czym śmierdzi Java i na pewno nie dadzą JS’a przemianować na Javę
Odnośnie tego co Dart proponuje, to trzeba pamiętać, że to głos paru osób, nie wielkiej społeczności. Praca nad nową wersją JS wymaga dużo większej komunikacji, jak i z racji bagażu przeszłości nie na wszystko można sobie pozwolić.
Z tego co wiem temat asynchronicznych wywołań jest brany pod uwagę w Harmony i chyba pojawiły się jakieś ciekawe pomysły, w samym ES5 chyba nic ciekawszego niż deferred osiągnąć się nie da, jest wiele pomysłów które wymagają dodatkowej kompilacji, ale myślę, że nie tędy droga.
DOM nie jest już częścią ECMAScript to zupełnie inna działka, tu już trzeba się żalić do W3C :)
Odnośnie modułów, to z tego co ja czytałem koncepcja w Harmony jest praktycznie taka sama a nowa składnia wygląda logiczniej, jest bliska temu co mamy w Python’ie co mi się bardzo podoba.
Jest oczywiście parę rozszerzeń (typu asynchroniczne dociąganie) ale to są tylko dodatki , które nie determinują tego jak będziemy korzystać z tej funkcjonalności.
JS dopiero nie dawno (tak na serio) wyszedł z przeglądarki, więc można powiedzieć od nie dawna jesteśmy w punkcie kiedy nasze wymagania odnośnie dostępności narzędzi ich przydatności są znacznie wyższe. Teraz jest ten moment, kiedy tego brakuje i możemy sobie wspólnie takie narzędzia wypracować, przynajmniej na czas dopóki ES6 nie będzie szeroko wspierane.
@Marcoos:
Celna uwaga, co do tej rozłączności. Trochę szkoda, że nie szykują nic przełomowego, ale może też wraz z JS-owym, przewidywalnym DOM-em, łatwiej będzie budować wygodne i lekkie biblioteki. Ja tutaj akurat jestem zwolennikiem rozszerzania prototypów, co teraz jest dużym ryzykiem (choć może dla świeżych przeglądarek już nie – nawet nie wiem), a w przyszłości nie będzie.
Przewidując, że ktoś może zaraz zapostuje http://perfectionkills.com/whats-wrong-with-extending-the-dom/ – warto poczytać komentarze pod tym wpisem – np. http://perfectionkills.com/whats-wrong-with-extending-the-dom/#comment-59342 Moim zdaniem jeśli mówimy o rozsądnym rozszerzaniu (nie zmienianiu!), z sensownym prefiksem (zgodność w przód) i w bezpiecznym środowisku (prawdziwie jsowy dom), to takie podejście jest o wiele lepsze. Choćby ze względu na wydajność.
@Marcoos:
Co nie zmienia faktu, że uzmysłowiłeś mi, że nie doczekam się pewnie jednej, konfigurowalnej, wydajnej, lekkiej biblioteki dla DOM-a :P
@Mariusz:
Z tego co opowiadali tutaj – http://marakana.com/forums/html5/general/498.html to szykują generatory (które już choćby w Fxie mamy, bo wywodzą się z ES4). Generatory (chyba zbieżne z node-fibers, bo to ta sama koncepcja lekkich wątków), ponoć, bo ja nie do końca mam wizję jak miałoby to działać, rozwiązują problem powrotu po odroczeniu. Ja musiałbym zobaczyć kod, bo w tej chwili np. o ile mniej więcej wyobrażam sobie odroczenie jednego callbacka, to co np. z synchronizacją wielu, bądź „równoległym” wykonaniem? To chyba i tak pozostałoby w gestii bibliotek (o czym mówi też David Herman), a to nie to do czego chciałbym aby temat zmierzał. Chyba że myślą jeszcze o samych promise’ach (mam nadzieję, że sam David jeszcze o tym nie mówił, bo jeszcze nie obejrzałem filmiku do końca :P).
No i rzeczywiście nie wspomniałem o tym, że Dart może nawet zastąpić Javę w niektórych przypadkach. Mówi się, że Dart to odpowiedź na ich problemy patentowe związane Javą na Androida. Czas pokaże. Gdyby tak było, to może i fajnie – Dart jest mi chyba bliższy niż Java :)
Wydaje mi się, że było raczej odwrotnie, pojawiły się w śp. ES4, _bo_ były w JS 1.7.
Tego to ja już nie wiem :). Strzelałem w ciemno, że JS1.7. powstał w oparciu o wczesne założenia ES4, ale Ty na pewno masz na ten temat większą wiedzę.
Co jest nie tak z CoffeeScript?
@yanoo: Dużo i chyba wymagałoby to ode mnie osobnego artykułu :). Gwoli jasności, jest jednak podstawowa różnica pomiędzy CS a Dartem – CS jest laską z cycem, a Dart starą szkaradą. Jako że na szybko wolałbym laskę z cycem, to o samym CS-ie jako języku (składnia, semantyka) niewiele złego mogę powiedzieć. Chyba jedynie to, że nie da się redeklarować (bez szkaradnego `var x`) zmiennej w zagnieżdżonym scope’ie, czyli jeśli zmienna była już zadeklarowana w scope’ie wyżej, to we wszystkich funkcjach wewnątrz operujemy na tej jednej. To może powodować ogromniaste zależności i… po prostu uważam, że to jest jak obcięcie jednego z palców – będę lżejszy, ale nie podrapię się po zadku.
Druga kwestia związana z samym językiem, to trochę składnia, bo nie jestem wielkim zwolennikiem pomijania wszelkich wizualnych separatorów (klamry, nawiasy, średniki). Ale to już moja subiektywna ocena.
CS to jednak laska na jedną noc. Przede wszystkim i tak trzeba umieć dobrze JS, żeby dobrze programować w CS. Po drugie, mówi się, że semantyka kodu w CS-ie jest banalna i szybko wiadomo OCB. Nie zgadzam się. Nie dość, że i tak trzeba znać semantykę kodu w JS, to jeszcze reguły translacji, których jeśli się nie zgłębi w 100%, to zawsze można się zdziwić. A programiści nie lubią się dziwić. No chyba, że robią projekt na 100 linii kodu – w tedy CS to dla wielu na pewno zbawienie.
Kolejna sprawa, to „forkowanie wiedzy”. Trafiałem już nieraz na projekty gdzie ktoś sobie wymyślił, że zacznie pisać w CS-ie i, jak wiemy, żeby z jakiejś darmowej biblioteki skorzystać, to najczęściej trzeba przejrzeć jej kod. Problem w tym, że nie chce mi się uczyć CS-a i ten kod nie jest tak w 100% dla mnie zrozumiały. Oczywiście, wielu powie – naucz się chociaż podstaw CS-a. Ok – gdyby to był jedyny fork JS-a, to jasne. Problem w tym, że skoro powstał jeden, to może powstanie drugi, trzeci i dziesiąty. Już widziałem coś co się nazywało JavaScript+. Niedługo trzeba będzie znać 5 języków żeby korzystać do woli z wszystkich bibliotek Node’owych i client-side’owych. Wolałbym to zdusić w zalążku i po prostu nic w CS-ie nie robić.
Pewnie, jakbym miał trochę więcej czasu, to bym jeszcze coś wymyślił w tym temacie :).
PS. debugowanie – każdy CS-owiec z którym rozmawiałem mówił, że to problem.
Niemożność redeklaracji bywa uciążliwa, ale… sam fakt jej potrzeby to code smell ;)
Mnie składnia urzekła, taki soczysty ekstrakt z ruby i python’a.
Nie wiem co się mówi o wejściu do CS, ale znajomość JS jeżeli nie jest wymagana, to na pewno pomaga. Ale czy to problem? Jeżeli ktoś zna JS i Ruby albo Pythona, to po kilku godzinach z CS-em jest w stanie pisać w nim, jakby to robił od miesięcy.
Z „forkowaniem” wiedzy i 5 językami… na RuPy był dobry wykład, gdzie Fred George powiedział mniej więcej tak: „kiedyś mówili, że jak jak masz w projekcie 1-2 technologie, to jest ok, jak więcej to masz problem. A co dziś robimy?” i tu slajd z mnóstwem nazw od html, przez ruby, js, cs, sass, json i jeszcze parę. Wg mnie to nie jest problem, ale oznaka czasów. Jeżeli jakaś technologia wymaga niewiele czasu, by się w nią wdrożyć, a znacząco potrafi przyspieszyć i usprawnić produkcję – to czemu nie?
Co prawda nie miałem jeszcze okazji użyć CS w wielkim projekcie, ale nie przy odpowiedniej jakości kodu to nie powinien być problem.
Moim zdaniem właśnie nauczyć się CS-a na poziomie bezpiecznym przy dużym projekcie, to nie jest „szybko”, „krótko”, „w kilka godzin”. Zawsze znajdą się szczegóły składni, czy semantyki, które nie będą oczywiste po tak krótkim czasie, które nie są typowymi przykładami zastosowań, ale mogą narobić sporo problemów.
W dodatku – zawsze programiści dążą do tego, żeby wyciągnąć z języka jak najwięcej, naginając jego możliwości do granic. Znam JS, więc mogę sobie na to pozwolić. Nie sądzę, by ktoś, nawet znając świetnie Pythona, czy Rubiego (nota bene znam na średnim poziomie obydwa), był wstanie tak programować.
Przykład: http://wookieb.pl/2011/07/prywatne-metody-w-coffeescript/
Jeśli chodzi o CS, to mam jedną nadzieję – że zaryzykują z ES-em i trochę fajnych bajerów zapożyczą :P I wtedy CS przestanie być potrzebny :P