To się zresztą dzieje, tylko w pokurczony sposób, przez generowanie JavaScriptu (GWT, Pyjamas, …)

Taką drogą poszedł Python, który zresztą w wersji 2.x jest świetnym językiem. Mimo to developerzy (słusznie!) uznali, że zmiany są na tyle istotne, by wersja 3.0 była niekompatybilna wstecz. A zmiany między Pythonem 2.6 a 3.0 nie są AŻ TAK ogromne, jak należałoby to zrobić między JS 1.x, a 2.x

Co do kompilatora – to taka moja abstrakcja – nie musi to byc kompilator w sensie stricte, ale jakze fajnym udogodnieniem byloby, gdyby cos sprawdzalo za nas wszelkie odniesienia do DOM, niezgodnosc typow, brak return false/preventDefault w onclickach itd. Zastosowan bylaby cala masa, moze pokusze sie kiedys o jakis manifest przedstawiajacy funkcje takiego rzekomego kompilatora.

Napisz, jestem ciekawy. Bo o ile zgadzam się z Rafałem, to fakt faktem, że JS nie jest doskonały :).

Zastanawiam się tylko, ile można wycisnąć z języka czy „kompilatora” w sytuacji, gdy strony są tak dynamiczne jak obecnie. DOM jest żywym tworem i można go np. przewrócić do góry nogami, wstawiając dowolny string za pomocą innerHTML.

PS. Przydałoby się większe textarea lub opcja do rozciągania go – obecna wersja nie zachęca do pisania dłuższych komentarzy :).

Tutaj nie zgadzam się o tyle, że JavaScript ma po prostu inne podejście do obiektowości. Wszystko jest oparte o prototypy. Ale większość patrzy na JavaScript przez pryzmat innych języków z obiektówką o składni zbliżonej do Javy.

Tak, obiektowka jest inna, ale o wiele bardziej niewygodna. O to glownie sie rozchodzilo, acz zrecznie pominales argumenty o tym mowiace ;-)

JavaScript ma dynamiczną typizację, jak wiele innych języków skryptowych. Jedni programiści wolą języki ze ścisłą typizacją, inni z dynamiczną. Także, uważam, że nie można tutaj mówić o wadach takiego rozwiązania, bo fakt ten ściśle wiąże się ze specyfiką tego typu języków i wybór zależy wyłącznie od upodobań programisty. Obydwa rozwiązania mają swoje wady i zalety.

Jesli chodzi o proste rozwiazania – dynamiczna typizacja to zbawienna cecha jezyka – szybko, prosto, latwo etc. Schody zaczynaja sie, kiedy trzeba utrzymywac duzy kod.

Tutaj bym nieco uważał. Nie zapominaj proszę, że JavaScript nie jest wyłącznie językiem związanym z HTMLem. Język ten znajduje wiele innych zastosowań – nawet coraz szerzej wkrada się na stronę serwera. Czy tam jest potrzebna aż tak ścisła współpraca z HTMLem? Czy tej koniecznej współpracy nie spełniałby sam model DOM?

Poza tym, czy JavaScript nie posiada klarownych reguł w postaci specyfikacji ECMA-Scriptu? Czy na prawdę musi stać się językiem w pełni obiektowym z wyższej konieczności? Czy to tylko – jak już pisałem – nasze przyzwyczajenia?

Popatrzcie na jedno – najpierw byl JS w kontekscie webu, dopiero potem powstaly jego ewolucje, inne zastosowania (vide dodatki do Fx itd.). Podobnie bylo z PHP – np. PHP GTK. W obydwu przypadkach mamy do czynienia z jezykami niedopracowanymi, nadajacymi sie do szybkich i prostych zastosowan. Kiedy jednak przychodzi co do czego, w kwestii duzych projektow, wychodza wszelkie wady tych jezykow.

Nie nalezy jednak przesadzac w druga strone – nie robic z JS kombajnu, w ktorym nie napiszemy szybko 2 linijek kodu jak dotychczas. Chodzi raczej o to, by rozwinac ten jezyk na tyle, by utrzymanie i DEBUG kodu byl o wiele przyjemniejszy. Mnie gimnastyka z Firebugiem srednio odpowiada.

