Strona 1 z 1

JavaScript a Visual Basic Script. Podobieństwa i różnic...

PostNapisane: 19 września 2006, o 20:37
przez Wydra707
JavaScript a Visual Basic Script. Podobieństwa i różnice z punktu widzenia amatora (MSIE)
 
Zawartość:

  Zakres możliwości
  Łatwość nauki
  Ilość funkcji
  Daty i ustawienia regionalne
  Pułapki kalendarza
  Szybkość
  Pułapka zaokrągleń
  Odporność na (nasze!) błędy
  Na stronie www
  Poza stroną www
  Inna filozofia
  Który lepszy?

 
Internet Explorer „rozumie”, a Pajączek wspiera trzy języki skryptowe „client-side”: JavaScript, JScript (oba niemal identyczne i oznaczane skrótem JS) i Visual Basic Script (VBS). Który wybrać? Oto podobieństwa i różnice z punktu widzenia amatora.

Zakres możliwości

Ani JavaScript, ani Visual Basic Script nie góruje pod względem możliwości nad konkurentem. Mitem są więc opinie o „bezpiecznym” JavaScripcie w przeciwieństwie do „groźnego” VBS-u (wirusy!). W systemie operacyjnym Windows podobnych zniszczeń dokonamy obydwoma językami. Na stronie www również nie ma rzeczy możliwych dla VBScriptu, a niemożliwych dla JavaScriptu, lub odwrotnie. Wiele skryptów trzeba pisać inaczej, czasami kod jest dłuższy w jednym, a czasem w drugim języku. Niektóre funkcje są wygodniejsze w JS, a inne w VBS. Ale ogólna funkcjonalność jest w obu przypadkach taka sama.

Łatwość nauki

W moim odczuciu VBScript jest językiem prostszym, łatwiejszym do opanowania, i o bardziej logicznym wyglądzie kodu. Oto krótka funkcja sumująca liczby od 1 do podanej wartości max. Pierwszy przykład w języku JavaScript, drugi w VBScript:

function licz(max) {
  var i, x
  x = 0
  for(i = 1; i <= max; i++) {
    x += i
  }
  return(x)
}

Function Licz(max)
  Dim i, x
  x = 0
  For i = 1 To max
    x = x + i
  Next
  Licz = x
End Function

Drugi przykład wydaje się łatwiejszy do zrozumienia, ma też mniej (a w zasadzie wcale) średników i nawiasów, których pominięcie powoduje błędy w JS (a w przykładzie JS pominąłem już sześć średników, które nie są konieczne, a tylko zalecane!). W VBS jeśli coś się zaczyna, to się także wyraźnie kończy (ForNext; SubEnd Sub; FunctionEnd Function). W JS decydują o tym nawiasy klamrowe, które przy kilku poziomach zagnieżdżeń nietrudno pogubić.

Dodatkowo, VBS jest niewrażliwy na wielkość liter, można więc pisać nazwy funkcji i zmiennych w sposób dowolny — tak, jak jest dla nas czytelniej. Np. ja zapisuję czasem instrukcje dużymi literami wyróżniając je w ten sposób z kodu (FOR i = 1 TO max). Nawet tak dziwaczny zapis będzie w VBS prawidłowy: cAlL wInDoW.rEsIzeTo(300, 300).

W JS wielkość liter ma znaczenie. Wystarczy napisać For(i = 0; i < 5; i++) i otrzymujemy komunikat błędu (poprawnie: for(i = 0; i < 5; i++)). Także i oraz I to dwie różne zmienne. W odwołaniach do obiektów i metod DHTML dopuszczalny jest tylko prawidłowy zapis, np. window.resizeto(300, 300) wywoła błąd (prawidłowo: window.resizeTo(300, 300)). W efekcie w kodzie JS łatwiej o pomyłkę.

VBS daje ładniejszy kod także z uwagi na ciekawy sposób obsługi zdarzeń. Wystarczy odpowiednio nazwać podprogram, by został on powiązany z wybranym elementem strony. Na przykład chcemy wywołać procedurę kliknięciem elementu DIV:

<DIV ID="Test">Kliknij mnie</DIV>

