# Java vs. JavaScript



## Raabun (13. April 2004)

Hallo Leute,
ich habe da ein Problem. Ich habe ein Frontend für eine Datenbank geschrieben.
PHP und JavaSript. Nun es ist wegen der vielen Berechnungen und Abfrage recht umfangreich geworden (Ca. 3000 Zeilen JavaSript-Code) und nun ist es mir zu langsam.
Große Frage: Würde es schneller, wenn ich den JavaSript-Code durch Java-Appletts ersetze?
Oder gibt es einen anderen Weg? (Bitte diese Frage ignorieren, falls sie Off-Topic ist   )
Raabun


----------



## Christian Fein (13. April 2004)

> _Original geschrieben von Raabun _
> *Hallo Leute,
> ich habe da ein Problem. Ich habe ein Frontend für eine Datenbank geschrieben.
> PHP und JavaSript. Nun es ist wegen der vielen Berechnungen und Abfrage recht umfangreich geworden (Ca. 3000 Zeilen JavaSript-Code) und nun ist es mir zu langsam.
> ...



Ich würde Java-Appletts ignorieren, sie sind nicht mehr Zeitgemäss.

Schau dir Java - WebStart an und programmiere eine normale Applikation die sich mit WebStart aus dem Browser heraus aufrufen lässt.


----------



## Raabun (13. April 2004)

Danke für die schnelle Antwort,
was heißt nicht mehr zeitgemäß?
Und was ist mit dem Rest meiner Aplikation, sie besteht, aus ca. 20 Bildern und nur eins ist mir zulangsam. Würden Appletts einen Geschwindigkeitsvorteil bringen?
Ich bin leider was die Webprogrammierung und Java angeht ein Newbie, ich komme aus der C und Assembler Ecke  
Raabun


----------



## Christian Fein (13. April 2004)

> _Original geschrieben von Raabun _
> *Danke für die schnelle Antwort,
> was heißt nicht mehr zeitgemäß?
> Und was ist mit dem Rest meiner Aplikation, sie besteht, aus ca. 20 Bildern und nur eins ist mir zulangsam. Würden Appletts einen Geschwindigkeitsvorteil bringen?
> ...



Nicht mehr Zeitgemäss heisst, das Applets zuviele Schwierigkeiten bringen.

Im übrigen lassen sich so ziemlich alle Dinge im Web auf serverseitige Sprachen legen. JavaScript ist fast gar nicht mehr nötig.


----------



## oglimmer (13. April 2004)

Kleine Anmerkung zu JavaScript und serverseitigen Sprachen.

Man kann zwar fast jedes JavaScript durch eine serverseitige Lösung ersetzen, ich finde jedoch dass man das nicht sollte.

Ich bin eher der gegenteiligen Meinung, JavaScript sollte viel mehr eingesetzt werden, denn die sehr lästigen Request/Response Zeiten entfallen.

Man stelle sich mal ein Forum vor, dass beim drücken auf "Antworten" keine neue Seite laden muss, sondern einfach ein Edit-Bereich in die aktuelle Seite einfügt.

Und weil ich ein wehementer Verfechter von JavaScript bin, habe ich mal eine Bookmark-Verwaltung prototypisch realisiert.

Online-Bookmarks-Verwaltung


----------



## Dario Linsky (13. April 2004)

> Man stelle sich mal ein Forum vor, dass beim drücken auf "Antworten" keine neue Seite laden muss, sondern einfach ein Edit-Bereich in die aktuelle Seite einfügt.



JavaScript ist IMHO eher was für die kleineren Effekt-Spielereien, Ebenen aus- und einblenden und so weiter; nichts für interaktive Webanwendungen. In manchen Fällen kann sowas zwar sinnvoll sein, aber wenn die beim Client angezeigten Daten neu vom Server abgerufen werden müssen, ist das nicht mehr so praktisch. Abgesehen davon, dass die Dynamik der Anwendung nachlässt, steigen die Ladezeiten, weil ja nicht nur eine Seite geladen wird, sondern noch ein paar andere, die aber in versteckten Layern liegen. Und damit hast Du den Zeitverlust durch neue Anfragen schon bald wieder raus.
Wenn eine Interaktion zwischen Server und Client ins Spiel kommt (und das ist bei Datenbank-Anwendungen eigentlich ziemlich häufig der Fall), kommt man an serverseitigen Sprachen nicht vorbei.

