Abo
  1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Bastion und Mini Ninjas…

Also zurück zur Browserabhängigkeit

  1. Thema

Neues Thema Ansicht wechseln


  1. Also zurück zur Browserabhängigkeit

    Autor: linuxuser1 09.12.11 - 10:27

    Das ist doch schei*e!

  2. Re: Also zurück zur Browserabhängigkeit

    Autor: ggggggggggg 09.12.11 - 12:07

    kennt man ja sonst nur von MS.
    Wie war das mit "don't be evil"? ;-)

  3. Re: Also zurück zur Browserabhängigkeit

    Autor: Tapsi 09.12.11 - 12:18

    Wenn schon hätte man doch Java oder C# nehmen können, als wieder was neues reinzubringen. Ich mein, ich finde es beeindruckend, aber ganz erlich.... eine weiche und vor allem fließende Einbindung von Java/c# in den Browser hätte mir besser gefallen.

    while not sleep
    sheep++

  4. Re: Also zurück zur Browserabhängigkeit

    Autor: Nolan ra Sinjaria 09.12.11 - 12:46

    genial find ich bei solchen sachen dann auch immer noch die kommentare "kein Download erforderlich" weil es ja im Browser läuft. Okay was genau macht der Browser gleich nochmal, wenn das Plugin den Ladebalken für das Spiel anzeigt? ;)

    Ich habe nix gegen Christen. Ich habe nix gegen Moslems. Ich habe nix gegen Vegetarier. Ich habe nix gegen Apple-Fans. Aber ich habe etwas gegen Missionare...

  5. Re: Also zurück zur Browserabhängigkeit

    Autor: mikeee88 09.12.11 - 12:55

    > Also zurück zur Browserabhängigkeit

    Nicht ganz... der Native Client ist OpenSource und kann somit einfach in andere Browser übernommen werden.

    Das damalige Problem von IE6 war:

    1) Quasi-Monopol (>90% Marktanteile)

    2) MS hat absichtlich CSS falsch implementiert, um Programmierer zu demotivieren für "das Internet / Browser" zu programmieren bzw. das ganze Prozess der Abkehr von OS-Programmen zu Browser-Anwendungen zu verlangsamen (klingt anfangs unglaubwürdig, aber so manches kann man zB hier nachlesen / verstehen: http://www.joelonsoftware.com/articles/APIWar.html )

    => die Engine von IE war nicht nur nicht OpenSource, sondern auch inkompatibel zu den Browser, die die Standards richtig implementiert haben. Da aber MS >90% Markanteil hatte, musste man entweder a) die Webseite absichtlich Stand-NICHT-konform schreiben, oder b) sich stundenlang mit Tricks beschäftigen und somit beide Art von Browser (standardkonforme und IE6) unterstützen

  6. Re: Also zurück zur Browserabhängigkeit

    Autor: tingelchen 09.12.11 - 13:02

    Java ist langsam und viel zu komplex. die Klassenkonstrukte sind vollkommen unübersichtlich. Ganz zu schweigen davon das der Java Updater zu blöd ist sich selbst vernünftig zu aktualisieren.

    C# ist nicht wirklich Plattformunabhängig. Die einzige Plattform auf der es gut läuft ist Windows. auf allen anderen gibt es entweder gar keinen Port, oder nur einen der hinter her läuft (Mono).

    Da sehe ich Qt eher in der Lage. Qt gibt es für unterschiedliche Plattformen und hat ein übersichtliches Klassenkonstrukt. Dank C++ kann man zusätzlich auf diverse Bibliotheken zurück greifen. Vor allem, wenn diese auf den Zielplattformen vorhanden sind.


    Alles in allem jedoch, ist kein Native Client sinnvoll in einem Browser, weil es zwangsweise zu einem Plugin führt. Denn es ist kein Standard. Daher is ein guter Javascript Compiler deutlich besser und vor allem Plattformunabhängig.

  7. Re: Also zurück zur Browserabhängigkeit

    Autor: Tapsi 09.12.11 - 13:48

    > Java ist langsam und viel zu komplex. die Klassenkonstrukte sind vollkommen
    > unübersichtlich. Ganz zu schweigen davon das der Java Updater zu blöd ist
    > sich selbst vernünftig zu aktualisieren.

    Das meinte ich ja unter weich integieren.... man sollte am besten gar nciht mitbekommen, dass Java dabei ist. Außerdem könnte man durch eine Embedded VM auch Updateroutinen weglassen.

    Interessant wäre es ja nur deshalb, weil Google ja eben auch viel mit Java macht.

    > Da sehe ich Qt eher in der Lage. Qt gibt es für unterschiedliche
    > Plattformen und hat ein übersichtliches Klassenkonstrukt. Dank C++ kann man
    > zusätzlich auf diverse Bibliotheken zurück greifen. Vor allem, wenn diese
    > auf den Zielplattformen vorhanden sind.

    Aber C++ müsste doch für jede Plattform neu kompiliert bzw. ausgeliefert werden?!


    > Alles in allem jedoch, ist kein Native Client sinnvoll in einem Browser,
    > weil es zwangsweise zu einem Plugin führt. Denn es ist kein Standard. Daher
    > is ein guter Javascript Compiler deutlich besser und vor allem
    > Plattformunabhängig.

    Hmmm hmm hmm... neija... letztendlich ist eine Javascript VM/Interpreter (was auch immer) auch nur ein zusätzlicher Bestandteil eines Webbrowsers. Des weiteren wüsste ich nicht was das mit Standard zu tun hat. Beide Java/c# sind nach standardisierten Spezifikationen entworfen und festgelegt, sodass man wie bei JS auch von richtig funktionierenden Plugins ausgehen kann.

    Das Problem liegt doch eher in der Plattformunabhängikeit (mMn). Denn JS erlaubt wirklich eine extreme hohe Portabilität (eben erst auf dem Client nativ kompilieren) und das sehe ich gerade bei NativeClient und C++ eher kritisch. Die JVM wäre da, mMn., besser, weil sie eben auch statisch getypte Sprachen erlaubt, die eben performanter sind. Statt NC und Dart und whatever hätte ich mir daher eher die JVM oder CLR gewünscht.... da drauf hätte man immernoch super JS laufen lassen können. Und wenn Google ganz lustig ist, hätten sie eben auch ihr Dart dafür entworfen....

    Meinungsache, aber für mich hätte es bessere Alternativen gegeben. Aber Google und Oracle mögen sich ja nciht so xD

    while not sleep
    sheep++

  8. Re: Also zurück zur Browserabhängigkeit

    Autor: Seitan-Sushi-Fan 09.12.11 - 15:56

    tingelchen schrieb:
    ----------------
    > C# ist nicht wirklich Plattformunabhängig.

    Selbstverständlich ist die Spezifikation einer Programmiersprache völlig plattformunabhängig.


    > Die einzige Plattform auf der es
    > gut läuft ist Windows. auf allen anderen gibt es entweder gar keinen Port,
    > oder nur einen der hinter her läuft (Mono).

    Na und? Was hat das mit der Programmiersprache zu tun? Außerdem könnten sich Standardorganisationen auch auf ein Subset von C#, CIL usw. einigen, das für Browser geeignet ist (hat man ja bei QebGL auch geschafft), zumal ja offensichtlich in so einem Fall HTML+JS+CSS weiterhin für's GUI eingesetzt werden.

  9. Re: Also zurück zur Browserabhängigkeit

    Autor: kmork 09.12.11 - 21:49

    tingelchen schrieb:
    --------------------------------------------------------------------------------
    > Da sehe ich Qt eher in der Lage. Qt gibt es für unterschiedliche
    > Plattformen und hat ein übersichtliches Klassenkonstrukt. Dank C++ kann man
    > zusätzlich auf diverse Bibliotheken zurück greifen. Vor allem, wenn diese
    > auf den Zielplattformen vorhanden sind.

    Ich hab ja eigentlich eher nix gegen NaCl. Aber in dem Fall (die Idee ist auf jedenfall interressant!) müsste es ja nun wirklich nicht in C++ sein, schließlich wird bei Qt schon länger eine Nutzung von Javascript oder anderen Skriptsprachen propagiert. Macht bei graphischen Oberflächen auch Sinn, imho.

    Ich seh das Potenzial von NaCl eher bei rechenlastigen Problemstellungen und bei Portierungen.

  10. Re: Also zurück zur Browserabhängigkeit

    Autor: Pierre Dole 10.12.11 - 12:12

    Ich kann mich noch erinnern, es war so um das Jahr 2002/2003. Da haben wir die Websites für die letzten 3 Versionen von IE, Netscape und Opera optimiert. Und das sowohl für den PC als auch fürn Mac. Das war noch eine Arbeit die Websites auf allen Browsern gleich aussehen zu lassen. Heute kommt man mit GWT daher und es passt auf Anhieb.

  11. Re: Also zurück zur Browserabhängigkeit

    Autor: Geistesgegenwart 10.12.11 - 14:15

    tingelchen schrieb:
    --------------------------------------------------------------------------------
    > Java ist langsam und viel zu komplex. die Klassenkonstrukte sind vollkommen
    > unübersichtlich. Ganz zu schweigen davon das der Java Updater zu blöd ist
    > sich selbst vernünftig zu aktualisieren.

    Full ACK.

    >
    > C# ist nicht wirklich Plattformunabhängig. Die einzige Plattform auf der es
    > gut läuft ist Windows. auf allen anderen gibt es entweder gar keinen Port,
    > oder nur einen der hinter her läuft (Mono).

    So sehr Mono hinterher läuft, *alle* von Google gezeigten Spiele wurden von Mono angetrieben. Entweder die Spiele wurden in XNA programmiert oder via Unity3D (welches intern ebenfalls Mono verwendet). Google oder Unity haben Mono auf die NaCl portiert (prinzipiell kann man ja C++ mit Sicherheitseinschränkungen ausführen) welches letztlich auf *clientseite* die Spiele ausführt (ich denke AOT compiled im gegensatz zum standard JIT). Quelle hab ich leider momentan nur Twitter: http://twitter.com/#!/migueldeicaza/statuses/145339188538122242 (siehe auch ältere tweets un #NaCl), denke aber da kommen bald mehr technische Details.

    Die Idee ist also gar nicht verkehrt, du kannst also durchaus mit C# deine NaCl Programme / Spiele programmieren.


    > Alles in allem jedoch, ist kein Native Client sinnvoll in einem Browser,
    > weil es zwangsweise zu einem Plugin führt. Denn es ist kein Standard. Daher
    > is ein guter Javascript Compiler deutlich besser und vor allem
    > Plattformunabhängig.

    Naja NaCl ist apache 2.0 opensource lizensiert. Es hindert niemanden daran plugins für IE, Firefox & co herauszubringen.

  12. Re: Also zurück zur Browserabhängigkeit

    Autor: hroessler 10.12.11 - 20:59

    tingelchen schrieb:
    --------------------------------------------------------------------------------
    > Java ist langsam und viel zu komplex. die Klassenkonstrukte sind vollkommen
    > unübersichtlich. Ganz zu schweigen davon das der Java Updater zu blöd ist
    > sich selbst vernünftig zu aktualisieren.
    Das es immer noch Informatiker gibt, die diesen quatsch behaupten. Ok, wie hast du es gemessen? Dank JIT ist der Unterschied zu native kompilierten Programmen meist kaum nocht nennenswert, bzw. es gibt sogar Fälle, in denen ein JIT Kompiliertes Programm sogar flotter ist, als ein native kompiliertes ;-)

    > C# ist nicht wirklich Plattformunabhängig.
    Bestimmt kannst du mir eine Plattformunabhängige Programmiersprache nennen?! xD

    >Die einzige Plattform auf der es
    > gut läuft ist Windows.
    Nein, es läuft auf der .net Plattform, die, wie Mono bewiesen hat, portabel ist.

    > Da sehe ich Qt eher in der Lage. Qt gibt es für unterschiedliche
    > Plattformen und hat ein übersichtliches Klassenkonstrukt.
    >Dank C++ kann man
    > zusätzlich auf diverse Bibliotheken zurück greifen. Vor allem, wenn diese
    > auf den Zielplattformen vorhanden sind.
    Qt selbst kapselt doch einen großen Teil Standard C++ libs und ist selbst nicht mit dem C++ Standard. Bist halt immer auf den Meta Object Compiler angewiesen.


    > Alles in allem jedoch, ist kein Native Client sinnvoll in einem Browser,
    > weil es zwangsweise zu einem Plugin führt. Denn es ist kein Standard.
    Naja, ich persönlich bin der Meinung, dass ein Browser überhaupt nichts nativ ausführen braucht. Ein Browser soll Webseiten anzeigen und benötigt dazu keinen Zugriff auf meine Systemressourcen.

    > Daher is ein guter Javascript Compiler deutlich besser und vor allem
    > Plattformunabhängig.
    Naja, wenn JavaScript so Plattformunbhängig wäre, würden wir Frameworks ala jQuery und Co. nicht benötigen.

    Greetz
    hroessler

  13. Re: Also zurück zur Browserabhängigkeit

    Autor: Tapsi 10.12.11 - 21:29

    > Das es immer noch Informatiker gibt, die diesen quatsch behaupten. Ok, wie
    > hast du es gemessen? Dank JIT ist der Unterschied zu native kompilierten
    > Programmen meist kaum nocht nennenswert, bzw. es gibt sogar Fälle, in denen
    > ein JIT Kompiliertes Programm sogar flotter ist, als ein native
    > kompiliertes ;-)

    Optimiert sind C++ Programme in der Regel immer besser als Java-Pendants. Aber im allgemeinen Fall sind diese Aussagen oft nur Flame-Behauptungen, Erfahrungen aus Lügen.

    EDIT: Bzw. sind meine Java-Programme, vielleicht bin ich der einzigste Java-Programmierer der sowas kann (zumindest sieht es hier im Forum so aus, nach dem was alle über Java sagen :P), bei Kunden (wenn es jetzt auch nur ein Paar sind) nie negativ in Punktu Geschwindigkeit aufgefallen. Manchmal glaube ich auch, dass Java schlampige Programmierung schnell bestraft und deshalb schnell dieser Ruf über Java entsteht. <--- IST JETZT ABER NUR MEINE MEINUNG =)


    > Nein, es läuft auf der .net Plattform, die, wie Mono bewiesen hat, portabel
    > ist.

    Problem ist nur, dass die .net Platform die einzige ist, die den C# Standart voll implementiert... Mono ist meines Wissens nur bis .Net 2.x vollständig kompitabel. (oder?)

    > Naja, wenn JavaScript so Plattformunbhängig wäre, würden wir Frameworks ala
    > jQuery und Co. nicht benötigen.

    DA muss man wieder unterscheiden. Denn dies ist kein Problem von ECMA-Script, sondern ein Problem durch x-verschiedene Implementierungen. Würden alle wirklich korrekt die JavaScript Spezifikationen umsetzen, würden diese Probleme gar nicht auftreten.
    BTW: Ich gehe selber von der Annahme aus, dass viele Script-Kiddies einfach immer jQuery als Basis nehmen, ob sie es nun bräuchten oder nicht. Daher wird jQuery zum zum Pflichtmodul für alles mögliche ernannt, obwohl dies gar nicht notwendig wäre und in einigen Fällen sogar schädlich ist... ( besonders wenn man PRoto und jQuery mischt )

    while not sleep
    sheep++



    1 mal bearbeitet, zuletzt am 10.12.11 21:34 durch Tapsi.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. HITS gGmbH, Heidelberg
  2. ENERCON GmbH, Aurich
  3. Ledermann GmbH & Co. KG, Horb am Neckar
  4. NTI Kailer GmbH, Villingen-Schwenningen, Wendlingen, Lahr

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 69,99€ (Release am 25. Oktober)
  2. 0,49€
  3. (-55%) 4,50€