W skrypcie w dowolnym miejscu dokumentu (zazwyczaj w sekcji HEAD) piszemy podprogram nazywając go: idelementu_zdarzenie()

Sub Test_ONCLICK()
  Call MsgBox("Dziękuję za kliknięcie", 64)
End Sub

…i podprogram zostaje automatycznie powiązany ze zdarzeniem ONCLICK elementu o identyfikatorze Test. W JScripcie można uzyskać zbliżony efekt, ale skrypt trzeba umieścić na końcu strony (lub przynajmniej za interesującym nas obiektem), bądź stosować atrybut DEFER, co nie jest już tak wygodne i elastyczne.

W VBS można też korzystać z tradycyjnego zapisu z atrybutem (zdarzeniem) wpisanym wprost w kodzie elementu (ONCLICK="…"). Jednak możliwość pełnego oddzielenia skryptów od kodu HTML wydaje się szczególnie elegancka.

Ilość funkcji

JavaScript posiada więcej gotowych funkcji (zwanych tu metodami) niż VBS. Z większości rzadko się korzysta, ale są i takie, których w VBS brakuje. Przykładem może być metoda sort() sortująca tablicę. W VBS funkcje sortujące trzeba sobie pisać samemu.

JS dysponuje metodami push(), pop(), shift() i unshift() pozwalającymi na korzystanie z tablicy jak ze stosu — odkładanie i zdejmowanie danych z pierwszej lub ostatniej pozycji. W ten sposób łatwo stworzyć historię wprowadzanych danych. „Świeże” wartości układamy na szczycie stosu, a najstarsze usuwamy z jego spodu. W VBS takie działania wymagają pisania dłuższych funkcji.

W JS wielkość tablicy zmienia się samoczynnie w miarę dodawania (lub usuwania) kolejnych pozycji. W VBS rozmiar tablicy ustalamy z góry, i choć można go czasem zmienić, wymaga to osobnych poleceń, co komplikuje skrypt. Próba dopisania szóstej pozycji do pięciopozycyjnej tablicy wywoła w VBS błąd (podczas gdy w JS automatycznie powiększy tablicę do wymaganego rozmiaru). Na osłodę VBS oferuje tablice wielowymiarowe, w JS osiągalne tylko w sposób symulowany.

JS dysponuje metodą escape() zamieniającą spacje i znaki spoza podstawowego zestawu ASCII na kody „zdatne” do przesyłania przez Sieć (przykładowo tekst Góralu, czy ci nie żal? zostanie zamieniony na ciąg: G%F3ralu%2C%20czy%20ci%20nie%20%u017Cal%3F). Metoda unescape() dekoduje tekst. To samo, ale w stosunku do adresów URL, wykonują metody encodeURI() i decodeURI(). W VBS takich funkcji nie ma.

JS posiada wygodne operatory zwiększania (lub zmniejszania) wartości zmiennej. Aby zwiększyć wartość zmiennej mojwiek o 1, wystarczy napisać: mojwiek++. W VBS trzeba pisać dłużej: mojwiek=mojwiek+1. VBS nie ma też operatorów „szybkiego” dodawania, odejmowania, mnożenia, dzielenia (i innych działań). Aby dodać liczbę 3 do zmiennej mojwiek, w JS wystarczy zapis: mojwiek+=3. W VBS: mojwiek=mojwiek+3. Jeśli zwiększaną wartością jest jakaś głęboko ukryta właściwość elementu, zapis w VBS może stać się tak długi, że lepiej wprowadzić dodatkową zmienną.

W JS mamy do dyspozycji wyrażenia warunkowe, skracające zapis prostych warunków. Wyrażenie: (x>100)?"dużo":"mało" zwróci łańcuch dużo, gdy x będzie większe od 100, lub mało w przeciwnym wypadku. W VBS takie działania muszą mieć formę pełnego warunku IfThenElse.

JS posiada wygodne metody min() i max() zwracające największą lub najmniejszą wartość z kilku podanych. Jeśli chcemy pobrać największą liczbę z czterech zmiennych: w, x, y, z, a nie wiemy, która z nich ją zawiera, piszemy po prostu Math.max(w, x, y, z). W VBS w takiej sytuacji trzeba stosować porównania i warunki.