Was nicht heißen muss, dass man in JSP-Seiten oder Servlets kein JavaScript einfügen kann, und es gibt ja auch serverseitiges JavaScript, aber darum geht's ja nicht.

PS: Außerdem kann man JavaScript nicht wirklich gut debuggen.


----------



## Raabun (14. April 2004)

Hi,
ich habe alle Daten auf dem Client, besser alle Daten ca 200 werden und müssen auf einer einzigen Seite eingegeben werden. Es handelt sich um eine Art Stundenplanerstellung. Auf dem Server befindet sich eine Datenbank mit  den Lehren, ihrer Stundenzahl,Urlaub,Fächer usw. Und auch andere Datenbanken, wie Anzahl der Stunden pro Fach und Klasse.
Die Erstellung des Stundenplans erfolgt auf den Clients (mehrer). Also kann ich kaum serverseitig arbeiten. Die aktuelle Seite hat momentan ca. 1,3MByte Größe.
Ich suche ansich nur einen Rechenknecht für HTML  
Raabun


----------



## oglimmer (14. April 2004)

Hast Du Dir mal meine Bookmark-Verwaltung angesehen?

Ich führe alle Kommunikation mit dem Server in einem (halb-) versteckten Frame durch. Die Argumentation dass man dann also doch auf DB-Zugriff warten muss, ist nur halb richtig. Sicher gilt das für lesende Zugriffe, aber schreibende Zugriffe, kann man im Hintergrund durchführen.

Richtig ist dass heutzugtage JavaScript im überwiegenden Fall für "Spielerei" eingesetzt wird, ich bin aber der Meinung dass hier viel Potential drin ist, das ungenutzt ist.


----------



## Raabun (14. April 2004)

Habe ich gemacht,
aber mein Problem ist NICHT die Anbindung an die Datenbank. Ich lade mir die benötigten Daten beim Laden der Seite....duert lange, ist aber akzeptabel, da ich auf der Seite dann einige Stunden  verbringe.
Das Dumme ist nur nach jeder Eingabe müssen ca. 200 Input-Felder gelesen und deren Inhalt miteinander verechnet werden. Das dauert ohne Ende.
Das Abspeichern der Werte in die Datenbank ist dann wieder easy und auch hier spielt die Zeit keine Rolle.
Also nur meine Rechnerrei in meiner Tabelle  
Raabun


----------



## Andreas Gaisbauer (14. April 2004)

> _Original geschrieben von oglimmer _
> *Richtig ist dass heutzugtage JavaScript im überwiegenden Fall für "Spielerei" eingesetzt wird, ich bin aber der Meinung dass hier viel Potential drin ist, das ungenutzt ist. *


Ganz meine Meinung. JS ist viel mehr als Imagerollover und Form validation - leider gibt es aber relativ wenig "HighLevel JS". Gerade in Verbindung mit XML, Webservices und WDDX hat Javascript einiges zu bieten, was leider nur seltenst genutzt wird. Deine Bookmarkverwaltung gefällt mir - ich hab das gleiche Prinzip (mit dem "onClickEdit") mal für ein relativ umfangreiches DataGrid genutzt 


@Raabun:
3000 Zeilen JS code? Das wüd ich gerne mal anschauen, hast du einen Link, oder ist es nicht für die öffentlichkeit bestimmt?. 3000 Zeilen sind nicht automatisch langsam - Typo3 hat ca 6000 Zeilen JS Code und ist nicht wirklich langsam... Musst du alle Felder auf einmal berechnen (zum Beispiel bei Submit)? Wenn ja, dann schreib dir ein Programm in C (CGI funktioniert wunderbar mit C) - das sollte schneller sein. Wenn du nur "nach und nach" die Berechnungen durchfühst, sollte die Geschwindigkeit kein Problem sein, da du ja nur einen Bruchteil der Funktionen verwendest - es sei denn du hast deinen Code wirklich versaut aufgebaut


----------



## Raabun (15. April 2004)

