bin ich der Einzige ...

[vlad_tepesch]

dem die ganze Verlagerung von Funktionalität in den Browser extrem sinnlos vorkommt?
Das Mehr an Rechenzeit, was man so durch Fortschritt gewinnt wird hier sinnlos verballert, indem man in Skriptsprachen programme schreibt, die man auch nativ kompilieren und ausführen könnte.

AUßerdem was soll ich in einem Spiel mit einem Vorwärts/Zurück-Button und einer Adressleiste?

[nate]

> dem die ganze Verlagerung von Funktionalität in den Browser extrem sinnlos
> vorkommt?

Nein, ich finde es auch etwas befremdlich -- aber dennoch verständlich, denn browserbasierte Anwendungen sind die einzigen, die ohne großen Portierungsaufwand auf jeder Plattform laufen. Das ist gerade heute, wo die Anzahl und Diversität der Plattformen steigt, durchaus wichtig.

> Das Mehr an Rechenzeit, was man so durch Fortschritt gewinnt wird hier
> sinnlos verballert, indem man in Skriptsprachen programme schreibt, die man
> auch nativ kompilieren und ausführen könnte.

Spätestens im Browser wird der JavaScript-Code nativ compiliert und ausgeführt.

> AUßerdem was soll ich in einem Spiel mit einem Vorwärts/Zurück-Button und
> einer Adressleiste?

Den Vollbildmodus aktivieren?

[ggggggggggg]

vlad_tepesch schrieb:
--------------------------------------------------------------------------------
> dem die ganze Verlagerung von Funktionalität in den Browser extrem sinnlos
> vorkommt?
> Das Mehr an Rechenzeit, was man so durch Fortschritt gewinnt wird hier
> sinnlos verballert, indem man in Skriptsprachen programme schreibt, die man
> auch nativ kompilieren und ausführen könnte.

Jain,
wenn man rechenintensive Aufgaben in die "Cloud" (bzw. auf einen Server) verlegt, könnte man durchaus etwas gewinnen.
Dann bräuchte der Client eben kein Highendgerät mehr sein, da nicht mehr lokal gerechnet werden muss.
Lokal muss dann nur noch der "gestreamte" Inhalt darstellen und die Benutzereingaben an die Cloud/den Server zurückgesendet werden.
So wären sogar theoretisch weitaus rechenintensivere Anwendungen denkbar, als man sich mit einer einfachen Rechenkiste zuhause vorstellen könnte.

Soviel zur Theorie, es bleibt natürlich immernoch der Flaschenhals Internetverbindung.

[Missingno.]

> denn browserbasierte Anwendungen sind die einzigen, die ohne großen Portierungsaufwand auf jeder Plattform laufen.
Wo denn? In der Realität sieht es doch so aus:

- Du hast nicht Browser A, B oder C.

- Du hast A, B oder C, aber nicht in Version D oder höher.

- Du hast A, B oder C in Version D oder höher, aber nicht Plugin E.

- Du hast A, B oder C in Version D oder höher und Plugin E, aber nicht in Version F oder höher.

--
Dare to be stupid!

[nate]

> Wo denn? In der Realität sieht es doch so aus:
>
> - Du hast nicht Browser A, B oder C.
> - Du hast A, B oder C, aber nicht in Version D oder höher.
> - Du hast A, B oder C in Version D oder höher, aber nicht Plugin E.
> - Du hast A, B oder C in Version D oder höher und Plugin E, aber nicht in
> Version F oder höher.

Ja, das sind gute Beispiele dafür, wie Webprogrammierung *nicht* funktioniert. Es gibt aber auch unzählige Webanwendungen, die auf allen modernen Browser-Engines (also WebKit, Presto und Gecko) gleichermaßen funktionieren.

[Siciliano]

Ich muss dies über eine Dritt-Software lösen, wenn ich Browserspiele mit dem Controller spielen möchte. Für mich wäre es praktisch... ich finde jedoch, dass man solche Erweiterung auch abschalten können sollte = Ressourcen-Schonung + Geschwindigkeit

[Flyron]

nate schrieb:
--------------------------------------------------------------------------------
> > Wo denn? In der Realität sieht es doch so aus:
> >
> > - Du hast nicht Browser A, B oder C.
> > - Du hast A, B oder C, aber nicht in Version D oder höher.
> > - Du hast A, B oder C in Version D oder höher, aber nicht Plugin E.
> > - Du hast A, B oder C in Version D oder höher und Plugin E, aber nicht
> in
> > Version F oder höher.
>
> Ja, das sind gute Beispiele dafür, wie Webprogrammierung *nicht*
> funktioniert. Es gibt aber auch unzählige Webanwendungen, die auf allen
> modernen Browser-Engines (also WebKit, Presto und Gecko) gleichermaßen
> funktionieren.

