1. Foren
  2. Kommentare
  3. Software-Entwicklung
  4. Alle Kommentare zum Artikel
  5. › Monster Madness: Erstes…

asm.js, der Fortschritt zum Rückschritt

  1. Thema

Neues Thema Ansicht wechseln


  1. asm.js, der Fortschritt zum Rückschritt

    Autor: twothe 13.12.13 - 12:56

    Das tatsächlich jemand die Ausdauer hatte, ein ganzes Spiel in asm.js zu machen finde ich bewundernswert, das das Schule macht halte ich aber für unwahrscheinlich. Dazu erst mal ein paar Basisinformationen, da ja das Halbwissen wieder wild kursiert.

    asm.js ist kein Wunderwerk und keine grundsätzlich neue Technik, es reduziert das JavaScript Sprachset nur auf einen sehr kleinen Teil, der dann - nach erfolgreicher Validierung - direkt 1:1 in nativen Code übersetzt werden kann. Der Vorteil ist erst mal offensichtlich, denn die Performance steigt deutlich an. Bis zu 50% von "echtem" nativen Code sind drin, dazu aber der Vorteil, dass solcher asm.js Code sehr stabile Performance liefert, was bedeutet das man ihn dahingehend auch gut debuggen kann.

    Der Nachteil liegt darin, dass der Programmierer quasi am ersten Compilierungs-Schritt vorbei programmieren muss, so dass keine unnötige Interpretation des Codes notwendig ist. Da dadurch nicht nur viele Sprachkonstrukte wegfallen, sondern auch besondere Konstrukte für eine exakte Notation angewendet werden muss, erinnert das Code-Ergebnis an irgendwas zwischen dem guten, alten Assembler und Brainfuck. Ein Beispiel:

    function f(x, y) {
    // SECTION A: parameter type declarations
    x = x|0; // int parameter
    y = +y; // double parameter

    // SECTION B: function body
    log(x|0); // call into FFI -- must force the sign
    log(y); // call into FFI -- already know it's a double
    x = (x+3)|0; // signed addition

    // SECTION C: unconditional return
    return ((((x+1)|0)>>>0)/(x|0))>>>0; // compound expression
    }

    function h(i, x) {
    i = i|0;
    x = x|0;
    H32[i>>2] = x; // shifted by log2(byte count)
    ftable_2[(x-2)&2](); // dynamic call of functions in table 2
    }

    Während der erste Teil sich noch im Bereich "ungewohnt" bewegt, sollte der untere Teil klar machen auf was man sich da einlässt. Übersichtlicher bzw. verständlicher Code ist das genaue Gegenteil, und wer das debuggen muss, der tut mir leid. Effektiv ist man also dank moderner Technologie wieder da, wo man vor 10 Jahren schon war: optimieren mittels Assembler, weil das System zu langsam ist, um verständlichen Code schnell genug auszuführen. Nur das wir heute von 4 GHz Systemen reden, und nicht mehr von 0,4 GHz.

    Wenn man jetzt für irgend ein Projekt aus irgendwelchen Gründen gezwungen ist unbedingt JS im Browser verwenden zu müssen, ok: dann ist asm.js eine gute Sache. Aber wenn nicht, dann sollte man sich daran besinnen, dass Debugging einen Großteil der Programmierung ausmacht, und je komplizierter der Code, um so länger verzögert sich die Auslieferung (und damit steigen die Projektkosten).

    asm.js ist also alles mögliche, aber sicherlich nicht der Heilsbringer für den Browser. Man darf sich auch zurecht fragen: wenn wir wieder so weit zurück müssen in der Entwicklung der Programmierung, dass wir wieder beim Assembler sind um anständige Performance zu erreichen, heißt das nicht umgekehrt, dass die Technologie die wir da zu verwenden versuchen eigentlich völlig ungeeignet ist? Meine Lieblingssprache LUA beispielsweise schafft mit LUAJit die gleiche Performance, allerdings bei völlig lesbarem und gut zu wartenden Code, ohne das man sich irgendwie einschränken müsste.

    Wenn mir asm.js irgendwas sagt, dann nur, dass es höchste Zeit wird sich von diesem JavaScript Unsinn abzuwenden, und stattdessen an der Verbreitung einer sinnvolleren Technologie arbeiten sollte. Google ist ja zum Glück mit Dart schon dran.

  2. Re: asm.js, der Fortschritt zum Rückschritt

    Autor: superhans 13.12.13 - 14:40

    Aber dir ist schon klar, dass die selbst keinen JS-Code schreiben, sondern ihren C++ Code in Js übersetzen lassen?
    Also ich gehe mal davon aus, dass das hier auch so war.

    Wenn es Probleme gibt und sie debuggen müssen, hast du natürlich recht.

  3. Re: asm.js, der Fortschritt zum Rückschritt

    Autor: Paykz0r 13.12.13 - 14:41

    ASM.JS ist ein compiler target wenn man so will.

    das schreibt man nicht per hand und dafür ist es auch nicht gedacht,
    um es kurz zu fassen.

    Die Unreal Engine wurde dahingehend portiert.
    Das Spiel dort wurde in C/C++ geschrieben und dann zusammen mit der Unreal Engine
    durch Ecmascripten in ASM.JS umgewandelt.

    Ich verstehe persönlich nicht was du dagegen hast oder warum man javascript abschaffen soll. ist doch kein zwang.hol dir noscript und surf damit.
    macht dir niemand ein vorwurf.
    aber versuch nicht die welt an javascript zu hindern.
    das sind hier ansätze von java web start und flash weg zukommen.
    das kann für höhere sicherheit sorgen und ein offeneres web.
    ich bin davon begeistert.

  4. Re: asm.js, der Fortschritt zum Rückschritt

    Autor: daZe 13.12.13 - 14:54

    > aber versuch nicht die welt an javascript zu hindern.
    > das sind hier ansätze von java web start und flash weg zukommen.
    > das kann für höhere sicherheit sorgen und ein offeneres web.
    > ich bin davon begeistert.

    Typische Aussage eines Technik-Trolls (benutzt du Apple Produkte? :-).
    Was der Poster sagt ist, dass solche JS-Entwicklungen "technisch gesehen" (!!) einen Rückschritt darstellt und ich kann dieser Aussage nur stark beipflichten. Jeder der, wie du, Unsinn á la "toll das Flash weg ist" oder "Tolles offenes Web" schreibt, hat selbst noch nie versucht komplexere Programme in JS zu schrieben (oder solche als Geldgeber zu finanzieren). JS ist und bleibt eine (zwar stark gepimpte) aber grundsätzlich "hässliche Scriptsprache" die auch ohne optimierten Code eine Zumutung (was das Code-Bild angeht) darstellt.

  5. Re: asm.js, der Fortschritt zum Rückschritt

    Autor: superhans 13.12.13 - 15:00

    JS ist eine hässliche Sprache, der es an einigen höheren Features fehlt, um große Applikationen zu schreiben. Nicht umsonst gibt es tausend Frameworks. Wird mit der nächsten Version zwar besser (endlich Module), aber viel schöner wird sie dadurch auch nicht. Es gibt da ein Youtube-Video in dem die "lustigsten" Design-Fehler zusammengefasst werden, finde ich gerade aber leider nicht :(

    Edit: Gefunden! https://www.destroyallsoftware.com/talks/wat



    1 mal bearbeitet, zuletzt am 13.12.13 15:08 durch superhans.

  6. Re: asm.js, der Fortschritt zum Rückschritt

    Autor: Paykz0r 13.12.13 - 15:08

    daZe schrieb:
    --------------------------------------------------------------------------------
    > > aber versuch nicht die welt an javascript zu hindern.
    > > das sind hier ansätze von java web start und flash weg zukommen.
    > > das kann für höhere sicherheit sorgen und ein offeneres web.
    > > ich bin davon begeistert.
    >
    > Typische Aussage eines Technik-Trolls (benutzt du Apple Produkte? :-).
    > Was der Poster sagt ist, dass solche JS-Entwicklungen "technisch gesehen"
    > (!!) einen Rückschritt darstellt und ich kann dieser Aussage nur stark
    > beipflichten. Jeder der, wie du, Unsinn á la "toll das Flash weg ist" oder
    > "Tolles offenes Web" schreibt, hat selbst noch nie versucht komplexere
    > Programme in JS zu schrieben (oder solche als Geldgeber zu finanzieren). JS
    > ist und bleibt eine (zwar stark gepimpte) aber grundsätzlich "hässliche
    > Scriptsprache" die auch ohne optimierten Code eine Zumutung (was das
    > Code-Bild angeht) darstellt.

    da liegst du völlig falsch.
    ich arbeite seit knapp 4 Jahren als reiner Javscript Frontend Enwickler,
    auch für sehr namenhafte Kunden.
    Vorher hab ich mit C/C++ 3 Jahre lang Nintendo DS spiele geschrieben.

    Das beides bald verbinden zu können ist der echte hammer und absolut kein rückschritt. Und mutmaße nicht ob ich ahnung habe oder nicht nur weil ich sag das ich ein offenes web will.

    Aber ich kann gerne noch mal ausweiten was ich meine.
    Ich hab beide Welten beruflich durchlebt. Hardware nahes C/C++ auf ein 33Mhz Gerät
    3d Games Entwickelt,
    und auf ein mal Beruf gewechselt zu reinen Javascript Anwendungsentwickler.
    Auch eine tolle Sache, aber eine komplett andere Welt.
    Da kam es viel mehr auf saubere Software Architektur an, weil die Web Apps immer weiter gepflegt werden müssen. Bei DS games war quasi nach dem Release eine fehlerfreien version alles egal. Hauptsache das Teillief flüssig auf der speziellen Hardware.

    Naja, man kann unter JS inzwischen richtige schön sauber Entwickeln.
    Dazu kann man sich bsw. mal ExtJS/Angular usw. anschauen.

    Was aber fehlte bisher ist eben die Hardwarenahen möglichkeiten.
    Nicht nur für Spiele. Auch für Steueranlagen, Heimsteuersysteme usw. kann das
    was hier gerade passiert von riesen Vorteil sein.
    Und das sag ich aus erfahrung, auch in diesen Sektoren bewege ich mich.
    Denkbar wären NodeJS Server die auf allen möglichen geräten mit webser laufen,
    und man kann von aussen (im selben wlan) mit den Browser (pc/tablets usw) drauf gehen und damit alles Zentral steuern.
    Alles dann quasi aus einer Hand.

    Backend in JS, Frontend in JS... man mit hilfe von Grunt kann man inzscieh sogar die Build Prozesse und das Deployment etc alles in JS machen.
    Zusätzlich dann noch ASM.JS Module die als Hardware Treiber dienen und dann geht das richtig ab.



    1 mal bearbeitet, zuletzt am 13.12.13 15:12 durch Paykz0r.

  7. Re: asm.js, der Fortschritt zum Rückschritt

    Autor: Paykz0r 13.12.13 - 15:15

    superhans schrieb:
    --------------------------------------------------------------------------------
    > JS ist eine hässliche Sprache, der es an einigen höheren Features fehlt, um
    > große Applikationen zu schreiben. Nicht umsonst gibt es tausend Frameworks.
    > Wird mit der nächsten Version zwar besser (endlich Module), aber viel
    > schöner wird sie dadurch auch nicht. Es gibt da ein Youtube-Video in dem
    > die "lustigsten" Design-Fehler zusammengefasst werden, finde ich gerade
    > aber leider nicht :(
    >
    > Edit: Gefunden! www.destroyallsoftware.com

    Da steht folgendes unter dme Video:
    "The sarcasm in this talk does not represent anyone's actual opinion. For a more serious take on software, try Destroy All Software Screencasts: 10 to 15 minutes every other week, dense with information on advanced topics like Unix, TDD, OO Design, Vim, Ruby, and Git."

    Das Video ist lustig, keine Frage.
    Kommt aber von Leuten die gerne mit diesen Technologien arbeiten.
    Das ist einfach mal Sarkasmus...

  8. Re: asm.js, der Fortschritt zum Rückschritt

    Autor: superhans 13.12.13 - 15:19

    Klar, ändert aber nichts daran, dass das Probleme der Sprache sind :D
    Jede Sprache hat so ihre Probleme, so auch Javascript. Aber wie schon gesagt, es gibt Gründe, warum es tausende von Frameworks gibt und auch Sprachen, die nach Javascript kompilieren (CoffeeScript, TypeScript, Dart, etc.pp).

  9. Re: asm.js, der Fortschritt zum Rückschritt

    Autor: Paykz0r 13.12.13 - 15:27

    superhans schrieb:
    --------------------------------------------------------------------------------
    > Klar, ändert aber nichts daran, dass das Probleme der Sprache sind :D
    > Jede Sprache hat so ihre Probleme, so auch Javascript. Aber wie schon
    > gesagt, es gibt Gründe, warum es tausende von Frameworks gibt und auch
    > Sprachen, die nach Javascript kompilieren (CoffeeScript, TypeScript, Dart,
    > etc.pp).

    Ja,
    das auf jeden fall.
    Gibt irre komische dinge die echt gewöhnungsbedüftig sind.
    Wenn man sich mal eine Wahrheitstabelle anschaut was in Javscript true oder false ist geht schon los. Aber das bsw. nimmt ein Coffecript usw. leider auch nciht alles ab.

    Gibt auf jeden Fall einige Pitfalls,
    aber auf der anderen Seite gibt es ziemlich geniale Sachen die nurmit solchen Sprachen gehen. Und davon ab: man kann fast alles in JS ändern was ein nicht passt!
    Ob das empfehlenswert ist, ist wieder eine andere Frage, aber die sprache ist so dynamisch und anpassbar... Das erfordert echtes Umdenken wenn man bsw. vorher C/C++ gemacht hat.
    Mir gefallen wie gesagt beide Seiten.
    Hat alles vor- und nachteile.
    Auch C hat einige hässlige sachen zu bieten,
    Java genau so. Andere Sprachen kann ich nicht beurteilen.

  10. Re: asm.js, der Fortschritt zum Rückschritt

    Autor: twothe 13.12.13 - 16:17

    Paykz0r schrieb:
    --------------------------------------------------------------------------------
    > Das Spiel dort wurde in C/C++ geschrieben und dann zusammen mit der Unreal
    > Engine durch Ecmascripten in ASM.JS umgewandelt.

    Das ist korrekt, ändert aber nichts an meiner Aussage. Ein weiteres Compile-Target ist nett, sagt aber gleichzeitig aus: "Programmier lieber nichts komplexes in JavaScript". Denn aus genau so einem Grund ist dieser Compiler erfunden worden, und aus dem gleichen Grund programmiert man heutzutage im Allgemeinen nicht mehr in Assembler.

    Was mich sehr stört sind eigentlich diese JavaScript Evangelisten, die sagen: "JavaScript ist toll und dank asm.js auch rasend schnell!" Dabei müsste es korrekt heißen: "JavaScript ist so langsam, dass asm.js erfunden werden musste, damit es noch einigermaßen flott läuft."

    Das is son bisschen so wie wenn man mit ner alten Ente auf die Autobahn will. Das geht nur, wenn man ein zweites Auto vorne dran schnallt das einen zieht. Jetzt ist es natürlich lustig so eine alte Ente zu fahren, und ich würds wahrscheinlich für den Gag auch machen, aber wenn ich realistisch und effizient denke, dann sollte ich die Ente in der Garage lassen und stattdessen den ziehenden Wagen fahren. Das Problem sind für mich dann die Leute, die mir dann erzählen so ne Ente ist eigentlich der beste Wagen des es gibt, und sogar unglaublich flott... wenn man nen Porsche vorne dran klemmt. Da fehlt es mir dann immer etwas an Verständnis.

    Mit dieser tiefgreifenden Symbolik... noch einen schönen Freitag. ;)

  11. Re: asm.js, der Fortschritt zum Rückschritt

    Autor: Paykz0r 13.12.13 - 18:34

    twothe schrieb:
    --------------------------------------------------------------------------------
    > Paykz0r schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Das Spiel dort wurde in C/C++ geschrieben und dann zusammen mit der
    > Unreal
    > > Engine durch Ecmascripten in ASM.JS umgewandelt.
    >
    > Das ist korrekt, ändert aber nichts an meiner Aussage. Ein weiteres
    > Compile-Target ist nett, sagt aber gleichzeitig aus: "Programmier lieber
    > nichts komplexes in JavaScript". Denn aus genau so einem Grund ist dieser
    > Compiler erfunden worden, und aus dem gleichen Grund programmiert man
    > heutzutage im Allgemeinen nicht mehr in Assembler.
    >
    > Was mich sehr stört sind eigentlich diese JavaScript Evangelisten, die
    > sagen: "JavaScript ist toll und dank asm.js auch rasend schnell!" Dabei
    > müsste es korrekt heißen: "JavaScript ist so langsam, dass asm.js erfunden
    > werden musste, damit es noch einigermaßen flott läuft."
    >
    > Das is son bisschen so wie wenn man mit ner alten Ente auf die Autobahn
    > will. Das geht nur, wenn man ein zweites Auto vorne dran schnallt das einen
    > zieht. Jetzt ist es natürlich lustig so eine alte Ente zu fahren, und ich
    > würds wahrscheinlich für den Gag auch machen, aber wenn ich realistisch und
    > effizient denke, dann sollte ich die Ente in der Garage lassen und
    > stattdessen den ziehenden Wagen fahren. Das Problem sind für mich dann die
    > Leute, die mir dann erzählen so ne Ente ist eigentlich der beste Wagen des
    > es gibt, und sogar unglaublich flott... wenn man nen Porsche vorne dran
    > klemmt. Da fehlt es mir dann immer etwas an Verständnis.
    >
    > Mit dieser tiefgreifenden Symbolik... noch einen schönen Freitag. ;)

    Naja, man muss differenzieren.
    Ich weiss warum JS so ein schlechten Ruf hat.
    Das hat viele Gründe.
    Einer ist bsw. das Firefox jahrelang bei jeder neuen Version geschrieben hat
    das JS so und so viel Prozent schneller geworden ist.
    Das stimmte auch, davon hat aber kein User was gemerkt.
    Woran lag das? Wenn du beispielsweise eine Animation in die Seite einbaust,
    triggert Javascript nur das CSS/HTML und die animation läuft. Egal wie schnell Javascript läuft, die Animation läuft ab da teils ruckelig. Und das liegt am HTML Renderer.
    Das andere Ding warum viele JS kritisieren sind browser unterschiede.
    Auch das liegt nicht an JS als Sprache. ECMASCRIPT ist genau definiert.
    Das MS beispielweise die Eventlistener anders nennt als Firefox,
    dafür kann die sprache nix.

    Wer sich das reinste JS anschaut (z.b. Serverseitig durch NodeJS)
    wird feststellen das JS sehr konsistent und schön sein kann.

    Ein weiter Grund ist teils JQuery und seine Plugins.
    Die schiessen sich teils gegenseitig ins aus und man ist oft besser dran
    dinge einfach selber zu implementieren.

    Und zu aller guter letzt:
    JS ist nur so gut wie seine Entwickler.
    Da die meisten aber ursprünglich aus der klassischen Web Gestaltung irgendwie
    zum JS Entwickler wurden, hat auch seine Auswirkungen.
    Richtige Programmierer die Design Patterns drauf haben findet wirklich
    in den aller wenigsten Agenturen. Und ich weiss wovon ich rede,
    ich werde zu solchen Firmen immer hin vermietet und spiel die Feuerwehr
    wenn da kurz vorm Release alles nur rotz ist.

    Und wenn man dann sieht wie die da arbeiten,
    scripte einbinden und nicht mal wissen das nicht garantiert ist in welcher reinfolge die geladen werden, aber auch abhängigkeiten dort aufbauen von der hässligsten sorte wunder mich nix. Auch nicht deine aussage,
    man könne keine komplexe Projekte damit umsetzen.

    Dem ist aber nicht so.
    Das kann man nicht nur,
    das machen viele am laufenden Band.
    Und mit den richtigen Frameworks (Extjs kann ich nur sehr empfehlen!)
    hat man NIX mit Browserunterschieden zu tun.
    Im Falle von ExtJS schreibt man nicht mal html/css.
    Man verschachtelt nur Widgets mit JSON und schreibt controller und stores dazu.
    Und das läuft einfach mal in jeden Browser gleich.

    Da kann man so hochqualitativen kram mit bauen.
    Aber die meisten wissen das nicht und springen in die Jquery hölle.
    Das liegt aber alles nicht an der Sprache.
    JS hat wie gesagt seine Sprachlichen Pitfalls.
    Die sind aber meist nicht das Problem sondern eher die ahnungslosigkeit der Entwickler.



    1 mal bearbeitet, zuletzt am 13.12.13 18:36 durch Paykz0r.

  12. Re: asm.js, der Fortschritt zum Rückschritt

    Autor: mag 13.12.13 - 18:58

    Ich bin der Meinung, dass die Betrachtungsweise nicht die Philosophie hinter asm.js wiedergibt. Besser wäre es, erst einmal gedanklich zu sagen: "Javascript und asm.js sind zwei ganz verschiedene Dinge."

    asm.js ist im Prinzip der Bytecode einer virtuellen Maschine. Und der wird genausowenig direkt geschrieben wie Bytecode für die JVM, .NET. Statt dessen wird fast ausnahmslos eine höhere Programmiersprache genutzt und in Bytecode kompiliert.

    Ein Browser, der spezielle Unterstützung für asm.js mitbringt, behandelt solchen Code ja auch anders als Javascript-Code (insbesondere Vorkompilierung vs. Just-In-Time), erst das erlaubt ja die vergleichsweise hohe Performance. Der Gag an der Geschichte ist halt, dass man die Bytecoderepräsentation so gewählt hat, dass sie nebenbei auch ein valides Javascript-Programm darstellt, und deshalb als Notbehelf auch in Browsern ausgeführt werden kann, die keine gesonderte Unterstützung für asm.js bieten.

    Ich ganz persönlich bin der Meinung, dass diese Idee weniger genial ist als sie im ersten Moment klingt und bevorzuge die Einführung einer von Grund auf neu definierten, browserübergreifenden, offenen und standardisierten virtuellen Maschine. Diese hätte den Vorteil, eben nicht mit JavaScript und dadurch mit der nachgesagten schlechten Performance assoziiert zu werden. Dass asm.js-Code auch auf Browsern ohne spezielle Unterstützung (dann potenziell mit wirklich schlechter Performance) lauffähig ist, birgt darüber hinaus die Gefahr, dass sich dieses Vorurteil sogar noch durch tatsächliche Nutzererfahrungen verstärkt. Aber das ist meine persönliche Meinung, und ich erkenne an, dass der gewählte Weg natürlich einfacher zu einer nenneswerten Verbreitung führt. Das zeigt z.B. PNaCl, dass ja in der Tat eine neue virtuelle Maschine darstellt, aber bislang wenig Anklang findet.

    Was hingegen (zumindest nach meinem Kenntnisstand) aktuell wirklich katastrophal ist, ist die Lage bzgl. Debugging. Da asm.js eben nur oberflächlich betrachtet Javascript ist, hilft ein Javascript-Debugger hier nicht im geringsten weiter. Das ist vergleichbar mit einem Java-Debugger, der nur Bytecode und nur interne System-IDs statt Variablennamen anzeigen kann. Ohne Debugger, die den Systemzustand aus dem Browser auf den ursprünglichen hochsprachigen Code zurückmappen können, ist eine direkte Entwicklung für asm.js-Targets quasi nicht machbar. Das wird wohl auch der Grund sein, warum es bisher vornehmlich nur Portierungen gibt. Der Code ist auf einer anderen Plattform getestet und läuft, und dann wird er halt nach asm.js kompiliert und man hofft auf das beste. Sollte sich die Lage hier gebessert haben, darf man nich gern korrigieren. ;)

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Windows-Systemadministrator (m/w/d)
    Hays AG, Wiesbaden
  2. Technical Consultant ServiceNow (m/w/d)
    operational services GmbH & Co. KG, Frankfurt am Main, Berlin, Dresden, München
  3. Sachbearbeiterinnen / Sachbearbeiter IuK-Koordination (w/m/d)
    Der Polizeipräsident in Berlin, Berlin
  4. Leiter Anwendungsentwicklung (m/w/d)*
    über Dr. Richter Heidelberger GmbH & Co. KG, Rhein-Neckar-Kreis

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. (u. a. Fallout 76 für 12,50€, Wolfenstein II: The New Colossus für 11€, Dishonored: Death of...
  2. 8,99€
  3. 29,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Probleme mit Agilität in Konzernen: Agil sein muss man auch wollen
Probleme mit Agilität in Konzernen
Agil sein muss man auch wollen

Ansätze wie das Spotify-Modell sollen großen Firmen helfen, agil zu werden. Wer aber erwartet, dass man es überstülpen kann und dann ist alles gut, der irrt sich.
Ein Erfahrungsbericht von Marvin Engel


    Neues Apple TV 4K im Test: Teures Streaming-Gerät mit guter Fernbedienung
    Neues Apple TV 4K im Test
    Teures Streaming-Gerät mit guter Fernbedienung

    Beim neuen Apple TV 4K hat sich Apple eine ungewöhnliche Steuerung einfallen lassen, die aber im Alltag eher eine Spielerei ist.
    Ein Test von Ingo Pakalski

    1. Shareplay TVOS 15 soll gemeinsame Streaming-Erlebnisse schaffen
    2. Apple TV Farbkalibrierung per iPhone schneidet schlecht ab
    3. Sofasuche beendet Airtag-Hülle für Apple-TV-Fernbedienung

    Early Access: Spielerisch wertvolle Baustellen
    Early Access
    Spielerisch wertvolle Baustellen

    Vor allen anderen spielen, bei der Entwicklung mitmachen: Golem.de stellt besonders spannende Early-Access-Neuheiten vor.
    Von Rainer Sigl

    1. Hype auf Steam Mehr als 500.000 Menschen spielen Valheim
    2. Hype auf Steam Warum ist Valheim eigentlich so beliebt?
    3. Nur für echte Gamer Die besten Spiele-Geheimtipps 2020