Als da JavaScript stand...

[twothe]

... war die Sache gleich klar: eine weitere Luftnummer, denn es wird keine next-generation Browser Engine für Desktop-Apps auf JavaScript Basis geben. Jeder Versuch bisher, und technisch bedingt auch jeder zukünftige Versuch, ist zum Scheitern verurteilt. Eine lahmende Schnecke mit Rollator wird mit egal wie viel Farbe nicht zum Ferrari.

[[gelöscht]]

[gelöscht]

[JP]

twothe schrieb:
--------------------------------------------------------------------------------
> ... war die Sache gleich klar: eine weitere Luftnummer, [...]

ganz viel heiße Luft von dir wie mir scheint. Sezieren wir mal deine Sätze und Aussagen:

twothe schrieb:
--------------------------------------------------------------------------------
> [...], denn es wird keine
> next-generation Browser Engine für Desktop-Apps auf JavaScript Basis geben.

"next-generation Browser Engine für Desktop-Apps" - Irgendwie wird nicht ganz klar was du mit all den Buzz-Words meinst, da gibt es unterschiedliche Interpretationsmöglichkeiten. Aber ich vermute du meinst mit "next-generation" die aktuellen kommerziellen Engines.

Auch wenn es sich hier nicht primär um Spiele dreht, kann man Spiele-Engines, wie z.B. Unreal Engine oder CryEngine, als Performance-Maßstab heranziehen. Zumindest für die Unreal Engine existiert ein JS Asm.js Port. Natürlich nicht mit allen Features der aktuellen "nativen" Unreal Engine. Aber viele Spiele abseits der Core-Spiele brauchen auch gar nicht alle Features.

twothe schrieb:
--------------------------------------------------------------------------------
> Jeder Versuch bisher, und technisch bedingt auch jeder zukünftige Versuch,
> ist zum Scheitern verurteilt.

Auf welche Versuche beziehst du dich? Und selbst wenn du recht hättest, Scheitern in der Vergangenheit bedeutet nicht automatisch ein Scheitern in der Zukunft, bestes Beispiel die Entwicklungsgeschichte der Luftfahrt.


twothe schrieb:
--------------------------------------------------------------------------------
> Eine lahmende Schnecke mit Rollator wird mit
> egal wie viel Farbe nicht zum Ferrari.

Wie viel Ahnung hast du so vom Engine Design? Nehmen wir wieder als Performance-Beispiel Game-Engines: So gut wie jede aktuelle Engine kann und wird gescriptet. Der Kern wird oft noch "nativ" unter C/C++ entwickelt, aber das Steuern der Engine wird hauptsächlich mittels Skriptsprachen vorgenommen. Unreal Engine hat ihr UnrealScript, CryEngine lässt sich mittels Lua Scripten, ähnliches Bild bei id Tech, Source, Unity. Das hat viele Gründe, z.B. dass die Performance außerhalb des Cores vernachlässigbar ist.

Also warum soll sich in einer Engine nicht JavaScript als Script-Komponente eigenen? Letztendlich ist das System hier einfach eine "normale" Engine, die verstärkt auf Netzwerk-Ressourcen ausgelegt ist. Da sich die Engine scheinbar auf Grund ihrer Domäne an Web-Standards orientiert ist JS eine logische Konsequenz. Der Kern kann, wie auch bei Web-Browsern, trotzdem nativ in irgendeiner "maschinennahen" Sprache entwickelt und kompiliert werden, nur mit ganz anderen API-Funktionen als ein normaler Web-Browser.

-- Edit: habe bisschen den Fokus auf Spiele-Engines abgemildert, da nidium primär nicht zwingend auf Spiele ausgelegt ist.



1 mal bearbeitet, zuletzt am 05.09.13 03:16 durch JP.

[pythoneer]

Du hast dir ziemlich viel Mühe gegeben für jemanden, der augenscheinlich keine Ahnung hat. Ich befürchte du wirst auf deine gut aus-argumentierten Fragen keine Antworten gleicher Qualität erhalten.



1 mal bearbeitet, zuletzt am 05.09.13 10:28 durch pythoneer.

[Paykz0r]

pythoneer schrieb:
--------------------------------------------------------------------------------
> Du hast dir ziemlich viel Mühe gegeben für jemanden, der augenscheinlich
> keine Ahnung hat. Ich befürchte du wirst auf deine gut aus-argumentierten
> Fragen keine Antworten gleicher Qualität erhalten.

ich kann immer wieder nur betonen,
das viele Probleme der vergangenheit von n00bs schlichtweg javascript zugeordnet wurden.

Javascript ansich ist eine ordentlcihe sprache,
und wer mir mal ein echten JS fehler zeigt,
bekommt blumen.

Das was die meisten als solches bezeichnen,
war in ernst DOM, CSS, Broowserunterschiede, Rendering Probleme...
Aber in den absolut seltensten Fällen (ist mir nie passsiert!) ist es ein Javascript bug.

Daher macht die Idee dieser Leute schon etwas sinn.
Wobei das wieder die Enticklung aufhält, ähnlich wie Flash
(das übrigens auch ein ECMAScript-Core hat)

Naja,
ich mag JS.
Nach 3,5 Jahren C++ und 3,5 Jahren JS beruflich,
will ich nicht wieder zurück zu C++.

[twothe]

Ich sehe in der Entwicklung immer wieder, wie auch JS Profis bei jeglicher Desktop-Anwendung extrem viel Zeit für Performance-Optimierungen verschwenden, wohlgemerkt in einem Bereich, in dem es in anderen Sprachen heißt, Performance kann ignoriert werden, weil man eh 99% der Zeit auf die Eingaben des Anwenders wartet. V8 ist eine sicherlich geniale Weiterentwicklung des JITs, sagt aber auch gleichzeitig, das da in Zukunft nicht mehr viel Performance zu erwarten ist. 10% vielleicht, aber 100% oder 200% sind völlig ausgeschlossen.

LuaJIT schlägt aber schon jetzt auch die V8 um Längen, hat dabei mindestens den selben Funktionsumfang ist aber sprachlich einfacher zu benutzen und gerade was die Integration in Programme angeht wesentlich angenehmer.

Da stell ich mir eine ganz einfache Frage: wenn ich mein Programm in der Ausführungsgeschwindigkeit mindestens verdoppeln - teilweise sogar verzehnfachen - kann indem ich einfach eine andere Scriptsprache nehme, die mir keinerlei Nachteile bietet... warum sollte ich dann bei einem langsameren und in Relation überkomplexen JavaScript bleiben?

Ein Programmierer der so unflexibel ist, das er vom Dogma JavaScript nicht weg kommt, wird, sobald mal einer das Revolutiönchen wagt die Programmiersprache zu wechseln, zusammen mit dem Alteisen aussortiert.