JS posiada więcej gotowych funkcji trygonometrycznych oraz kilka wbudowanych stałych, jak pi, e czy pierwiastek z 2 i z 0,5. W VBS obliczenia trygonometryczne trzeba składać z podstawowych dostępnych funkcji (na szczęście Microsoft podaje niezbędne wzory), a brakujące stałe znać samemu lub wyliczyć. Np. funkcja arcus cosinus, w JS uzyskiwana prosto: Math.acos(x), w VBS wygląda tak: Atn(-x/Sqr(-x*x+1))+2*Atn(1).

Ale i VBS ma coś, czego JavaScript może mu pozazdrościć — własne okienka dialogowe (JS korzysta tylko z okienek udostępnianych przez przeglądarkę). W okienkach tworzonych funkcją MsgBox() można wybierać wyświetlaną ikonę, ilość i rodzaj przycisków, napis na pasku tytułowym, modalność. Można uzyskać praktycznie wszystkie standardowe okienka komunikatów i ostrzeżeń, jakie spotykamy w „prawdziwych” programach. Okienka są dostępne wszędzie, gdzie używamy VBS, także poza stroną www.

W sumie przewaga JavaScriptu nad VBScriptem, liczona ilością obiektów, właściwości, metod, jest dwu- trzykrotna.

Daty i ustawienia regionalne

Jeśli chcemy operować datami lub czasem, VBScript jest wygodniejszy, mimo mniejszej liczby funkcji z tego zakresu niż w JS. W VBS mamy osobny podtyp zmiennej przechowującej daty, co upraszcza zapis, i zestaw skutecznych funkcji konwertujących na daty zwykłe łańcuchy — i to ze sporą dozą domyślności. Daty mogą być wyświetlane w formie cyfrowej lub zawierać słowne nazwy miesięcy i dni tygodnia (data długa) bądź ich skróty — po polsku lub w innych językach (!).

Operacje na datach są w VBS intuicyjne. Proste odjęcie dwóch dat daje różnicę czasu liczoną w dobach (w JS w milisekundach). Dodanie liczby do daty daje datę po upływie wskazanej liczby dni. Ułamki są traktowane jak części doby, np. 2,5 to 2 dni i 12 godzin.

W VBS można operować różnymi jednostkami czasu — sekundami, minutami, godzinami, dniami, tygodniami, miesiącami, kwartałami, latami. Przy czym za podstawę przyjmowane są jednostki kalendarzowe. Przykładowo, między 7 i 11 marca 2005 upłynęły 4 dni i 0 tygodni (ponieważ kalendarzowy tydzień był wciąż ten sam), a między 7 i 11 kwietnia 2005 — te same 4 dni, ale już 1 tydzień (bo kalendarzowy tydzień uległ zmianie). JavaScript nie dostrzega takich niuansów — w obu przypadkach dowiemy się, że upłynęło… 345600000 ms. Przeliczenie tej liczby na żądane jednostki, z uwzględnieniem kalendarza, wymaga dalszych operacji.

W VBS można odczytać z daty nie tylko numer roku, miesiąca i dnia, lecz także numer dnia w roku, numer tygodnia w roku, numer kwartału. Możemy łatwo dodać do daty bieżącej 7 tygodni i 5 dni i dowiedzieć się, czy termin wypadnie jeszcze w trzecim, czy może już w czwartym kwartale roku. W JS takie operacje wymagają pisania dłuższych funkcji.

VBS formatuje daty, waluty i liczby zgodnie z ustawieniami regionalnymi komputera, na którym uruchamiany jest skrypt. Nazwy miesięcy i dni tygodnia wyświetlane są w odpowiednim języku, kwoty pieniężne we właściwej walucie, a ułamki z prawidłowym symbolem dziesiętnym. Przykładowo, wynik dzielenia 3/2 to w Polsce 1,5 (z przecinkiem), a w Anglii 1.5 (z kropką). JavaScript zawsze wyświetla liczby „po angielsku”, co w Polsce wygląda dość nienaturalnie (czasami można użyć metody toLocaleString(), ale jej możliwości są ograniczone).

