JavaScript JavaScript vs JavaApplet

[SevenTech]

Hallihallo ich habe mal eine allgemeine Frage an die Webprogrammierer, die sich mit JavaScript und Java-Applets auskennen:

Welche Vor- und Nachteile haben beide, wenn man damit Webseiten dynamisieren will? Ganz allgemein eine kleine Gegenüberstellung.

Optimal wäre wenn jemand noch etwas sagen könnte unter folgenden Gesichtspunkt: Wenn man die Absicht hat, damit dynamische Seiten zu erstellen, mit denen man über Internet z.B. technische Anlagen überwachen und z.T. steuern kann - Stichworte: Sicherheit und Nutzerauthentifizierung. Das wäre natürlich noch das Sahnehäubchen aber eine allgemeine Sicht reicht mir auch vollkommen zu.

Mit Java hab ich schonmal ne ganze Weile gearbeitet aber das hatte nix mit Internet oder Online zu tun (alles offline). Java (Applets) mit Online-Kontext und JavaScript hab ich nur vor kurzem mal oberflächlich angekratzt.

Hab zwar jetzt n ganz paar Tage hin- und wieder gegoogelt aber nix gefunden. Ich bin da über jeden Tipp dankbar.

 

[ice-breaker]

Java-Applets sind nicht mehr zeitgemäß.
JavaScript und JavaApplets können keine Anlagen überwachen.

Mehr kann ich dir mit den spärlichen Infos auch nicht sagen, du hast ja noch nichtmal gesagt wie man diese Teile ansprechen kann.

 

[LasMiranda]

JavaApplets sollte man für komplette Anwendungen nehmen. Ein aktiviertes Java wird auch wesentlich weniger anzutreffen sein, als ein aktiviertes JavaScript.

Von den Möglichkeiten her ist ein JavaApplet natürlich besser.

 

[theHacker]

U.U. is keines von beiden notwendig.

Kommt halt drauf an, was man haben will.

 

[SevenTech]

Danke für eure Antworten schonmal aber ich muss nochn bisschen nachbohren:

Java-Applets sind nicht mehr zeitgemäß.
JavaScript und JavaApplets können keine Anlagen überwachen.

Mehr kann ich dir mit den spärlichen Infos auch nicht sagen, du hast ja noch nichtmal gesagt wie man diese Teile ansprechen kann.

Ob Java-Applets zeitgemäß oder geeignet sind oder nicht spielt eine andere Rolle und es beantwortet auch meine Frage leider nicht. Doch man kann mit JavaApplets und Java sich wenigstens Prozessdaten aquirieren und sich anzeigen lassen. Das war das eine Beispiel, was ich Java online und mit JavaScripts gemacht hab. Gewisse Technikertruppenteile sind ganz verzückt auf die Möglichkeiten des Webs auch wenn das eigentlich am weitesten entfernt von ihren Bedürfnissen ist.

Achja wegen dem Hintergrund: Die technische Anlage ist natürlich mitm Server verbunden, der dann über entsprechende Servlets oder anderes, dem JavaScript oder Java-Applet dann die Prozessdaten zuschickt. Nur als Vorstellung aber viel tiefer soll es hier garnicht gehen. Ansonsten verstehen wir uns falsch.

U.U. is keines von beiden notwendig.

Kommt halt drauf an, was man haben will.

Wie gesagt es geht um nichts konkretes sondern allgemein um die Vorteile die Java-Applets und JavaScript für die dynamisierung der Webseiten bieten. Das schließt die Frage, was man im Einzelfall konkret benötigt aus.

JavaApplets sollte man für komplette Anwendungen nehmen. Ein aktiviertes Java wird auch wesentlich weniger anzutreffen sein, als ein aktiviertes JavaScript.

Von den Möglichkeiten her ist ein JavaApplet natürlich besser.

Das hatte ich leider vergessen: Wir sprechen nicht von Otto-Normalnutzer sondern wir dürfen davon ausgehen, dass wir einen ideal voll optimiert eingestellten Browser für unsere Anwendung bzw. das Problem haben. Unter dieser Vorraussetzung: Könntest du bitte deinen letzten Gedanken etwas erschöpfender formulieren? Hört sich gut an

Nochmal zu guter letzt: Es geht wie bereits mehrfach erwähnt, um die Vor und Nachteile von JavaApplets/JavaScript allgemein, wenn es um die Dynamisierung von Webseiten geht. Vlt. vergessen wir mal besten diesen tiefergehenden Fakt mit der Anlage im Hintergrund und das gewisse Leute das für nicht ganz zugeschnittene Probleme nutzen. Fakt ist: Es geht und man kann es dafür verwenden. Sinn oder Unsinn sei dahingestellt.

 