Haben wir etwas übersehen?

E-Mail an news@golem.de


iPad 7 im Test: Nicht nur für Einsteiger lohnenswert
iPad 7 im Test
Nicht nur für Einsteiger lohnenswert

Auch mit der siebten Version des klassischen iPads richtet sich Apple wieder an Nutzer im Einsteigersegment. Dennoch ist das Tablet sehr leistungsfähig und kommt mit Smart-Keyboard-Unterstützung. Wer ein gutes, lange unterstütztes Tablet sucht, kann sich freuen - ärgerlich sind die Preise fürs Zubehör.
Ein Test von Tobias Költzsch

  1. iPad Einschränkungen für Apples Sidecar-Funktion
  2. Apple Microsoft Office auf neuem iPad nicht mehr kostenlos nutzbar
  3. Tablet Apple bringt die 7. Generation des iPads

Gemini Man: Überflüssiges Klonexperiment
Gemini Man
Überflüssiges Klonexperiment

Am 3. Oktober kommt mit Gemini Man ein ambitioniertes Projekt in die deutschen Kinos: Mit HFR-Projektion in 60 Bildern pro Sekunde und Will Smith, der gegen sein digital verjüngtes Ebenbild kämpft, betreibt der Actionfilm technisch viel Aufwand. Das Seherlebnis ist jedoch bestenfalls komisch.
Von Daniel Pook

  1. Filmkritik Apollo 11 Echte Mondlandung als packende Kinozeitreise