Moin Andreas,
der  Code ist leider nicht öffentlich., er soll/wird in einem lokalen Netzwerk verwendet.
Ich muß bei jeder Eingabe ca. 200 Felder berechnen und aktualisieren, und nicht nur bei "Submit". Bei jeder Berechnung wird ein Großteil des Scriptes durchlaufen, zum Teil mehrmals, da es sich um Funktionen handelt..
Auf der Seite befinden sich ca 15.000 Felder. Bei jeder Eingabe werden ca. 200 Felder aktualisiert.
Mit "Submit" werden die Daten dann als ca. 600 Datensätze gespeichert. Aber dies geht wunderbar schnell, aber hier ist die Geschwindigkeit ist hier nicht so wichtig, da nur am "Ende" der Arbeit gespeichert wird.
Alle Angaben sin ca. Werte, da die ganze Chose dynamisch aufgebaut ist und sich die Größe jederzeit ändert.

Es stimmt der Code ist teilweise versaut, aber bei weitem nicht total   
Er hat einige Schleifen, die ich optimiert habe, aber mit mäßigem Erfolg. 

Ich habe nun den Verdacht, daß es für JavaSript recht lange dauert einzelne Felder aus der HTML-Datei auszulesen.
Ich bin nun dabei, die ganze dynmische HTML/PHP-Tabelle in ein JavaSript-Array zu schreiben, um so die Lesezugriffe auf die Tabelle zu minimieren.
Gruß
Raabun (Dirk-Uwe)


----------



## Christian Fein (15. April 2004)

> _Original geschrieben von oglimmer _
> *Hast Du Dir mal meine Bookmark-Verwaltung angesehen?
> 
> Ich führe alle Kommunikation mit dem Server in einem (halb-) versteckten Frame durch. Die Argumentation dass man dann also doch auf DB-Zugriff warten muss, ist nur halb richtig. Sicher gilt das für lesende Zugriffe, aber schreibende Zugriffe, kann man im Hintergrund durchführen.
> ...



Ich habe mir die Bookmarkverwaltung angesehen, und genau da kommt einer der
grössten nachteile von JavaScript zum Vorschein.

Unter konqueror funktioniert Sie nicht. Es gibt zu viele Browser die unterschiedlich JavaScript beherrschen.

Mit einer Serverseitigen geschichte kann mann viel mehr machen.
Und mann muss auch nicht 200 Datensätze bei jedem Seitenaufruf neu laden, dazu hat mann die Möglichkeit diese Daten beim Server im Speicher zu halten, und das im Application Scope so das bei jedem Aufruf, egal welcher Session mann diese Daten abrufen kann.
Persistenzierung in ein Datenbank kann mann ebensolang zurückhalten bis wirklich Daten geschrieben werden müssen. Und selbst bei der Persistenzierung in die Datenbank, brauch mann nicht die geänderten Daten neu aus der Datenbank auslesen um diese im Application Scope zu schreiben.
Mann kann auch direkt die Daten im ApplicationScope updaten. Wenn mann sauber Programmiert reicht es für mehrere Stunden nutzung einer Application nur eine Handvoll von Datenbankoperationen durchzuführen.


----------



## Thomas Lindner (15. April 2004)

Ich bin zwar Freund des JavaScriptes und habe mich da mit Mühe reingefuchst (so halb), aber denoch kann ich dem gesagten nur zustimmen:

JavaScript ist und bleibt für  Effekte geeignet, aber sollte keine kompletten Funktionen erstezen.
Ich selber setze mich mittlerweile mit PHP auseinander weil JavaScript an seine Grenzen gestossen ist und in vielen Dingen zu langsam gearbeitet hat.
JavaScript werde ich weiterhin für "kleine Annwendungen" nutzen, aber vermehrt versuchen auf Alternativen auszuweichen.


----------



## Raabun (15. April 2004)

...und welche Alternativen gibt es, nicht zum "malen" sondern zum Rechnen?


----------



## Thomas Lindner (15. April 2004)

> _Original geschrieben von Raabun _
> *...und welche Alternativen gibt es, nicht zum "malen" sondern zum Rechnen? *



Zum Beispiel PHP - auch wenn hier die Berechnung erst Serverseitig erfolgen muss, sollte das kein Problem darstellen.


----------



## Raabun (15. April 2004)

Stimmt, aber für meine Problem nicht der richtige Weg, dazu müßten dann zu viele Daten geschaufelt werden. Der reine Seitenaufbau dauer zur Zeit schon 20sec. (im lokalen Netzwerk und nicht über Modem  )
Ich suche einfach einen "Rechenknecht", der auf meinem Client läuft...


----------



## Christian Fein (15. April 2004)