Korzystanie z ustawień regionalnych procentuje przy rozpoznawaniu liczb w łańcuchach, np. w polach formularzy. JS za punkt dziesiętny uznaje kropkę, więc próba przetworzenia na liczbę łańcucha 6,54 zakończy się wynikiem 6. VBScript rozpozna to w Polsce prawidłowo — jako liczbę 6,54. Podobnie, łańcuch 20 000 zostanie błędnie odczytany przez JS — jako liczba 20, podczas gdy VBS przetworzy go poprawnie na liczbę 20000 — bo „wie”, że w Polsce używamy czasem spacji do rozdzielania grup cyfr (ale spacja „nie przejdzie” w USA, gdzie w tej roli używają przecinka…). VBS potrafi nawet rozpoznać (i zignorować) w łańcuchu symbol waluty właściwy dla danego kraju np. znak $ w USA czy skrót w Polsce. To wszystko upraszcza skrypty i chroni przed problemami.

VBS możemy przełączyć na ustawienia zgodne z normami wybranego kraju, a nawet robić to wielokrotnie na tej samej stronie — np. aby wyświetlić te same informacje w kilku językach. Warunkiem jest obecność w systemie operacyjnym niezbędnych danych. W polskich wersjach Windows 95 i 98 nie ma problemu z Europą (także wschodnią) i ważniejszymi państwami świata. Uwaga: starsze komputery wyświetlają stare waluty państw europejskich!

W sumie, w zakresie dat i ustawień regionalnych, VBS oferuje i więcej, i przede wszystkim łatwiej niż JS.

Pułapki kalendarza

VBScript operuje na czasie lokalnym strefowym, a zakres dopuszczalnych dat obejmuje lata od 100 do 9999. JavaScript ma dodatkowo dostęp do czasu uniwersalnego i radzi sobie z setkami tysięcy lat w przeszłość i w przyszłość. Choć obliczenia historyczne są w tej sytuacji kuszące (w jakim dniu tygodnia odbyła się bitwa pod Grunwaldem?), wyniki sprzed XVI wieku nie będą prawdziwe.

Obydwa języki dokonują obliczeń według kalendarza gregoriańskiego, obowiązującego w Polsce od 15 października 1582 r. Ponieważ w wielu państwach przyjęto ten kalendarz później, nie ma jednej daty, od której obliczenia są poprawne. Np. dla Niemiec (całych) będzie to 1 marca 1700; dla Anglii i kolonii (w tym USA) 14 września 1752; dla Rosji 14 lutego 1918 itd. Obliczenia dla dat wcześniejszych będą obarczone błędem minimum 10 dni — tym większym, im dalej w przeszłość będziemy się cofać. Średniowieczne daty musimy więc liczyć „ręcznie” zgodnie z kalendarzem używanym w danym okresie na danym obszarze (w Europie w większości przypadków będzie to kalendarz juliański). Operacje na datach sprzed ok. IV w. n.e. w ogóle tracą sens, wobec zanikania znanych nam jednostek czasu (np. współczesnego tygodnia) i dość przypadkowych korekt wprowadzanych w ówczesnych kalendarzach.

Innego rodzaju błędy wystąpią dla dat przyszłych. Kalendarz gregoriański nie jest idealny, i już przed rokiem 5000 różnica między datą wyliczoną, a faktyczną, wyniesie jeden dzień. A to wystarczy, by obliczony dzień tygodnia był w rzeczywistości inny (zakładając, że nasi potomkowie będą korygowali błąd na bieżąco, a pewnie będą). Jak widać, bezpiecznie możemy poruszać się ok. 500 lat w przeszłość i 2-3 tys. lat w przyszłość. Kalendarz obejmujący 10 tysięcy lat (w VBS), czy setki tysięcy (w JS), to w dużym stopniu fikcja.