Rabbids Coding angespielt: Hasenprogrammierung für Einsteiger
Rabbids Coding angespielt
Hasenprogrammierung für Einsteiger

Erst ein paar einfache Anweisungen, dann folgen Optimierungen: Mit dem kostenlos erhältlichen PC-Lernspiel Rabbids Coding von Ubisoft können Jugendliche und Erwachsene ein bisschen über Programmierung lernen und viel Spaß haben.
Von Peter Steinlechner

  1. Transport Fever 2 angespielt Wachstum ist doch nicht alles
  2. Mordhau angespielt Die mit dem Schwertknauf zuschlagen
  3. Bus Simulator angespielt Zwischen Bodenschwelle und Haltestelle

  1. BDI: Industrie für schnelle 5G-Errichtung statt Vertrauensschwüre
    BDI
    Industrie für schnelle 5G-Errichtung statt Vertrauensschwüre

    Die deutsche Industrie will keine Vertrauenswürdigkeitserklärung von den 5G-Ausrüstern einholen müssen. Diese Erklärungen seien wirkungslos, gefragt sei dagegen Cyber-Resilienz.

  2. Watch Parties: Twitch ermöglicht Streamern Filmabende mit Followern
    Watch Parties
    Twitch ermöglicht Streamern Filmabende mit Followern

    Gemeinsam im kleinen oder großen Kreis einen Spiefilm oder eine TV-Serie per Streaming anschauen: Das können Influencer künftig auf Twitch - vorerst allerdings nur in den USA.

  3. Smartspeaker: Belauschen mit Alexa- und Google-Home-Apps
    Smartspeaker
    Belauschen mit Alexa- und Google-Home-Apps

    Mit verschiedenen Tricks gelang es Sicherheitsforschern, Apps für Google Home und Amazons Alexa zu erzeugen, die Nutzer belauschen oder Phishingangriffe durchführen. Die Apps überstanden den Review-Prozess von Google und Amazon.


  1. 18:53

  2. 17:38

  3. 17:23

  4. 16:54

  5. 16:39

  6. 15:47

  7. 15:00

  8. 13:27