[theHacker]

Gehen wir von einem perfekt zugeschnittenen Browser aus, würd ich das Java-Applet nutzen. Warum?

Wenn die Aufgabe wirklich nur is, irgendeine Steuerung zu machen (ich stell mir da Buttons, Sliders und alle möglichen Anzeigen und Balken vor), dann stell ich mir die Frage: Wieso soll ich mich mit Webprogrammierung aufhalten?
JavaScript würde AJAX bedingen, wo ich alle paar Sekunden beim Server pullen muss. Quark!
Auch brauch ich keine zig verschiedenen Unterseiten, sondern eigentlich nur ein "Programm", was ständig auf dem Bildschirm is. Kein Markup, nix mit verschiedenen Browsern aufhalten. Alles nicht notwendig für diesen Fall.

Wenn hier die Webseite wirklich nur ein zugeschnittenes Frontend für eine Steuerung auf dem Server sein soll, dann nutze ich Java und halte via TCP persistente Verbindungen zum Server. Ich muss nicht nachfragen, sondern der Server schickt mir alle paar Millisekunden ein paar Bytes - kein Overhead, kein Headshake, nix, außer vielleicht n paar Kontrollbytes - und ich zeige sie an. Für den Fall, dass ich aktiv eingreife und einen Knopf drücke, wird dann eben in die Gegenrichtung geschickt.

 

[ice-breaker]

Achja wegen dem Hintergrund: Die technische Anlage ist natürlich mitm Server verbunden, der dann über entsprechende Servlets oder anderes, dem JavaScript oder Java-Applet dann die Prozessdaten zuschickt. Nur als Vorstellung aber viel tiefer soll es hier garnicht gehen. Ansonsten verstehen wir uns falsch.

genau das wollten wir wissen

Gehen wir von einem perfekt zugeschnittenen Browser aus, würd ich das Java-Applet nutzen. Warum?

ich bin für JavaScript, fügt sich besser in den Gesammtkontext des Browsers ein, ein Applet ist einfach ein Fremkörper.

Wenn die Aufgabe wirklich nur is, irgendeine Steuerung zu machen (ich stell mir da Buttons, Sliders und alle möglichen Anzeigen und Balken vor), dann stell ich mir die Frage: Wieso soll ich mich mit Webprogrammierung aufhalten?

gerade diese Dinge lassen sich meiner Meinung nach mit JavaScript (jQuery) deutlich angenehmer und auch optisch ansprechender umsetzen.

JavaScript würde AJAX bedingen, wo ich alle paar Sekunden beim Server pullen muss. Quark!

Jup quark!
Comet, Long Polling oder WebSockets sind die optimalen Praktiken dafür.
Da wir von Servlets sprechen, auch gut lösbar, da Jetty und Tomcat Funktionen dafür haben, und auch Teil des neuen J2EE-Standards ist.

Auch brauch ich keine zig verschiedenen Unterseiten, sondern eigentlich nur ein "Programm", was ständig auf dem Bildschirm is. Kein Markup, nix mit verschiedenen Browsern aufhalten. Alles nicht notwendig für diesen Fall.

reine JavaScript-Anwendung, geschlossene Zielgruppe, keine Browserprobleme.

 

[theHacker]

[...] und auch optisch ansprechender umsetzen.

In Java hab ich Kontrolle über jedes einzelne Pixel. Du kannst dich also in der Optik soviel verausgaben, wie du willst. Und du bist zufällig frei von betriebssystem-/browsereigenen Vorgaben.
(Wenn du willst, kannst du der Optik n eigenen Thread spendieren, wenn 2 oder mehr CPUs verfügbar sind )

 

[SevenTech]

@Hacker: Danke! Das ist genau das, was ich wissen wollte. D.h. mit einem Java-Applet und der persistenten Verbindung, wäre ich z.B. sogar in der Lage Alarm-Meldungen ausgehend von Server/Anlage zurück an den Client zu schicken und nicht erst auf Anfrage wie bei JavaScript und AJAX.

Und wie sieht das mit Sitzungs-Daten aus? Wenn ich mit AJAX/JS ständig polle und der Server nur Anfragen von entsprechenden authentifizierten Nutzern entgegen nimmt (Name/Passwort), dann müsste doch diese Information immer irgendwie als Overhead mitgeschickt werden oder? Klar kann man Daten beim Client speichern aber das ist nicht erwünscht. Der Sicherheitsaufwand ist bei Web-Anwendungen dieser Art so schon sehr hoch*.