Warto też dodać, że w obu językach formatowanie daty długiej działa „w tył” tylko do roku 1601. Przy datach wcześniejszych, JS przechodzi samoczynnie na format daty krótkiej, a VBS wywołuje błąd. Wyświetlanie daty krótkiej nie ma ograniczeń ani w JS, ani w VBS (chodzi o samo wyświetlanie, a nie kwestię, czy ta data jest prawdziwa).

Szybkość

JavaScript jest wyraźnie szybsza w prostych obliczeniach arytmetycznych. Dodawanie, odejmowanie, mnożenie i dzielenie wykonuje o ok. 40% szybciej niż VBS. Także o ok. 40% szybciej sprawdza proste warunki. Z kolei przy bardziej skomplikowanych obliczeniach, to VBS jest górą — potęgowanie, pierwiastkowanie i obliczenia trygonometryczne są tu o ok. 30% szybsze niż w JS. Niestety, mniejsza liczba dostępnych funkcji trygonometrycznych wymusza większą ilość obliczeń, co może zrównoważyć zysk na prędkości. VBS szybciej wykonuje też pętle (same pętle, bez innych instrukcji) — przewaga nad JS wynosi tu ok. 40%.

Przy operacjach na łańcuchach wyniki zależą od użytej funkcji. Ogólnie, JS jest minimalnie szybsza, choć są działania, w których jej przewaga może być aż dwukrotna — np. zmiana wielkości liter w łańcuchu. Najczęściej wykonywana czynność — wyszukiwanie ciągów w stosunkowo krótkich łańcuchach (z ewentualną zamianą), zabiera obu językom niemal tyle samo czasu. Przewaga JS powoli rośnie wraz z długością przeszukiwanego łańcucha — gdy ma on pół miliona znaków (ok. 250 stron maszynopisu), JS jest już pięciokrotnie szybsza. W liczbach bezwzględnych to jednak wciąż tylko ułamki sekund. Nawet na starym komputerze z zegarem 300 MHz, wolniejszy VBS przeszuka 0,5 mln znaków w 0,05 sekundy.

Odwołania do elementów strony zajmują obu językom tyle samo czasu — jeśli korzystamy z odwołań skróconych (np. guzik dla obiektu o identyfikatorze ID="guzik"). Gdy korzystamy z odwołań pełnych (np. window.document.all("guzik") lub metoda getElementById()), obydwa języki wyraźnie zwalniają, przy czym znów pojawia się przewaga JS. Przy pełnych odwołaniach JS zwalnia (średnio) ok. dwukrotnie, VBS — trzykrotnie. (Więcej informacji o odwołaniach w artykule „Przyspieszanie skryptów”).

W praktycznych zastosowaniach oba języki można uznać za tak samo szybkie, z lekkim wskazaniem na JS — choć różnicę zauważymy dopiero po wykonaniu tysięcy instrukcji.

Pułapka zaokrągleń

Zarówno JS, jak i VBS nie dokonują obliczeń w arytmetyce dziesiętnej, co skutkuje zaokrągleniami mogącymi być źródłem problemów. Przy czym JS częściej prezentuje błędny wynik wprost, podczas gdy w VBS pozornie wszystko jest w porządku (ale tylko pozornie!). Oto przykład:

<DIV>Oblicz 1,1-1. Czy jest równe 0,1?</DIV>
<DIV LANGUAGE="JScript" ONCLICK="x=1.1-1; b=(x==0.1); this.innerText=x+' '+b">Oblicz JS</DIV>
<DIV LANGUAGE="VBScript" ONCLICK="x=1.1-1: b=(x=0.1): Me.innerText=x&' '&b">Oblicz VBS</DIV>

Po kliknięciu odpowiedniego napisu, oba języki wykonają proste odejmowanie 1,1 minus 1. Wyświetlą wynik i sprawdzą, czy rzeczywiście jest on równy 0,1 (co wydawałoby się oczywiste). JS od razu zaskoczy ilością zer, VBS niby pokaże wynik prawidłowy, ale… przy porównaniu z liczbą 0,1 oba języki wykażą fałsz. Wynik odejmowania nie jest równy 0,1 (co wynika z wewnętrznych zaokrągleń), a VBS tylko „oszukał” nas wyświetlając przybliżoną wartość. Choć błąd jest znikomo mały — dopiero na 17. miejscu po przecinku — to jednak istnieje, i gdyby od takiego porównania zależało wykonanie dalszych instrukcji, w obu przypadkach nie byłyby one wywołane.

