Skrypt w JS a podobny kod w C

Witam, pytanie zapewne trywialne ale jednak. Z czego wynika różnica, mając taki skrypt w JS:
p id=“demo"
var text = " “;
var i;
for(i=1;i<10;i+=2)
{
text = i +br;
document.getElementById(“demo”).innerHTML = text;
}
Do poprawnego działania muszę zastosować text += i; a majac podobna pętle for w C nie muszę stosować x+=i żeby wynik był poprawny.
int i,x;
for (i = 1;i < 10;i += 2)
{
x=i;
printf(”%d\n”,i);
}
Wynika to tylko z różnicy w języku i różnic w zastosowaniu tych języków ? Chodzi mi o różnice w mechanizmie działania tych kodów. I ostatnie pytanie dlaczego
for(i=1;i<10;i+=2)
{
text += i
}
document.getElementById(“demo”).innerHTML = text;
też zadziała i wyniki pojawia się prawidłowo mimo że ostatnia linijka jest poza pętlą for.

Różnice w tych programach są zasadnicze, mimo podobnych pętli.
Otóż w JS w pierwszym przykładzie masz 5 razy przypisany napis do innerHTML, ale widzisz i tak tylko jego ostatnią wartość, bo kod wykonuje się błyskawicznie i nie masz możliwości zobaczyć etapów pośrednich - to też jest odpowiedź na ostatnie pytanie.

W C zaś używasz całkiem innej funkcji, która wypisuje na ekran (za każdym razem/wywołaniem) jedną liczbę (i znak przejścia do nowego wiersza) - bo tak działa funkcja printf() - w JS musiałbyś użyć podobnej funkcji/konstrukcji document.writeln(i); (lub document.getElementById("demo").writeln(i);)

Czyli - podsumowując - w JS musisz składać kolejne wartości i dopiero na końcu łącznie przypisać do obiektu innerHTML, a w C wypisujesz je po kawałku, choć tak samo mógłbyś ją wypisać jako całość (po “scaleniu” w pętli) jednorazowo.

Dzięki za odpowiedź :slight_smile:

Uściśliłbym, że w wersji JS nie zobaczysz “etapów pośrednich” gdyż widok odświeżany jest po wykonaniu całego skryptu, a nie w jego trakcie.

Z tym bym się nie zgodził - widok strony zmienia się dynamicznie w trakcie działania skryptu JS i tylko dlatego, że zmiany są błyskawiczne, nie da się ich zauważyć - ale jakby dać pętlę opóźniającą, albo zwykły alert(“przerwa”), to będzie można zobaczyć te zmiany.

Sprawdziłem to. Tak faktycznie dzieje się pod Firefoxem. Natomiast w Chrome nie. Ale tylko jeśli zatrzymamy skrypt przy pomocy alert(). To jest kwestia interpretacji tego polecenia przez FF. Skrypt bez alert nie odświeża widoku do czasu zakończenia wykonywania.

Stąd różne triki np. z setTimeout.

Być może jakieś przeglądarki (np. Chrome) w wyniku daleko idących optymalizacji nie wyświetlają stanu strony HTML na bieżąco, po każdorazowej modyfikacji DOM, ale po to został stworzony JS, by manipulować na treści strony. I być może w tym przypadku treść strony się nie aktualizuje (optymalizator wie, że dany element za chwilę znów będzie modyfikowany, więc go jeszcze nie wyświetla), ale ogólne stwierdzenie “widok odświeżany jest po wykonaniu całego skryptu, a nie w jego trakcie” jest oczywiście błędne (biorąc pod uwagę wszystkie możliwe przypadki manipulacji DOM w JS).
Ale nie o to w tym wątku chodzi, więc to tylko poboczne uwagi.

PS. W 99% przypadków korzystam z Firefoksa (nie przepadam za Chrome), bo FF stara się dobrze trzymać oficjalnych standardów W3C, a z Chrome to już różnie bywało (kładli nacisk na wprowadzanie swoich poprawek/nowości oraz na szybkość działania).

Panie kolego. Rozmawiamy o podstawach podstaw dlatego ja raczej sugeruję zapoznać się z nimi w tym momencie niż wprowadzać w błąd początkujących programistów. Zaoszczędzimy im tym samym wielu irytujących niespodzianek.

Przeglądarka parsując dokument i napotykając na skrypt wstrzymuje renderowanie strony do czasu wykonania skryptu do samego końca. W rzeczywistości jest dokładnie odwrotnie w kwestiach optymalizacji, bo to FF próbuje zrównoleglać wątki w celu przyspieszenia ich wykonania.

Jeśli nie chcemy aby przeglądarka wstrzymała parsowanie dokumentu możemy użyć argumentu DEFER, opisanego w dokumentacji HTML4

When set, this boolean attribute provides a hint to the user agent that the script is not going to generate any document content (e.g., no “document.write” in javascript) and thus, the user agent can continue parsing and rendering.
https://www.w3.org/TR/html401/interact/scripts.html#adef-defer

Manipulacja DOM za pomocą JS i interaktywność stron leży w zupełnie innym miejscu i wbrew pozorom powyższemu nie przeczy. Jak słusznie zauważyłeś, małe skrypty wykonywane są bardzo szybko i wyzwalane np. w reakcji na aktywność użytkownika, tak, że nie zauważa on czasu jaki upłynął od jego rozpoczęcia do zakończenia.

A jeśli nadal zamierzasz twierdzić co innego to poproszę o wskazanie która dokumentacja o tym wspomina, bo potoczne przekonania bywają mylne.

Lektura dodatkowa:
https://www.html5rocks.com/en/tutorials/internals/howbrowserswork/#The_order_of_processing_scripts_and_style_sheets