*Aber wie gesagt ob Un oder Sinn ist eine andere Frage.

Comet, Long Polling oder WebSockets sind die optimalen Praktiken dafür.
Da wir von Servlets sprechen, auch gut lösbar, da Jetty und Tomcat Funktionen dafür haben, und auch Teil des neuen J2EE-Standards ist.

D.h. es wäre damit auch möglich ständig die Verbindung zu halten ohne ständig zu pollen? Leider wurde das nur sehr spärlich erklärt, als ich mich damals mit diesem Thema (leider nur) relativ kurz beschäftigt hab (bzw. konnte). Meine Frage hier kam dann erst später auf und ich konnte nicht mehr nachhaken. In einer Zusatzaufgabe, wurde tatsächlich Tomcat verwendet. Leider bin ich dazu nicht mehr gekommen.

Achja die Optik spielt nur zweitrangig eine Rolle. Es soll übersichtlich sein und entsprechende Farben da eingesetzt werden wo es notwednig ist (weil wichtig oder so) - mehr nicht.

reine JavaScript-Anwendung, geschlossene Zielgruppe, keine Browserprobleme.

Warum dann ausgerechnet JavaScript wenn diese Bedingungen vorliegen?

 

[theHacker]

Und wie sieht das mit Sitzungs-Daten aus? Wenn ich mit AJAX/JS ständig polle und der Server nur Anfragen von entsprechenden authentifizierten Nutzern entgegen nimmt (Name/Passwort), dann müsste doch diese Information immer irgendwie als Overhead mitgeschickt werden oder?

Wenn du AJAX einsetzt, hast du das HTTP-Protokoll unter dir. Normales Spielchen mit Sessions, Keksen, etc.
Da kannst AJAX auch mit HTTPS verwenden. Da geht mein Wissen aber zur Neige. Prinzipiell kannst du zusätzlich die Daten im XML-Container ja noch beliebig sichern und verschlüsseln. Macht nur keinen Sinn, da XML für den Austausch von Textdaten is.

Setzt du TCP direkt ein, bist du eine Ebene im Protokollstack tiefer, hast mehr Freiheiten und den ganzen Overhead der Ebene 5 (HTTP) weg. Du kannst machen, was du willst. Denk dir selber was aus oder im professionellen Bereich eben geeignete Protokolle und Sicherheitsmechanismen suchen und einsetzen.

 

[ice-breaker]

In Java hab ich Kontrolle über jedes einzelne Pixel.

In JavaScript genauso möglich, nennt sich Canvas

Du kannst dich also in der Optik soviel verausgaben, wie du willst. Und du bist zufällig frei von betriebssystem-/browsereigenen Vorgaben.
(Wenn du willst, kannst du der Optik n eigenen Thread spendieren, wenn 2 oder mehr CPUs verfügbar sind )

schonmal versucht eigene Designs für einen Slider zu implementieren? Das ist in Swing eine Qual, ich habe ihn nachher selbst auf einem JPanel gezeichnet und implementiert.

@Hacker: Danke! Das ist genau das, was ich wissen wollte. D.h. mit einem Java-Applet und der persistenten Verbindung, wäre ich z.B. sogar in der Lage Alarm-Meldungen ausgehend von Server/Anlage zurück an den Client zu schicken und nicht erst auf Anfrage wie bei JavaScript und AJAX.

ja kannst du, es ist aber genauso mit JavaScript möglich, nennt sich WebSockets (sehr genial).
Es wird erst ein HTTP-Request gestartet, dann mit einem HTTP-Response geantwortet und ab dem Zeitpunkt kann man die Verbindung zwischen Client und Server komplett so variabel wie TCP nutzen.
Für Browser die das noch nicht kennen gibt es web-socket-js, eine Flash-Implementierung, die die API Js zur Verfügung stellt.

D.h. es wäre damit auch möglich ständig die Verbindung zu halten ohne ständig zu pollen?

ja, bei Long-Polling stellst du eine Anfrage an den Server und diese läuft solange bis der Server dir antwortet. Hat er dir geantwortet, stellst du die Anfrage neu, bis dir geantwortet wird.
Meebo, der Facebook-Chat und viele weitere Applikationen bauen auf das Modell auf (ist mit Servlets eben sehr einfach zu implementieren). Alternativ eben die bessere Lösung mit Websockets.

Warum dann ausgerechnet JavaScript wenn diese Bedingungen vorliegen?