Odporność na (nasze!) błędy

VBScript jest nieco bardziej odporny na błędy w konstrukcji skryptu — częściej „jakoś” radzi sobie z nieprawidłowymi danymi (patrz rozdział „Inna filozofia”). W praktyce to bardziej wada niż zaleta. Zwykle lepiej otrzymać komunikat błędu, niż mieć skrypt tylko pozornie funkcjonujący poprawnie, a w rzeczywistości np. zamieniający liczbę na łańcuch.

Gdy mamy już do czynienia z błędem, komunikaty wyświetlane przez VBS mogą być mniej czytelne, szczególnie dla początkujących. Oto przykład błędnego kodu („zapomniałem” w nim o wywołaniu Call):

<DIV LANGUAGE="VBScript" ONCLICK="MsgBox('Dziękuję', 64)">Kliknij VBS</DIV>

VBScript poinformuje:  W wywołaniach procedur Sub nie można używać obiektów nadrzędnych . Trudno domyślić się o co chodzi, bo pozornie nie ma tu żadnej procedury Sub… Na szczęście tak niejasne komunikaty zdarzają się rzadko.

Z drugiej strony, VBS posiada potężną broń w walce z błędami — instrukcję Option Explicit. Jej użycie blokuje automatyczne tworzenie zmiennych, co likwiduje sytuacje, w których skrypt (zwykle na skutek naszego niedopatrzenia) sam tworzy potrzebne mu zmienne, nie zawsze będące tym, czego oczekujemy. W JS nie ma takiej blokady, co zwiększa ryzyko problemów, szczególnie w rozbudowanych skryptach (patrz też artykuł: „Wyszukiwanie błędów w skryptach”).

Warto zauważyć, że niektóre działania mogą być błędne w jednym języku, a dopuszczalne w drugim. Przykładowo, JS bez protestu wykona dzielenie przez zero — zwracając wartość Infinity, a nawet wyciągnie pierwiastek kwadratowy z liczby ujemnej — zwracając wartość NaN (Not a Number). W VBS obie te operacje zakończą się komunikatem błędu.

VBScript i JScript (microsoftowa odmiana JavaScriptu) mogą elastycznie reagować na błędy — przechwytywać je i funkcjonować dalej wg naszych wytycznych. Możemy więc kierować skryptem zależnie od rodzaju błędu, jaki w nim wystąpił. Nie ma to większego zastosowania na stronach www, ale przydaje się przy pracy off-line np. w aplikacjach HTA. Choć nie są to funkcje zawarte w standardowym JavaScripcie, Explorer udostępnia je również w skryptach opisanych wprost jako JavaScript.

Na stronie www

Na stronach www to JavaScript jest standardem obsługiwanym przez wszystkie przeglądarki. W serwisach mających charakter ogólny („dla wszystkich”) jest to więc wybór bezdyskusyjny. Znajomość JavaScriptu pozwoli też zrozumieć działanie cudzych stron, w większości automatyzowanych właśnie tym językiem.

Jako bardziej popularny, JS uznawany jest przez Explorera za język domyślny — zarówno w wydzielonych skryptach (znacznik SCRIPT), jak i w skryptach „inline” (definiujących obsługę zdarzeń). Jeśli nie opiszemy kodu atrybutami TYPE i (lub) LANGUAGE, użyty zostanie interpreter JScriptu.

Sytuacja przestaje być oczywista, gdy korzystamy z rozwiązań dostępnych tylko w Explorerze — szerokiej gamy obiektów, właściwości, zdarzeń. Wtedy i z językiem nie musimy się ograniczać. Może nawet lepiej użyć innego niż JavaScript (choćby skryptów opisanych wprost jako JScript), bo zwiększy to szansę, że nasz „program” nie uruchomi się w innych przeglądarkach — a zawsze jest to lepsze niż działanie błędne. Podobnie przy tworzeniu aplikacji HTA. Ponieważ bazują one na Explorerze, każdy z rozumianych przez niego języków będzie dobry. (Więcej informacji o HTA w artykule „Internet Explorer off-line, czyli aplikacje w HTML-u”).

