Abo
  1. Foren
  2. Kommentare
  3. Applikationen
  4. Alle Kommentare zum Artikel
  5. › Web-Bytecode: So sieht die…

Ist doch wie Java und .NET

  1. Thema

Neues Thema Ansicht wechseln


  1. Ist doch wie Java und .NET

    Autor: redbullface 01.11.18 - 14:57

    Die Technik der Webassembly ist doch einfach nur Bytecode erzeugen, so wie es Java und .NET auch machen und einige Browser Plugins der Vergangenheit. Ich verstehe nicht, was es jetzt besonders macht.

    https://forum.golem.de/nutzungsbedingungen.php

  2. Re: Ist doch wie Java und .NET

    Autor: lala1 01.11.18 - 15:04

    Das es im Browser läuft und man jetzt mit dem Browser Code ausführen kann, der in jeder beliebigen Sprache (die das compilen in WASM Bytecode) geschrieben wurde.

  3. Re: Ist doch wie Java und .NET

    Autor: schnedan 01.11.18 - 15:23

    und warum baut man dann keinen Java-Bytecode Interpreter ohne Plugin in den Browser ein und "erfindet" mal wieder was Neues?

  4. Re: Ist doch wie Java und .NET

    Autor: redbullface 01.11.18 - 15:25

    Das macht .NET doch auch schon.

    https://forum.golem.de/nutzungsbedingungen.php

  5. Re: Ist doch wie Java und .NET

    Autor: Andreas.Kreuz 01.11.18 - 15:33

    Weil WASM extra für das Web optimiert wurde, das kann man von der JVM und .NET eher nicht behaupten.
    Siehe auch die FAQ von WASM. Bezieht sich zwar auf LLVM statt JVM, passt aber trotzdem ganz gut:
    https://github.com/WebAssembly/design/blob/master/FAQ.md

  6. Re: Ist doch wie Java und .NET

    Autor: redbullface 01.11.18 - 15:45

    Ok, im Grunde ist es nichts neues. Ich dachte, das ich vielleicht das Konzept nicht ganz verstanden hätte. Java wurde ja auch seinerzeit für das Web im Browser entwickelt und macht genau dasselbe. Und im Beitrag steht ja auch, das es auch als Desktop Anwendung vom Browser entkoppelt ausführbar sein soll. Es ist also nicht speziell nur für das Web optimiert und im Grunde wie Java, nur noch mal komplett von Grund auf neu entwickelt und auf aktuelle Technologien optimiert. Macht ja an sich auch durchaus Sinn. Zudem ist es von Oracle/Sun Microsystems oder im Falle von .NET auch von Microsoft unabhängig.

    https://forum.golem.de/nutzungsbedingungen.php

  7. Re: Ist doch wie Java und .NET

    Autor: lala1 01.11.18 - 16:03

    Weil man jede Menge Bullshit Jobs braucht ... keine Ahnung. Wozu braucht man 100derte Javascript Frameworks? Wozu braucht man min 2 CSS Precompiler? Weil einfach irgend einer was besser machen wollte und es am Ende der gleiche Kram ist wie vorher nur farbiger ;)

  8. Re: Ist doch wie Java und .NET

    Autor: lala1 01.11.18 - 16:05

    Ja ... ich bin ja nicht für WASM ... klar macht das .net auch schon aber neu ist cool oder so ... kein Plan. Ich bin gegen Bytecode im Web.
    Shaderanweisungen für WebGL reichen schon.

  9. Re: Ist doch wie Java und .NET

    Autor: Dieselmeister 01.11.18 - 18:17

    Weil dieser Byte Code eben schneller als JS im Browser läuft. Außerdem ist JS eh eine eher bescheidene Sprache, von daher bin ich über Projekte, wie Blazor (.NET SPA im Browser) oder andere Dinge sehr froh.

    Gern kann JS aussterben. Und ich entwickle neben C# und F# eben auch in TypeScript/JS und JS ist meiner Meinung nach einfach eine schlechte Sprache.

  10. Re: Ist doch wie Java und .NET

    Autor: Andreas.Kreuz 01.11.18 - 18:35

    Rein aus Interesse: Was spricht gegen Bytecode (im Web)?
    Ich halte obfuscated JS jetzt nicht unbedingt für besser lesbar..

  11. Re: Ist doch wie Java und .NET

    Autor: FreiGeistler 02.11.18 - 07:11

    Andreas.Kreuz schrieb:
    --------------------------------------------------------------------------------
    > Rein aus Interesse: Was spricht gegen Bytecode (im Web)?
    > Ich halte obfuscated JS jetzt nicht unbedingt für besser lesbar..

    Weil das Betriebssystem für die Verwaltung von Ressourcen zuständig sein sollte.
    Mit WASM wird der Browser quasi zu einem Betriebssystem im Betriebssystem.
    Gibt sicher so ein Gefrickel wie bei Java (nicht JS), nur übers Netz.
    Bin gespannt, wie die das "sicher" und performant kriegen wollen.

  12. Re: Ist doch wie Java und .NET

    Autor: c3rl 02.11.18 - 12:20

    redbullface schrieb:
    --------------------------------------------------------------------------------
    > Ok, im Grunde ist es nichts neues. Ich dachte, das ich vielleicht das
    > Konzept nicht ganz verstanden hätte. Java wurde ja auch seinerzeit für das
    > Web im Browser entwickelt und macht genau dasselbe. Und im Beitrag steht ja
    > auch, das es auch als Desktop Anwendung vom Browser entkoppelt ausführbar
    > sein soll. Es ist also nicht speziell nur für das Web optimiert und im
    > Grunde wie Java, nur noch mal komplett von Grund auf neu entwickelt und auf
    > aktuelle Technologien optimiert.

    Wenn man deiner Einstellung folgt ist auch Java/.NET nichts neues. Seit den ersten Assembly-Sprachen werden Byte-Codes vom Compiler generiert. Der Unterschied bei Java/NET: es ist kein nativer Byte-Code, sondern muss erst noch maschinenabhängig von einer Laufzeit übersetzt werden.

    WASM wurde/wird so entwickelt, dass es in den JS-VMs läuft, aber eben in einer sehr optimierten Form, die das aufwendige Parsing und Optimieren dem Compiler auferlegt, statt der Laufzeit. Es ist also nichts neues und auch nicht "so wie Java". Es ist ganz klar eine (logische) Erweiterung von JS, die in der selben VM laufen wird, mit den selben Rechten und Fähigkeiten.

    Dass es vom Browser entkoppelt ausführbar sein soll hat erstmal nichts mit WASM zu tun, das nennt sich Progressive Web Application.

  13. Re: Ist doch wie Java und .NET

    Autor: c3rl 02.11.18 - 12:25

    redbullface schrieb:
    --------------------------------------------------------------------------------
    > Das macht .NET doch auch schon.

    Wäre mir neu, dass .NET ein Web-Standard ist und von Browsern ausgeführt werden kann.

  14. Re: Ist doch wie Java und .NET

    Autor: c3rl 02.11.18 - 12:29

    FreiGeistler schrieb:
    --------------------------------------------------------------------------------
    > Andreas.Kreuz schrieb:
    > --------------------------------------------------------------------------------
    > Weil das Betriebssystem für die Verwaltung von Ressourcen zuständig sein
    > sollte.

    Ist es doch auch, selbst wenn der Browser ein WASM-Modul ausführt.

    > Mit WASM wird der Browser quasi zu einem Betriebssystem im Betriebssystem.

    Nicht mehr oder weniger, als das bisher mit den JS-VMs schon der Fall war.

    > Bin gespannt, wie die das "sicher" und performant kriegen wollen.

    Steht auf diversen Websites sehr gut erklärt. Die WASM-VM setzt auf den JS-Runtimes auf und emuliert darin eine ganz einfache Art virtueller CPU, gegen die der WASM-Bytecode dann ausgeführt wird. Ist im Prinzip ähnlich zu LLVM, nur halt innerhalb der JS-Runtime.

  15. Re: Ist doch wie Java und .NET

    Autor: redbullface 02.11.18 - 12:32

    Erst mal, danke für die Antwort. Das sieht dann schon mal ganz anders aus.

    c3rl schrieb:
    --------------------------------------------------------------------------------
    > Wenn man deiner Einstellung folgt ist auch Java/.NET nichts neues. Seit den
    > ersten Assembly-Sprachen werden Byte-Codes vom Compiler generiert. Der
    > Unterschied bei Java/NET: es ist kein nativer Byte-Code, sondern muss erst
    > noch maschinenabhängig von einer Laufzeit übersetzt werden.

    Ich bezog mich darauf, das es bereits eine Lösung existiert und "im Grunde" dasselbe macht. Zumindest aus logischer Sicht für den End-Programmierer. Was jetzt zwischen einem nativen Bytecode und dem hier erzeugten Bytecode der Unterschied sein soll, muss ich erst noch verstehen. Werde dazu mich mal kurz woanders einlesen. Danke das du den Punkt aufgebracht hast.

    > Es ist ganz klar eine (logische) Erweiterung von JS,
    > die in der selben VM laufen wird, mit den selben Rechten und Fähigkeiten.

    Mir leuchtet ein das eine neue Entwicklung vollständig den heutigen Gegebenheiten optimiert werden kann und daher auch Sinn macht manchmal etwas neu zu entwickeln. Was ich nicht wusste ist, das es in derselben Umgebung wie JavaScript läuft. Ich dachte, es hätte seine eigene Laufzeitumgebung, eben wie Java (daher meine Vergleiche).

    Diese Fakten lassen das alles im ganz anderen Licht für mich erscheinen und macht absolut Sinn. Bin neugierig geworden, werde mal dazu mehr lesen. :-)

    https://forum.golem.de/nutzungsbedingungen.php

  16. Re: Ist doch wie Java und .NET

    Autor: redbullface 02.11.18 - 12:34

    Ja stimmt, in dem PUnkt habe ich mich verheddert. Ich meinte das mit dem Bytecode erzeugen. War ein unnötiger Kommentar von mir. Edit: Es existiert ja bereits ein Projekt, welches erlaubt .NET in Webassembly zu übersetzen. Vielleicht bin ich deswegen durcheinander geraten.

    https://blazor.net/

    https://forum.golem.de/nutzungsbedingungen.php



    1 mal bearbeitet, zuletzt am 02.11.18 12:37 durch redbullface.

  17. Re: Ist doch wie Java und .NET

    Autor: lala1 02.11.18 - 15:08

    > Ich halte obfuscated JS jetzt nicht unbedingt für besser lesbar..
    Ist mit wesentlich weniger Aufwand machbar ... wenn auch anstrengend.

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. Sellwerk GmbH & Co. KG, Düsseldorf
  2. Landesbetrieb für Hochwasserschutz und Wasserwirtschaft Sachsen-Anhalt (LHW), Magdeburg
  3. über duerenhoff GmbH, Raum Köln (Home-Office möglich)
  4. eco - Verband der Internetwirtschaft e.V., Köln

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. 32,95€
  2. 5,99€
  3. (-68%) 15,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Mobile Bezahldienste: Wie sicher sind Apple Pay und Google Pay?