> _Original geschrieben von Raabun _
> *Stimmt, aber für meine Problem nicht der richtige Weg, dazu müßten dann zu viele Daten geschaufelt werden. Der reine Seitenaufbau dauer zur Zeit schon 20sec. (im lokalen Netzwerk und nicht über Modem  )
> Ich suche einfach einen "Rechenknecht", der auf meinem Client läuft... *



Mhhh wie gesagt, die Seiten sind so schnell wie der Entwickler sie schuff.
Sprich wer komplett auf Caching verzichtet der wird auch lange Antwortzeiten haben.

Mit Caching wird mann auch Seiten die tausend Datensätze lesen müssen auf innerhalb < 1 Sec Laufzeit bringen.


----------



## Raabun (15. April 2004)

...bekommt der Cache mit, wenn sich Daten in der Datenbank geändert haben ?
Mein Programm sollte in gewissen Grenzen schon Multi-User fähig sein. Meine Browser (Opera 7.23, Netscape 7.1 und der IE6) sind aber auch mit allen eingeschalteten Caches zu langsam und arbeitet fehlerhaft.
Nun nocheinmal eine ganz wertfreie Frage:

Gibt es eine Programmiersprache oder Scriptsprache, die schneller als JavaScript ist und auch auf dem Client laufen kann?
Wichtig, nach meiner Erfahrung liegt der Bottleneck in der Verbindung
 JavaSript   -   HTML/PHP

Auf diesem Aspekt ist noch keine Antwort eingegangen  
Aber was nicht ist kann noch werden. 

Noch zur Erklärung:
Es geht nicht um eine "Internet-Seite", sondern um eine Software, mit der gearbeitet wird.
Es werden auf einmal 600 Datensätze geladen. Eine Eingabe in einem der Datensätze beeinflußt gleich 20 Datensätze auf einmal. Diese Änderungen *muß* der User sofort sehen (ohne "Submit" und Neuladen)
Es sollte einwenig wie eine Spread-Sheet-Applikation wirken, aber keine sein.

Gruß
Raabun


----------



## Christian Fein (15. April 2004)

> _Original geschrieben von Raabun _
> *...bekommt der Cache mit, wenn sich Daten in der Datenbank geändert haben ?
> *



Nun wenn du es so programmierst das jedesmal wenn daten geändert werden diese im Cache und in der Datenbank geändert werden, natürlich.
Manche Technologien machen das ganz automatisch (z.b J2EE mit EJB)



> _Original geschrieben von Raabun _
> *
> Mein Programm sollte in gewissen Grenzen schon Multi-User fähig sein. Meine Browser (Opera 7.23, Netscape 7.1 und der IE6) sind aber auch mit allen eingeschalteten Caches zu langsam und arbeitet fehlerhaft.
> Nun nocheinmal eine ganz wertfreie Frage:
> *



Ich rede nicht von dem Browser Cache. Sondern ein selber implementiertes Caching auf dem Server




> _Original geschrieben von Raabun _
> *
> Es geht nicht um eine "Internet-Seite", sondern um eine Software, mit der gearbeitet wird.
> Es werden auf einmal 600 Datensätze geladen. Eine Eingabe in einem der Datensätze beeinflußt gleich 20 Datensätze auf einmal. Diese Änderungen muß der User sofort sehen (ohne "Submit" und Neuladen)
> ...



Dafür schreibe eine Applikation mit einer Programmiersprache deiner Wahl, und keine Browserbasierende geschichte.


----------



## Raabun (15. April 2004)

..würde ich jetzt evtl. auch machen, aber die Browsergeschichte hat auch Vorteile beim "Malen", billige Tools, mehrer Platformen  usw.
Aber ich finde es interessant, daß kaum einer "inhaltliche" Antworten schreibt.
Auf die Bottleneck-Geschichte ist noch keiner eingegangen, noch darauf ob es eine Alternative zu JavaScript gibt, ohne das ganze Projekt umzuschmeißen.
Ich denke, in der Zukunft geht der  Weg zu browsergesteuerten Programmen.

Nun noch eine Frage: Hat hier jemand schon eine solche Applikation geschrieben?

...und noch was: So einfach bekommt man IMHO sonst keine Mehrplatz Software

Es ist einfach schlampige Software und Unwissendheit mir vorzuwerfen, und wißt Ihr was:

* Ihr habt recht!*

....aber dies alles sind keine Antworten auf meine Frage!

