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. Vorwerk Services GmbH, Wuppertal
  2. Hochschule Furtwangen, Furtwangen
  3. IGEL Technology GmbH, Augsburg
  4. ENGAGEMENT GLOBAL gGmbH, Bonn

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 344,00€
  2. 204,90€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Faire IT: Die grüne Challenge
Faire IT
Die grüne Challenge

Kann man IT-Produkte nachhaltig gestalten? Drei Startups zeigen, dass es nicht so einfach ist, die grüne Maus oder das faire Smartphone auf den Markt zu bringen.
Von Christiane Schulzki-Haddouti

  1. Smartphones Samsung und Xiaomi profitieren in Europa von Huawei-Boykott
  2. Smartphones Xiaomi ist kurz davor, Apple zu überholen
  3. Niederlande Notrufnummer fällt für mehrere Stunden aus

10th Gen Core: Intel verwirrt mit 1000er- und 10000er-Prozessoren
10th Gen Core
Intel verwirrt mit 1000er- und 10000er-Prozessoren

Ifa 2019 Wer nicht genau hinschaut, erhält statt eines vierkernigen 10-nm-Chips mit schneller Grafikeinheit einen Dualcore mit 14++-Technik und lahmer iGPU: Intels Namensschema für Ice Lake und Comet Lake alias der 10th Gen macht das CPU-Portfolio wenig transparent.
Von Marc Sauter

  1. Neuromorphic Computing Intel simuliert 8 Millionen Neuronen mit 64 Loihi-Chips
  2. EMIB trifft Foveros Intel kombiniert 3D- mit 2.5D-Stacking
  3. Nervana NNP-I Intels 10-nm-Inferencing-Chip nutzt Ice-Lake-Kerne

Schienenverkehr: Die Bahn hat wieder eine Vision
Schienenverkehr
Die Bahn hat wieder eine Vision

Alle halbe Stunde von einer Stadt in die andere, keine langen Umsteigezeiten zur Regionalbahn mehr: Das verspricht der Deutschlandtakt der Deutschen Bahn. Zu schön, um wahr zu werden?
Eine Analyse von Caspar Schwietering

  1. DB Navigator Deutsche Bahn lädt iOS-Nutzer in Betaphase ein
  2. One Fiber EWE will Bahn mit bundesweitem Glasfasernetz ausstatten
  3. VVS S-Bahn-Netz der Region Stuttgart bietet vollständig WLAN

  1. Apple: Mitarbeiter hörten bis zu 1.000 Siri-Schnipsel am Tag
    Apple
    Mitarbeiter hörten bis zu 1.000 Siri-Schnipsel am Tag

    Bevor Apple die Auswertung von Siri-Sprachdateien gestoppt hat, mussten Mitarbeiter in Irland teilweise bis zu 1.000 Audio-Schnipsel pro Schicht auswerten. Meist handelte es sich nur um Sprachkommandos, manchmal waren aber auch persönliche Informationen darunter.

  2. ISS: Sojus-Kapsel mit Roboter an Bord bricht Andockmanöver ab
    ISS
    Sojus-Kapsel mit Roboter an Bord bricht Andockmanöver ab

    Eine Sojus-Kapsel mit dem russischen Testroboter Fedor an Bord konnte nicht wie geplant an die ISS andocken - wegen eines Problems des automatisierten Andocksystems des Stationsmoduls. Ein zweiter Versuch ist bereits geplant.

  3. Raumfahrt: Nasa untersucht möglicherweise erstes Verbrechen im Weltraum
    Raumfahrt
    Nasa untersucht möglicherweise erstes Verbrechen im Weltraum

    Ein Scheidungskrieg scheint sich bis auf die ISS ausgeweitet zu haben: Die Astronautin Anne McClain hat von einem Computer der Raumstation auf das Onlinekonto ihrer Ex-Frau zugegriffen und deren Finanzen kontrolliert. Die Nasa untersucht das mutmaßlich erste Verbrechen im Weltraum.


  1. 14:15

  2. 13:19

  3. 12:43

  4. 13:13

  5. 12:34

  6. 11:35

  7. 10:51

  8. 10:27