Mobile Bezahldienste
Wie sicher sind Apple Pay und Google Pay?

Die Zahlungsdienste Apple Pay und Google Pay sind nach Ansicht von Experten sicherer als klassische Kreditkarten. In der täglichen Praxis schneidet ein Dienst etwas besser ab. Einige Haftungsfragen sind aber noch juristisch ungeklärt.
Von Andreas Maisch

  1. Anzeige Was Drittanbieter beim Open Banking beachten müssen
  2. Finanzdienstleister Wirecard sieht kein Fehlverhalten
  3. Fintech Wirecard wird zur Smartphone-Bank

Security: Vernetzte Autos sicher machen
Security
Vernetzte Autos sicher machen

Moderne Autos sind rollende Computer mit drahtloser Internetverbindung. Je mehr davon auf der Straße herumfahren, desto interessanter werden sie für Hacker. Was tun Hersteller, um Daten der Insassen und Fahrfunktionen zu schützen?
Ein Bericht von Dirk Kunde

  1. Alarmsysteme Sicherheitslücke ermöglicht Übernahme von Autos
  2. Netzwerkanalyse Wireshark 3.0 nutzt Paketsniffer von Nmap
  3. Sicherheit Wie sich "Passwort zurücksetzen" missbrauchen lässt

Geforce GTX 1660 im Test: Für 230 Euro eine faire Sache
Geforce GTX 1660 im Test
Für 230 Euro eine faire Sache