Naja....

Raabun


----------



## Christian Fein (15. April 2004)

> _Original geschrieben von Raabun _
> *.
> ...und noch was: So einfach bekommt man IMHO sonst keine Mehrplatz Software
> 
> ...



Dir hat niemand das vorgeworfen.

Und die Frage auf deine Antwort ist, das du die falsche Technologie für dein Vorhaben wählst und das JavaScript dafür nicht geeignet ist.
Und wenn du performance haben willst dein Vorhaben lieber ganz mit einer anderen Technologie durchführst.

Das ist eine sehr genaue und die einzig richtige Antwort auf deine Frage


----------



## Raabun (15. April 2004)

Durch Umgehen des wohl nur von mir jemals bemerkten Bottleneck   ist das Projekt nun um ca. 500% schneller. Klingt toll was, aber von 10 sec auf unter 2 sec. ist doch schon was, und ich bin noch nicht fertig mit der Sache  

Also für alle:

*JavaScript ist schnell, PHP/HTML ist schnell, ABER die Komunikation zwischen beiden Seiten (HTML/JavaSript) ist langsam*

Mich wundert nur das dies hier keiner weiß oder beobachtet hat, oder es ist jedem egal. Denkt daran, wenn Ihr Web-Seiten schreibt, denn nun weiß ich warum mein alter PC (244MHz/PII) bei manchen Seite so endlos braucht....

Gruß Raabun

PS. Ich entwickele NICHT auf dieser alten Krücke, sie steht nur zuhause rum, denn ich mag keine PCs und hänge doch den ganzen Tag davor....


----------



## Christian Fein (15. April 2004)

> _Original geschrieben von Raabun _
> *Durch Umgehen des wohl nur von mir jemals bemerkten Bottleneck   ist das Projekt nun um ca. 500% schneller. Klingt toll was, aber von 10 sec auf unter 2 sec. ist doch schon was, und ich bin noch nicht fertig mit der Sache
> 
> Also für alle:
> ...



Sorry aber JavaScript ist eine Krücke 
Und auch PHP ist kein Geschwindigkeitsknecht.

Das weitere Problem wenn du soviele Datensätze an den Client bugsieren will, ist das wenn er obwohl er nur 1-2 % Der Daten braucht, mit 100% der Daten beliefert werden muss.
Auf dem Server kann mann sowas einschränken, und nur je nachdem was der Client benötigt dieses liefert.


----------



## Raabun (15. April 2004)

Jede Scriptsprache ist eine Krücke, aber denen kann man auch Beine machen 
Nun ich brauche nicht 1-2% der Daten, die ich zum Client schaufele, sondern 100%. Alle Daten werden benötigt
Ich hole mir nur die Daten vom Server, die ich brauche....
Gruß
Raabun


----------



## Andreas Gaisbauer (15. April 2004)

> _Original geschrieben von Christian Fein _
> ch habe mir die Bookmarkverwaltung angesehen, und genau da kommt einer der grössten nachteile von JavaScript zum Vorschein.
> Unter konqueror funktioniert Sie nicht. Es gibt zu viele Browser die unterschiedlich JavaScript beherrschen.



Stimmt - das ist _der_ Nachteil von JS. Aber der zählt nur wenn 
1) man sich seiner Zielplattform nicht bewusst ist
2) man den Code nicht CrossBrowser Kompatibel hält. Man kann sogut wie jedes Javascript auf allen modernen Browsern zum laufen bringen - ist nur die Frage ob man das machen will... Alte Programme wie NS 4.72 kann man auch noch zu einigen Sachen überreden - spar ich mir aber meistens weil eine 100% Unterstützung dieser veralteten Software mehr Nachteile als Vorteile mitsichbringt (CSS Support zum Beispiel).



> Mit einer Serverseitigen geschichte kann mann viel mehr machen.


aber auch viel weniger, das brauch ich dir nicht zu erklären. JS / Serversprachen haben ja nicht das gleiche Einsatzgebiet (meistens). Außerdem kann man Javascript auch Serverseitig verwenden...




> Gibt es eine Programmiersprache oder Scriptsprache, die schneller als JavaScript ist und auch auf dem Client laufen kann?
> Wichtig, nach meiner Erfahrung liegt der Bottleneck in der Verbindung
> JavaSript - HTML/PHP
> 
> Auf diesem Aspekt ist noch keine Antwort eingegangen