Aby przełączyć język domyślny na VBScript, wystarczy, by prawidłowo opisany skrypt VBS pojawił się na stronie jako pierwszy (najlepiej w sekcji HEAD). Explorer przyjmie wówczas, że właśnie ten język należy uznać za podstawowy dla wszystkich nieopisanych skryptów i instrukcji występujących na stronie. Analogicznie, gdy pierwszy pojawi się skrypt opisany jako JavaScript, to JS zostanie wybrany na język domyślny. Drugi skrypt na stronie, jeśli będzie w języku innym niż pierwszy, nie zmieni już ustawień domyślnych.

Można korzystać jednocześnie z VBS i JS — choć ogólnie nie jest to zalecane i wymaga uwagi, by skrypty nie przeszkadzały sobie wzajemnie. W takiej sytuacji należy opisać każdy skrypt atrybutem LANGUAGE, aby nie doszło do użycia błędnego interpretera. Np.:

<DIV LANGUAGE="JScript" ONCLICK="window.alert('Dziękuję')">Kliknij JS</DIV>
<DIV LANGUAGE="VBScript" ONCLICK="Call MsgBox('Dziękuję', 64)">Kliknij VBS</DIV>

W tym przypadku atrybuty LANGUAGE określają język obowiązujący w danym elemencie DIV i wskazują, którego interpretera użyć do odczytania instrukcji obsługujących zdarzenia. Brak atrybutu LANGUAGE spowoduje przyjęcie języka domyślnego, co w jednym z powyższych przypadków na pewno okaże się błędne.

Poza stroną www

Mimo wielkiej popularności w Sieci, JavaScript jest w praktyce językiem jednofunkcyjnym — służącym do automatyzacji stron www (choć jego microsoftową odmianę JScript można stosować szerzej). Tymczasem Basic znajdziemy we wszystkich ważniejszych produktach Microsoftu. Częścią systemu DOS jest darmowy QBASIC („dziadek” VBScriptu), którym napiszemy zupełnie przyzwoity program (i jest to niezła metoda na ożywienie starego komputera). Komercyjna, choć już nie sprzedawana, wersja QUICK BASIC pozwala na stworzenie samodzielnego, DOS-owego programu exe. Samodzielną, okienkową aplikację napiszemy w Visual Basicu (także komercyjny). VBScriptem zautomatyzujemy stronę www, serwer (ASP), system operacyjny Windows (WSH), napiszemy własną aplikację HTA. Również sztandarowe programy Microsoftu są „automatyzowalne” Basicem. Zdarzają się też programy freeware, które możemy rozbudowywać tworząc własne funkcje przy pomocy skryptów (np. program do porządkowania grafik MyAlbum). Znajomość Basica pozwala więc łatwo opanować różne środowiska — zarówno w Sieci, jak i w swoim komputerze. Rezygnując z technologii Microsoftu, musimy uczyć się różnych języków do różnych zastosowań.

Inna filozofia

Na koniec różnica teoretyczna, choć o fundamentalnym znaczeniu. Filozofie obu języków całkowicie się różnią.

JavaScript, wywodząca się z profesjonalnego języka C, operuje na „obiektach”. Niemal wszystko jest tu obiektem — liczba, data, tablica, łańcuch. Anna Kowalska to nie tylko trzynaście znaków — to obiekt String posiadający, oprócz zawartości, także kilka właściwości, m.in. długość. Aby poznać długość łańcucha, wystarczy odczytać właściwość length tego obiektu:

dlugosc = "Anna Kowalska".length

Z obiektem powiązane są metody, czyli operacje, które możemy na obiekcie wykonać. Aby zmienić wszystkie litery łańcucha na duże, wywołujemy metodę toUpperCase() tego obiektu:

wynik = "Anna Kowalska".toUpperCase()