Aber nur, weil sie eben auf eine aberwitzige Matrix von Browsern, Versionen, Plugins, etc. portiert und getestet wurden.

Ich glaube, die Browser befinden sich da in einem kognitiven Widerspruch: Einerseits versucht sich jeder Browser durch Alleinstellungsmerkmale von der Konkurrenz abzuheben, andererseits sollen alle auf den großen gemeinsamen Standard hinarbeiten...
Natürlich sollte man dabei Render-/Javascript-Engine getrennt von der Oberfläche und Benutzerführung betrachten. Gerade bei zweiterem liegen ja die für den Endbenutzer wichtigsten Unterschiede zwischen den Browsern.
Aber der Artikel zeigt ja auch wieder, dass die Browser-Entwickler auch in der Engine immer unterschiedliche Vorstöße wagen. Und das ist es, was einen gemeinsamen Standard in der Funktionalität für Web-Anwendungen eher gefährdet.

[nate]

> Aber nur, weil sie eben auf eine aberwitzige Matrix von Browsern,
> Versionen, Plugins, etc. portiert und getestet wurden.

"Portiert" ist das falsche Wort. Wirklich auf verschiedene Engines _portieren_ muss man den Code nur, wenn man noch nicht standardisierte APIs benutzt, wo Mozilla und Google/Apple verschiedene Wege gehen -- derzeit also z.B. für Realtime-Audio oder eben das Joystick-API. Aber sobald es einen herstellerübergreifenden Standard gibt (auch wenn er noch nicht final ist, siehe WebGL), kann man den Code durchaus so schreiben, dass er überall funktioniert. Um das Testen kommt man dabei natürlich nicht herum :)

[SoniX]

Ne mir gehts genauso.

Eine Art Wrapper würde ich weit besser finden.

Sowas habe ich vor Jahren mal verwendet. Damit konnte man ganz einfach die Buttons des Joysticks oder Gamepads auf andere Tasten umleiten. Das hat dann Systemweit funktioniert; am Desktop, in Spielen, selbst in Dosbox oder im Emulator. Das Spiel hat ja auch garnicht gemerkt, dass das nun n Joystick ist.

[Trollversteher]

>Nein, ich finde es auch etwas befremdlich -- aber dennoch verständlich, denn browserbasierte Anwendungen sind die einzigen, die ohne großen Portierungsaufwand auf jeder Plattform laufen. Das ist gerade heute, wo die Anzahl und Diversität der Plattformen steigt, durchaus wichtig.

Naja, also wenn man sich Browsergames wie z.B. Bigpoints neues Drakensang ansieht, welches trotz Java im Browser erst mal nur auf Win-PCs läuft, scheint das auch kein Argument mehr zu sein...

>Spätestens im Browser wird der JavaScript-Code nativ compiliert und ausgeführt.

Wird er nicht - der wird zur Laufzeit interpretiert, was etwas völlig anderes ist.

[nate]

> Naja, also wenn man sich Browsergames wie z.B. Bigpoints neues Drakensang
> ansieht, welches trotz Java im Browser erst mal nur auf Win-PCs läuft,
> scheint das auch kein Argument mehr zu sein...

Wieso "nicht mehr"? Für Bigpoint ist es eher "noch kein" Argument :)
3D-Grafik im Browser funktioniert -- Stand heute! -- nur auf Desktop-Betriebssystemen, egal ob man sich für WebGL, Flash 11 oder eine Java-Bastellösung entscheidet. Da hat Bigpoint wohl einfach nachgerechnet und ist zu dem Schluss gekommen, dass es sich nicht lohnt, auf eine kompliziertere Technologie zu setzen, die dafür auch auf OS X und Linux funktioniert -- ist zwar schade, kann man ihnen aber nicht verübeln, das machen die meisten anderen Spielepublisher schließlich auch so. Aber spätestens wenn WebGL dann auch in Tablets und Mobiltelefonen Einzug hält, ist diese Überlegung hinfällig, denn diesen wachsenden Markt will man sich als Browserspiel-Anbieter sicherlich nicht entgehen lassen.

> > Spätestens im Browser wird der JavaScript-Code nativ compiliert und
> > ausgeführt.
>
> Wird er nicht - der wird zur Laufzeit interpretiert, was etwas völlig
> anderes ist.

Du bist nicht auf dem neuesten Stand -- seit ein paar Monaten haben alle Browserengines (sogar IE9!) JavaScript-JIT-Compiler :)