Die Geforce GTX 1660 - ohne Ti am Ende - rechnet so flott wie AMDs Radeon RX 590 und kostet in etwa das Gleiche. Der klare Vorteil der Nvidia-Grafikkarte ist die drastisch geringere Leistungsaufnahme.

  1. EC2 G4 AWS nutzt Nvidias Tesla T4 für Inferencing-Cloud
  2. Zotac Geforce GTX 1660 Ti im Test Gute 1440p-Karte für unter 300 Euro
  3. Nvidia Turing OBS unterstützt Encoder der Geforce RTX

  1. ULED: Ubiquitis Netzwerkleuchten bieten Wechselstromversorgung
    ULED
    Ubiquitis Netzwerkleuchten bieten Wechselstromversorgung

    Nach der Einführung der reinen PoE-Beleuchtung von Ubiquiti Networks bietet das US-Unternehmen jetzt auch Leuchten mit herkömmlicher Stromversorgung an. Für die Kommunikation mit Schaltern arbeiten sie mit einem alten WLAN-Standard.

  2. FTTH: Telekom und EWE gründen Glasfaser NordWest
    FTTH
    Telekom und EWE gründen Glasfaser NordWest

    Das Gemeinschaftsunternehmen von Telekom und dem Versorger EWE wird konkret. Stimmt das Kartellamt zu, sollen 2020 die ersten FTTH-Haushalte versorgt sein. Ziel sind 1,5 Millionen Haushalte und Firmen.

  3. Nasa: SLS scheitert auf Raten
    Nasa
    SLS scheitert auf Raten

    Die neue Schwerlastrakete der Nasa muss per Gesetz gebaut werden. Aber Missionen sollen auf andere Raketen umgebucht und Geld für die Weiterentwicklung gestrichen werden. Es war ein lange absehbares Desaster, das die Schwächen der heutigen Raumfahrt und ihre Angst vor der Technik zeigt.


  1. 14:40

  2. 14:20

  3. 14:00

  4. 13:20

  5. 13:00

  6. 12:28

  7. 12:04

  8. 11:25