Miłosz Orzeł

Istnieje kilka powodów, dla których nie powinno się umieszczać aplikacji ASP.NET w środowisku produkcyjnym z ustawieniem <compilation debug=”true”/> (czytaj…). Wbrew pozorom prędkość wykonywania instrukcji kodu po stronie serwera nie stanowi bardzo istotnego problemu. Inaczej jednak wygląda sytuacja po stronie klienta - gdy nasza aplikacja korzysta z javascriptowej biblioteki Microsoft AJAX Framework. Wówczas ustawienie Release/Debug* ma ogromny wpływ na szybkość wykonywania kodu aplikacji!

Doskonale widać to na przykładzie poniższej pętli, korzystającej z funkcji startsWith dostarczanej wraz z częścią kliencką pakietu ASP.NET AJAX.

for (var i = 0; i < 10000; i++) {
    'xxx'.startsWith('abc');
}

Pętla ta wykonuje się ok. 5 razy wolniej gdy używana jest wersja debug biblioteki JavaScript!  Czasy gdy JS był używany do wyświetlania alertów dawno minęły. Teraz gdy aplikacje webowe mogą posiadać tysiące linii kodu wykonywanego po stronie klienta, tak wielka różnica wydajnościowa może być sporym problemem (zwłaszcza gdy przeglądarka zgłosi komunikat o wolnym działaniu skryptu na stronie).

Skąd bierze się różnica w szybkości działania? Wynika ona z tego, że kod JavaScript opracowany przez Microsoft dla potrzeb tworzenia aplikacji ajaxowych, dostarczany jest w dwóch wersjach. Wersja, która jest wykorzystywana w trybie Debug, zawiera bloki kodu znacznie ułatwiające rozwijanie aplikacji – np. sprawdzają one ilość i typy parametrów podawanych w wywołaniu funkcji. Wersja dostarczana do przeglądarki w trybie Release nie zawiera tego rodzaju udogodnień – przez co skrypt wykonuje znacznie mniej pracy i działa szybciej.

Oto kod wykonywany przy wywołaniu metody startsWith w trybie Release (w celu ograniczenia wielkości plików pobieranych przez przeglądarkę kod nie zawiera komentarzy i zbędnych białych znaków):

String.prototype.startsWith=function(a){return this.substr(0,a.length)===a};

A to kod z trybu Debug:

String.prototype.startsWith = function String$startsWith(prefix) {
    /// <summary locid="M:J#String.startsWith" />
    /// <param name="prefix"></param>
    /// <returns type="Boolean"></returns>
    var e = Function._validateParams(arguments, [{
        name: "prefix",
        type: String
    }]);

    if (e) throw e;

    return (this.substr(0, prefix.length) === prefix);
}

Widzisz wywołanie funkcji _validateParams? Korzysta ona z kilku innych funkcji – łącznie kod walidujący parametry ma 155 linii (w wersji 3.5.30729.196 pliku MicrosoftAjax.debug.js).

Function._validateParams = function Function$_validateParams(params, expectedParams) {
    var e;
    e = Function._validateParameterCount(params, expectedParams);

    if (e) {
        e.popStackFrame();
        return e;
    }

    for (var i = 0; i < params.length; i++) {
        var expectedParam = expectedParams[Math.min(i, expectedParams.length - 1)];
        var paramName = expectedParam.name;

        if (expectedParam.parameterArray) {
            paramName += "[" + (i - expectedParams.length + 1) + "]";
        }

        e = Function._validateParameter(params[i], expectedParam, paramName);

        if (e) {
            e.popStackFrame();

            return e;
        }
    }

    return null;

Podczas korzystania z kontrolki CheckBox i ustawiania jej po stronie klienta jako nieaktywnej, natchnąłem się na problem, który (przeoczony) może sporo namieszać w pracy aplikacji. Otóż jeśli CheckBox jest zaznaczony i zablokujesz go ustawiając właściwość disabled w JavaScript to po postbacku zobaczysz, że właściwość Checked == false!

Ten fragment JS ustawia właściwość disabled (CheckBox staje się szary i przestaje reagować na akcje użytkownika):

document.getElementById('<%= CheckBox1.ClientID %>').disabled = true;

Po "powrocie na serwer" kontrolka CheckBox nie będzie zaznaczona. Dzieje się tak dlatego, że przeglądarka nie wysyła w requescie informacji o polu input type="checkbox" z atrybutem disabled.

Testowałem w IE6/8 i FF2 na .NET 2.0/3.5.

Dzięki funkcji parseInt() języka JavaScript w łatwy sposób można dokonać konwersji łańcucha tekstowego na liczbę całkowitą. Niestety korzystanie z niej w celu pobrania wartości wpisanej przez użytkownika niesie za sobą pewne zagrożenie. Przeanalizuj poniższy fragment kodu:

function dodaj() {
    var txt = document.getElementById('TextBox1');
    var a = parseInt(txt.value);
    return a + 10;
}

Co stanie się gdy użytkownik wprowadzi do okienka 10? Oczywiście funkcja zwróci wartość 20. Co jednak wydarzy się gdy ktoś wpisze do okienka ciąg 010? Otóż w rezultacie otrzymamy 18! Stało się tak dlatego, że funkcja parseInt() wywoływana tylko z jednym parametrem zinterpretowała tekst wpisany przez usera aplikacji jako wartość podaną w systemie ósemkowym (napis postaci 0x10 został by odczytany jako szesnastkowy). Możesz być niemal pewien, iż użytkownik programu zakładał, że wprowadzenie zera przed liczbę nie powinno mieć wpływu na wynik. A jednak ma! Co zrobić by program działał bardziej intuicyjnie? Wystarczy dodać w wywołaniu funkcji parseInt() drugi parametr określający podstawę wykorzystywanego systemu liczbowego. Należy więc zastosować taki kod:

function dodaj2() {
    var txt = document.getElementById('TextBox1');
    var a = parseInt(txt.value, 10);
    return a + 10;
}

Jeżeli masz coś wspólnego z aplikacjami webowymi to pewnie nerwowo reagujesz na widok IE6. Oto powód by znielubić tą przestarzałą (niestety wciąż popularną) wersję Internet Explorera jeszcze bardziej.

Załóżmy, że masz na formie kontrolki TextBox i Button. Zależy Ci na tym by zablokować przycisk gdy pole tekstowe jest puste. Piszesz więc taką prostą funkcję JavaScript:

function blokuj() {
    if (document.getElementById('TextBox1').value == '') {
        document.getElementById('Button1').disabled = true;
    }
}

i podpinasz ją do zdarzenia onblur (zdarzenie ma miejsce gdy kontrolka traci focus) TextBoxa... Pozornie wszystko działa jak należy - gdy pozostawisz pole tekstowe puste i przeskoczysz klawiszem Tab na inną kontrolkę przycisk zostanie zablokowany. Co jednak stanie się gdy trzymając kursor tekstowy w pustym okienku klikniesz bezpośrednio w przycisk? IE6 zawiesi się do momentu, aż przełączysz się na okno innego programu. By temu zaradzić możesz skorzystać ze zdarzenia onfocusout zamiast onblur jednak takie rozwiązanie nie zadziała poza IE. Można także zamiast kontolki Button użyć ImageButton albo bawić się ukrytym divem, z właściwością Z-index wyższą niż przycisk...