Weil soetwas in JavaScript schneller entwickelt ist als im Counterpart mit Java. Und gleichzeitig bist du eben nicht an diese strengen Auflagen, die du gemacht hast, gebunden. Bei Bedarf kann die Anwendung eben auch genutzt werden für Rechner die nicht diese spezielle Konfiguration aufweist.
Du nutzt auch keine speziellen Features, die nur mit einem Java-Applet lösbar sind, daher würde ich eine tote Technologie auch in seinem Grab lassen.

Da geht mein Wissen aber zur Neige.

schau dir mal HTML5 an



@tH: also zusammenfassend hast du noch keinen besonderen Vorteil von Java Applets genannt, der nicht auch mit JavaScript realisierbar ist.

 

[SevenTech]

Wenn du AJAX einsetzt, hast du das HTTP-Protokoll unter dir. Normales Spielchen mit Sessions, Keksen, etc.
Da kannst AJAX auch mit HTTPS verwenden. Da geht mein Wissen aber zur Neige. Prinzipiell kannst du zusätzlich die Daten im XML-Container ja noch beliebig sichern und verschlüsseln. Macht nur keinen Sinn, da XML für den Austausch von Textdaten is.

Setzt du TCP direkt ein, bist du eine Ebene im Protokollstack tiefer, hast mehr Freiheiten und den ganzen Overhead der Ebene 5 (HTTP) weg. Du kannst machen, was du willst. Denk dir selber was aus oder im professionellen Bereich eben geeignete Protokolle und Sicherheitsmechanismen suchen und einsetzen.

Sessions, Kekse okay hab ich mir fast gedacht. Für diesen Anwendungsbereich um den es hier geht gibt tatsächlich entsprechende andere zugeschnittene Lösungen aber darum ranken sich einige Probleme. Um konkret zu werden: OPC also OLE for Process Control bzw. Object Linking and Embedding for Process control - da ist der Tag vorbei, wenn mans ausgesprochen hat. Das setzt in seiner klassischen Form auf COM/DCOM auf und war ja bei Windows immer fein dabei und man hat dann entsprechende voll ausprogrammierte Clients für die speziellen Anforderungen programmiert. Aus verschiedenen Gründen ist das aber nicht mehr abkzeptabel. Einerseits ist man dabei das OPC weiterzuentwickeln aber auch ein signifikanter Teil beschäftigt sich mit der Möglichkeit das über Web-Anwendung zu machen und alles schön bequem über Browser machen (Faulitis maximus auch da jaja ^^).

Es wird erst ein HTTP-Request gestartet, dann mit einem HTTP-Response geantwortet und ab dem Zeitpunkt kann man die Verbindung zwischen Client und Server komplett so variabel wie TCP nutzen.

Also damit ich das recht verstanden hab: Mit diesen WebSockets bei JavaScript kann ich somit eine beständige Verbindung aufbauen, die beide Server/Client nutzen können, um sich jederzeit ohne neuen Request oder Authentifizierung Nachrichten zu schicken. Und intialisiert wird das ganze über einen HTTP Request. Auf welchem Protokoll läuft dass dann danach weiter - einfach nur TCP dann? Das kann ja dann nicht weiterhin HTTP darüber nutzen so wie es mir scheint.

 

[ice-breaker]

jup korrekt Sobald HTTP-Request und Response ausgetauscht ist, ist es ein normaler TCP-Stream.

 

[SevenTech]

Vielen Dank für sehr ausführlichen Antworten.

Eine Sache ist mir noch eingefallen:
Gibt es eigentlich für JavaScript solche richtig feschen Debugger mit allem Pipapo? Also es muss nicht ja vlt. gleich so sein wie in Visual Studio oder Eclipse aber halt was mit dem sich das geschriebene nicht nur oberflächlich sondern auch tiefer beleuchten lässt. Ich bin jetzt allerdings auf Grund meiner Unwissenheit nicht ganz sicher ob es für solche ausladenden Debugger bei JavaScript eine Notwendigkeit besteht oder je bestand (vlt. schieß ich da mit Kanonen auf Spatzen oder auch nicht). Ich weiß, dass welche existieren aber sind die gut? Was letztlich auf die Vergleichsfrage hinausführt: Ist mit Java dann im Hinblick auf diese eine Angelegenheit einfacher zu entwickeln als JS? Also als ich das eine JS-Beispiel nur mal mitm Browser gemacht hab, da hab ich manchmal ganz schön in die Röhre geschaut, wo der Hase im Pfeffer steckt.

Sowas spielt durchaus auch eine Rolle für Dynamisierung, wenn auch eher indirekt.

 

[paddya]

Eine Sache ist mir noch eingefallen:
Gibt es eigentlich für JavaScript solche richtig feschen Debugger mit allem Pipapo?

Firebug und Konsorten sollten vollkommen ausreichen