Kommt drauf an, wenn du Client = Browser definierst, wirst du wohl oder übel nicht um JS herumkommen. Wenn du Client = Programm das Daten vom Server holt/schreibt definierst, wirst du zum Beispiel mit Python + GTK besser fahren. Den Bottleneck beim Auslesen der Felder kannst du meiner Meinung nach nicht umgehen - wenn die Daten ausgelesen werden müssen, kommst du halt leider nicht drum herum...



> Es geht nicht um eine "Internet-Seite", sondern um eine Software, mit der gearbeitet wird.
> Es werden auf einmal 600 Datensätze geladen. Eine Eingabe in einem der Datensätze beeinflußt gleich 20 Datensätze auf einmal. Diese Änderungen muß der User sofort sehen (ohne "Submit" und Neuladen)
> Es sollte einwenig wie eine Spread-Sheet-Applikation wirken, aber keine sein.


Dann würde ich mir nochmal überlegen ob es über den Browser laufen soll, wenn die Vorlage dies nicht ausdrücklich verlangt.



> Es ist einfach schlampige Software und Unwissendheit mir vorzuwerfen, und wißt


Das hat doch niemand gemacht. Ok, ich fasse nochmal zusammen:

-Bei Browser basierenden Anwendungen mit JS/PHP kommst du um JS nicht rum. Unter IE könntest du noch vbs verwenden, was aber garantiert nicht schneller ist (außerdem könntest du dann alles was du hast wegwerfen)
- Den Bottleneck beim Formularauslesen  wirst du nicht wegbekommen. Es wäre aber evtl interessant wie oft und wie viel gelesen wird - vielleicht kannst du da etwas einsparen
- Vielleicht liegt der Bottleneck wo anderes - Variablen auslesen sollte mestens nicht zu einem solchen Performance Einbruch führen.
- Wenn du nicht auf HTML setzten musst dann Schreib den Client neu. C# oder Java wären meine Vorschläge - dort könntest du u.a. mit echten Datagrids arbeiten und Datenbank Abfragen sind auch kein Problem
- Wenn du keinen Kompletten Client neu schreiben willst, dann schau dir mal das Mozilla Framework an. Damit lassen sich relativ schnell Anwendungen schreiben (auch in C und JS) - somit könntest du die Rechenintensiven Parts in z.B. C auslagen. (http://books.mozdev.org)


----------



## Andreas Gaisbauer (15. April 2004)

> _Original geschrieben von Raabun _
> *Durch Umgehen des wohl nur von mir jemals bemerkten Bottleneck   ist das Projekt nun um ca. 500% schneller. Klingt toll was, aber von 10 sec auf unter 2 sec. ist doch schon was, und ich bin noch nicht fertig mit der Sache
> *


Wo war der Bottleneck genau und wie bist du ihn umgangen?


----------



## Raabun (15. April 2004)

Ich habe mir den Inhalt aller HTML-Input-Felder in ein JavaSript-Feld geholt und muß sie nun, wenn ich mit den Daten arbeite nicht mehr neu holen. Ich muß sie nur wieder in das HTML-Inputfeld schreiben, da ich aber erheblich mehr Felder lesen muß (30 mal Lesen , dann einmal schreiben)
In meiner ersten Version habe ich direkt mit den HTML-Inputs geabeitet
(document.Haupt[z_ende1_str].value  usw) und nun mit einem Feld (g_IniFeld[iii][tag][g_Ende1])
Das half gewaltig
Raabun


----------



## Christian Fein (15. April 2004)

> _Original geschrieben von Andreas Gaisbauer _
> *Stimmt - das ist _der_ Nachteil von JS. Aber der zählt nur wenn
> 2) man den Code nicht CrossBrowser Kompatibel hält. Man kann sogut wie jedes Javascript auf allen modernen Browsern zum laufen bringen - ist nur die Frage ob man das machen will...
> *



Das Problem ist dabei die Entwicklungszeit, die sowas von unproportional in die Höhe schiesst das es nicht mehr Tragbar ist-



> aber auch viel weniger, das brauch ich dir nicht zu erklären. JS / Serversprachen haben ja nicht das gleiche Einsatzgebiet (meistens). Außerdem kann man Javascript auch Serverseitig verwenden...



Ja weiss ich, aber hier geht es eindeutig um JS Clientseitig


----------