Co do kompilatora – to taka moja abstrakcja – nie musi to byc kompilator w sensie stricte, ale jakze fajnym udogodnieniem byloby, gdyby cos sprawdzalo za nas wszelkie odniesienia do DOM, niezgodnosc typow, brak return false/preventDefault w onclickach itd. Zastosowan bylaby cala masa, moze pokusze sie kiedys o jakis manifest przedstawiajacy funkcje takiego rzekomego kompilatora.

W kazdym razie JS, co chcialem wyrazic generalnie w artykule, jest bardzo ciezkim w utrzymaniu jezykiem, majacym wiele wspolnych cech z PHP – a glowna jest masa problemow i niezgodnosci, ktore z latwoscia moglyby byc naprawione na rzecz szybszego i skuteczniejszego developmentu.

Pozdrawiam i dziekuje za tresciwy komentarz!

A co do dynamiczna typizacja vs ścisła typizacja – jedno i drugie ma zalety. W PHP mam dynamiczną, w C++ ścisłą i nie narzekam.

To tysiące standardów, to setki problemów, to jeden JavaScript, więc ugryź suchara ;)

PS. Co Wy, ludzie macie z JAVA-mi, UNIX-ami, LINUX-ami? niedługo będzie MICROSOFT WINDOWS…

O ile CSS i XHTML współpracują ze sobą dość dobrze, tak JavaScript sprawia wrażenie przyszywanego wujka. Przede wszystkim, w JS pokutuje prawie to samo, co w PHP – naciągana obiektowość.

Tutaj nie zgadzam się o tyle, że JavaScript ma po prostu inne podejście do obiektowości. Wszystko jest oparte o prototypy. Ale większość patrzy na JavaScript przez pryzmat innych języków z obiektówką o składni zbliżonej do Javy. Także możemy tutaj mówić tylko o pewnym przyzwyczajeniu i nawet nie staramy się zrozumieć specyfiki tego języka. Przez wiele lat nikomu to nie przeszkadzało i JavaScript zyskał swoją popularność.

Niedostatki obiektowości powodują, że nie mamy choćby kontroli typów, przez co mnożą się instrukcje warunkowe, wspomagane przez typeof.

JavaScript ma dynamiczną typizację, jak wiele innych języków skryptowych. Jedni programiści wolą języki ze ścisłą typizacją, inni z dynamiczną. Także, uważam, że nie można tutaj mówić o wadach takiego rozwiązania, bo fakt ten ściśle wiąże się ze specyfiką tego typu języków i wybór zależy wyłącznie od upodobań programisty. Obydwa rozwiązania mają swoje wady i zalety.

Jak pisałeś, JavaScript 2 miał oferować pełną obiektowość znaną z innych języków. Nie twierdzę, że to złe, bo jednak przyzwyczajenia biorą górę i szkoda marnować czasu na niestandardowy w tym momencie model obiektowości. Uważam, że migracja na nową wersję języka miałaby szansę na szybkie zaistnienie, ale tylko pod warunkiem szybkiego wprowadzenia obsługi przez poszczególnych producentów przeglądarek. Oczywiście konieczna byłaby możliwość współistnienia obydwu wersji języka jednocześnie na stronie. Nie wszyscy przecież są programistami i będą korzystać z gotowych skryptów na swoich stronach. Raz trafią na skrypt „starej generacji”, drugi raz na skrypt napisany w JS2. A to znowu wiąże się z koniecznością utrzymywania dwóch silników JS w przeglądarkach… oj, kiepsko to wygląda. Rozsądnym rozwiązaniem wydaje się być ta wsteczna kompatybilność, ale jak sam napisałeś, nie wszyscy chcą się w to bawić.

By sen się ziścił, potrzeba klarownych reguł języka. JavaScript musi stać się w pełni obiektowy. Również relacje z HTML powinny być o wiele bardziej zacieśnione. Nie ukrywajmy tego, skoro w JavaScript istnieje obsługa DOM, dlaczego jeszcze bardziej nie popchnąć języka w tę stronę? Przecież większość skryptów odnosi się do struktury dokumentów HTML!