Struktura obiektowa jest bardzo elastyczna. Możemy tworzyć własne obiekty o dziwnych właściwościach, lub dodawać nowe właściwości do obiektów standardowych. Możemy np. utworzyć obiekt Osoba przechowujący w kolejnych właściwościach: imię, nazwisko, płeć, wzrost, adres, rok urodzenia i cokolwiek, co jest nam potrzebne. I wszystkie te informacje będą mieściły się w jednej „zmiennej” — w jednym obiekcie.

Organizacja VBScriptu jest dużo prostsza. Obiektów jest tu mało, a łańcuchy, daty, liczby, tablice, to zwykłe zbiory znaków bez dodatkowych właściwości. Na danych operują funkcje — wbudowane w język lub napisane samodzielnie. Przykładowo, by poznać długość łańcucha Anna Kowalska używamy funkcji Len(), która „dokonuje pomiaru” i zwraca wynik:

dlugosc = Len("Anna Kowalska")

By zmienić wszystkie litery w łańcuchu na duże, korzystamy z funkcji UCase():

wynik = UCase("Anna Kowalska")

Ponieważ w VBS łańcuch nie jest obiektem, nie można nadać mu (lub odczytać z niego) żadnych właściwości. Gdybyśmy chcieli zapisać gdzieś adres Anny, jedynym wyjściem byłoby użycie nowej zmiennej lub tablicy.

Podsumowując. W JavaScripcie odwołujemy się do obiektu, po czym odczytujemy jego właściwość lub wywołujemy metodę. W VBScripcie wywołujemy funkcję, której podajemy, jako argument, dane do przetworzenia. To zasadnicza różnica, choć pozornie sprowadza się tylko do „odwrotnego” pisania kodu.

Rozważmy np. prosty błąd. Co się stanie, gdy w JS wywołamy metodę, której dany obiekt „nie ma”? Przykładowo:

x = 123.456;
wynik = x.toUpperCase();

Zmienna x nie jest obiektem-łańcuchem, nie posiada więc „w swoim katalogu” metody toUpperCase(). Wystąpi błąd.

W VBS efekt zależy od tolerancji użytej funkcji na podawane jej nietypowe dane. Np.:

x = 123.456
wynik = UCase(x)

Tu nie otrzymamy błędu. Funkcja potraktuje podaną jej liczbę jak łańcuch o treści 123,456 i zmieni jego znaki na „duże”. A że w przypadku cyfr nie ma żadnej różnicy, otrzymamy w wyniku łańcuch o treści: 123,456 (uwaga: zgodnie z ustawieniami regionalnymi mojego komputera, kropkę zastąpił przecinek).

Jak widać, pozornie teoretyczna różnica „filozofii” może mieć także znaczenie praktyczne.

Uwaga: obiektowej natury JavaScriptu i „nieobiektowej” VBScriptu, nie należy mylić z obiektową strukturą całego dokumentu, jakim jest strona www. Każdy znacznik HTML jest obiektem o szeregu właściwościach, którymi mogą manipulować obydwa języki. Przy czym JS będzie traktowała odczytane wartości jak kolejne obiekty, a VBS — jak zwykłe zbiory znaków lub cyfry do przetworzenia. Przykładowo, odczytany i podstawiony pod zmienną kolor elementu: red to dla JS obiekt-łańcuch, a dla VBS prosty ciąg trzech znaków.

Który lepszy?

Na to pytanie nie ma odpowiedzi. Osobiście rozpocząłem przygodę z DHTML-em od JavaScriptu — bo najpopularniejszy. Z czasem, gdy odkryłem bogactwo funkcji Internet Explorera, przeszedłem na JScript — bo lepiej zintegrowany z Explorerem i z systemem Windows. A wreszcie zauroczyła mnie prostota, funkcjonalność i uniwersalność VBScriptu. Za amatorski ideał uznałbym dziś VBS wzbogacony o funkcje, których mu brakuje, będący do tego uznanym w świecie standardem. Niestety, taki język nie istnieje…

Paweł Rajewski

 
——————————
Pisane i testowane: Win95PL OSR2.1, Win98SE PL, IE5.5PL, fc 300 MHz
Copyright © 2005-2006 Paweł Rajewski