Tutaj bym nieco uważał. Nie zapominaj proszę, że JavaScript nie jest wyłącznie językiem związanym z HTMLem. Język ten znajduje wiele innych zastosowań – nawet coraz szerzej wkrada się na stronę serwera. Czy tam jest potrzebna aż tak ścisła współpraca z HTMLem? Czy tej koniecznej współpracy nie spełniałby sam model DOM?

Poza tym, czy JavaScript nie posiada klarownych reguł w postaci specyfikacji ECMA-Scriptu? Czy na prawdę musi stać się językiem w pełni obiektowym z wyższej konieczności? Czy to tylko – jak już pisałem – nasze przyzwyczajenia?

Kłania się potrzeba kompilatora lub czegoś w tym rodzaju. Najlepiej byłoby, gdyby tłumaczył on kod JS na inny, ściśle znany tylko przeglądarce. Tylko skompilowany program mógłby zostać użyty na stronach internetowych. W innym wypadku, dołączenie plików “przypominających” poprawny JS byłoby niemożliwe.

Ta idea, moim zdaniem, odbiłaby się na dynamice i pewnej łatwości w tworzeniu aplikacji webowych. Obecnie wystarczy zasiąść za komputer, otworzyć notatnik i napisać skrypt. Wprowadzenie dodatkowego elementu wiązałoby się z koniecznością instalacji/posiadania dodatkowego oprogramowania. W tym momencie całe to oprogramowanie trzebaby nosić cały czas przy sobie, żeby cokolwiek napisać. Poza tym, co taki kompilator by dał? Byłby w zasadzie w stanie wyłapać błędy składniowe (co konsole błędów wbudowane w przeglądarki potrafią) i kontrolować typy danych (jeśli język stałby się ściśle typizowanym językiem). A reszta? Nie dałoby się wychwycić wielu rzeczy w procesie kompilacji, bo sam HTML, na którym nasze skrypty operują jest jedną wielką zmienną, która dynamicznie się zmienia. Tutaj uważam kompilator za całkiem zbyteczny element.

Mianowicie, czy JavaScript, CSS i XHTML noszą na swoich plecach pokaźny garb wyraźnych niedociągnięć i problemów, które programistę server-side po prostu irytują i przyprawiają o śmiech politowania?

Może i jest to faktem, ale programiści serwerowi mają o tyle ułatwioną sprawę, że mają na serwerze jedno oprogramowanie i wiedzą, co i jak mają pisać. Programiści aplikacji klienckich mają sprawę o tyle utrudnioną, że muszą borykać się z kilkoma silnikami przeglądarek, których producenci przyzwyczaili nas do wprowadzania własnych autorskich rozszerzeń, a nie dbają o kompletną i poprawną implementację tego co zostało zdefiniowane w standardach. Co więcej, większość z dzisiaj obowiązujących standardów nadawała się dobre kilka lat temu, dzisiaj niestety stają się powoli bezużyteczne. Świat idzie do przodu i te najważniejsze standardy powinny się rozwijać. A jak sam napisałeś, definiuje się coraz to nowsze standardy, które nie są implementowane i przez to są bezużyteczne. Za przykład weźmy XHTMLa. Tak, ma swoje zalety, ale po co to? Wystarczy przecież rozbudować i zaktualizować starego poczciwego HTMLa i wszystko będzie dobrze. Wydaje się, że częściowo deweloperzy to zrozumieli i opracowuje się obecnie „coś” zwane HTML5.

Najlepiej byłoby zacząć wszystko od nowa, ale łatwo się mówi, gorzej wykonać. Nowy standard dzisiaj zdefiniować to banał, ale czekanie na implementację standardu w nieskończoność skutecznie zniechęca. Z dnia na dzień nie zmieni się całej sieci, więc niestety muszą wystarczyć półśrodki w postaci drobnych zmian aktualnie obowiązujących standardów.

rzadko zdarza się (wcale?), że kod napisany w jednym miejscu, nadpisuje inny. Hermetyzacja robi swoje.

Tak, tu się zgadzam. Wprowadzenie przestrzeni nazw skutecznie rozwiązałoby problem.

To chyba tyle chciałem przekazać. Jak sobie jeszcze coś przypomnę, to dopiszę.