Abo
  1. Foren
  2. Kommentare
  3. Applikationen
  4. Alle Kommentare zum Artikel
  5. › TV-Oberfläche: Wie Netflix seine…

Ich würde es mal ganz ohne JavaScript probieren.

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


  1. Ich würde es mal ganz ohne JavaScript probieren.

    Autor: Sinnfrei 13.01.17 - 12:48

    Damit sinkt die Renderzeit garantiert. Dieser ganze JavaScript Framework Bullshit wird langsam genauso schlimm wie Flash.

    __________________
    ...

  2. Re: Ich würde es mal ganz ohne JavaScript probieren.

    Autor: dabbes 13.01.17 - 12:52

    Frei nach Dieter Nuhr: einfach mal die.... ... wenn man offensichtlich keine Ahnung von der Materie hat.

  3. Re: Ich würde es mal ganz ohne JavaScript probieren.

    Autor: EnemyArea 13.01.17 - 13:07

    dabbes schrieb:
    --------------------------------------------------------------------------------
    > Frei nach Dieter Nuhr: einfach mal die.... ... wenn man offensichtlich
    > keine Ahnung von der Materie hat.

    du weißt, dass man sich selber damit meint, ja?

  4. Re: Ich würde es mal ganz ohne JavaScript probieren.

    Autor: waswiewo 13.01.17 - 13:33

    Ach ja? Was würdest du denn dann auf Smart TVs, die entweder mit eigenen OSen oder Android laufen, sonst so verwenden?

  5. Re: Ich würde es mal ganz ohne JavaScript probieren.

    Autor: Gandalf2210 13.01.17 - 13:41

    Python.
    Oder C++. Klappt auf dem PC ja auch

  6. Re: Ich würde es mal ganz ohne JavaScript probieren.

    Autor: ecv 13.01.17 - 13:42

    waswiewo schrieb:
    --------------------------------------------------------------------------------
    > Ach ja? Was würdest du denn dann auf Smart TVs, die entweder mit eigenen
    > OSen oder Android laufen, sonst so verwenden?


    Natürlich ausschließlich Hardcore Assembler auf jedes einzelne Gerät angepasst für die letzte Nanosekunde speed!

    Solange es keine einheitliche Hardware gibt ist so ein layer schon ganz richtig. Und Javascript ist doch eine gute Wahl, es wird von zigtausenden Menschen entwickelt und verbessert und von Millionen genutzt. Sollte passen.

  7. Re: Ich würde es mal ganz ohne JavaScript probieren.

    Autor: waswiewo 13.01.17 - 13:43

    Und woher willst du wissen, ob das auf den idR proprietären Systemen der unzähligen Smart TVs in der Welt funktioniert?

  8. Re: Ich würde es mal ganz ohne JavaScript probieren.

    Autor: waswiewo 13.01.17 - 13:44

    Mir ist das klar, dem OP scheinbar nicht.

  9. Re: Ich würde es mal ganz ohne JavaScript probieren.

    Autor: rw 13.01.17 - 13:45

    Genau ich installier mir auf meiner Windowskiste auch immer die Mac-Versionen, weil die so ne schöne Oberfläche haben.

  10. Re: Ich würde es mal ganz ohne JavaScript probieren.

    Autor: Quantium40 13.01.17 - 13:45

    Sinnfrei schrieb:
    > Damit sinkt die Renderzeit garantiert. Dieser ganze JavaScript Framework
    > Bullshit wird langsam genauso schlimm wie Flash.

    Ganz ohne Javascript wird das auf SmartTVs wohl eher nicht funktionieren, da die sogeannten Apps dort eigentlich nur Webseiten auf Basis von leicht modfiziertem HTML5+Javascript (und bei einigen Geräten auch Flash) sind, wobei diese Zugriff auf die API des SmartTVs haben, und darüber z.B. die Fernbedienung besser nutzen können.

  11. Re: Ich würde es mal ganz ohne JavaScript probieren.

    Autor: Sinnfrei 13.01.17 - 14:00

    "Verbessert" ist relativ. 99% von den Frameworks sind total unnötiger overkill, und für 99% der Fälle bei denen sie genutzt werden, würde auch einfach HTML+CSS ausreichen. 75% der Seiten welche diese Frameworks einsetzen sind grausam langsam, und 25% sind praktisch kaum nutzbar.

    __________________
    ...

  12. Re: Ich würde es mal ganz ohne JavaScript probieren.

    Autor: Desktopupser 13.01.17 - 14:01

    Gute Idee! Und auch ohne CSS, das muss ja auch erstmal runtergeladen und gerendert werden - wofür?

    Und wenn das nicht hilft, dann vielleicht einfach schwarzweiß statt Farbe. Bringt bestimmt auch was

  13. Re: Ich würde es mal ganz ohne JavaScript probieren.

    Autor: Sammie 13.01.17 - 14:17

    Na so Unrecht hat er damit auch wieder nicht.

    Frameworks erleichtern zwar die Entwicklung ungemein, aber auf die Performance haben sie in aller Regel immer einen deutlich negativen Effekt, durch die ganzen Kompatibiltätstests und unnötigen Funktionsaufrufe.

    Die meisten Frameworks sind eh überladen und kaum eine Anwendung benötigt auch nur 5% der Funktionen, die man auch genauso selbst schreiben könnte. Ein Framework kann nie so schnell arbeiten, wie pures Javascript, da immer unnötiger function-Overhead entsteht.

    Hab grad mal nach nem Performance-Test gegoogled, der das createElement-Problem aufzeigt: https://jsperf.com/react-vs-raw-dom-manipulation/29
    Da hab ich auf nem einfachen Rechner im aktellen Chrome 11 Ops/sec bei React, 36 bei Query und 460 bei purem Javascript. Die Frameworks sind da einfach nur gähnend langsam. 460 vs 11 ist schon ne Hausnummer.

    Wenn man in deren Blog schon liest, dass sie Babel-Transpiler einsetzen usw und erst hinterhermerken, dass der Murkscode produziert, der sie dann dazu zwingt, React selbst so zu modifizieren, so dass die unnötigen Funktionsaufrufe wegfallen, da hätten sies auch gleich selbst ohne das Framework scripten können. Wem es wirklich primär um Performance geht, sollte auf Frameworks verzichten.

    Genauso wie sie da erklären, wie sie nachträglich am __proto__ an bereits erstellen Objecten rumpfuschen ("When this happens the prototype chain approach only works if the __proto__ is assigned after the newProps object is created. ") usw. Das beträfe auch das neuere setPrototypOf, von dessen Verwendung auch Mozilla explizit abrät: "[[Prototype]] mutation harms performance in all modern JavaScript engines".

    Eine Anwendung, die zur Laufzeit die Prototype-Chain verändert, verliert grundsätzlich jede Performance-Optimierung in allen gängigen Javascript-Engines und wird dadurch unheimlich langsam. Performant laufen nur Prototyp-Chains, die beim Start der Anwendung einmalig initialisiert wurden und vom Compiler optimiert im Speicher verweilen. Aber den Fehler machen viele Entwickler, die von höheren Programmiersprachen kommen und sich in der Prototype-Welt von Javascript zurechtfinden müssen und kein typisches Klassen-Extending vorfinden. Da ändert auch ES6, der neue Fake-class-Syntax nichts daran, dass Javascript unter der Haube immer Prototype-basierend bleibt. Wer nachträglich die Prototypes bereits erstellter Objekte manipuliert, bremst seine Anwendung immer massiv aus und sollte seinen Coding-Stil einfach mal überdenken.

    * https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/setPrototypeOf
    * https://developer.mozilla.org/de/docs/Web/JavaScript/Reference/Global_Objects/Object/proto
    * https://developer.mozilla.org/en-US/docs/Web/JavaScript/The_performance_hazards_of__%5B%5BPrototype%5D%5D_mutation

  14. Re: Ich würde es mal ganz ohne JavaScript probieren.

    Autor: Geistesgegenwart 13.01.17 - 14:19

    Sinnfrei schrieb:
    --------------------------------------------------------------------------------
    > "Verbessert" ist relativ. 99% von den Frameworks sind total unnötiger
    > overkill, und für 99% der Fälle bei denen sie genutzt werden, würde auch
    > einfach HTML+CSS ausreichen. 75% der Seiten welche diese Frameworks
    > einsetzen sind grausam langsam, und 25% sind praktisch kaum nutzbar.

    99% der Zahlen in Statistiken im Internet sind frei erfunden (Wer kennt den Namen dieses Gesetztes?) - so auch deine vollkommen willkürlichen Zahlen.

    Ich verdiene überwiegend mit JavaScript Entwicklung mein Geld und kann dir sagen dass die meisten Frameworks kein Overkill sind - schon dann nicht mehr, wenn deine Codebase die 10-20k Zeilen überschreitet. Das du für eine Landing Page mit 2 Buttons die ein Modal anzeigen sollen natürlich keinen fetten Stack brauchst ist klar. Aber einer gewissen Komplexität bist du aber für jedes Stück Code dankbar, dass es dir erlaubt Komplexität zu reduzieren oder besser zu managen.

  15. Re: Ich würde es mal ganz ohne JavaScript probieren.

    Autor: MarcelLambacher 13.01.17 - 15:13

    Vue.js - deutlich schlanker als Angular und die anderen Konsorten.
    Ist kein ganzes Framework, sondern lediglich eine schlanke und schnelle View-Library.

    https://vuejs.org/v2/guide/

  16. Re: Ich würde es mal ganz ohne JavaScript probieren.

    Autor: maze_1980 13.01.17 - 15:16

    Probier das doch mal. Da musst Du jedesmal die Seite neu laden wenn Du etwas anderes darstellen willst. Ob das Begeisterung bei den Nutzern auslöst? Es ist sicher ein ganz neues Erlebnis für viele Junge!

  17. Re: Ich würde es mal ganz ohne JavaScript probieren.

    Autor: maze_1980 13.01.17 - 15:39

    Sie nutzen eine alte Javascript-Engine ohne Compiler. Da kann man auch an props rumändern.
    Diese Engine Engine der Hauptgrund dass es langsam ist. Aber bei älteren Geräten können sie diese ja nicht tauschen, also bleiben sie dabei und optimieren dann für diese Engine das Javascript so weit es geht.

  18. Re: Ich würde es mal ganz ohne JavaScript probieren.

    Autor: GottZ 13.01.17 - 15:54

    Sammie schrieb:
    --------------------------------------------------------------------------------
    > Die meisten Frameworks sind eh überladen und kaum eine Anwendung benötigt
    > auch nur 5% der Funktionen, die man auch genauso selbst schreiben könnte.
    > Ein Framework kann nie so schnell arbeiten, wie pures Javascript, da immer
    > unnötiger function-Overhead entsteht.
    ja das passiert schon mal wenn man ein framework auswählt weil es hip ist und nicht weil man es braucht.

    Sammie schrieb:
    --------------------------------------------------------------------------------
    > Hab grad mal nach nem Performance-Test gegoogled, der das
    > createElement-Problem aufzeigt: jsperf.com
    > Da hab ich auf nem einfachen Rechner im aktellen Chrome 11 Ops/sec bei
    > React, 36 bei Query und 460 bei purem Javascript. Die Frameworks sind da
    > einfach nur gähnend langsam. 460 vs 11 ist schon ne Hausnummer.
    ist zwar richtig, mit innerHTML kannste aber noch mehr elemente in weniger zeit erzeugen.
    es ist je nach anwendungsfall wirklich weit performanter 10k elemente mit nem stringbuilder zusammen zu kleben und in innerHTML zu schmeißen als sie per DOM einzeln zu erstellen.
    (der grund sollte klar sein.. bei innerHTML bekommt man keine node references zurück was auch der primäre geschwindigkeitsboost ist)
    oh wait.. viele nennen sowas shadow dom etc. und machen globale event listener statt node listener… nicht dass sich framework devs bei ihrem zeug noch was dabei denken.
    aber ja du hast recht. in der regel hat davon keiner ahnung und jeder abstrahiert es irgendwie weg um nicht damit konfrontiert zu werden. traurig aber wahr.

    ich muss aber noch einen drauf setzen:
    jsperf ist ne sehr sehr schlechte referenz.
    kannst ja mal Mathias Bynens dazu fragen was er von micro benchmarks hält. (ist btw der erfinder von jsperf.com) oh wait er hat nen beitrag dazu in seinem blog: https://mathiasbynens.be/notes/javascript-benchmarking

    Sammie schrieb:
    --------------------------------------------------------------------------------
    > Wenn man in deren Blog schon liest, dass sie Babel-Transpiler einsetzen usw
    > und erst hinterhermerken, dass der Murkscode produziert, der sie dann dazu
    > zwingt, React selbst so zu modifizieren, so dass die unnötigen
    > Funktionsaufrufe wegfallen, da hätten sies auch gleich selbst ohne das
    > Framework scripten können. Wem es wirklich primär um Performance geht,
    > sollte auf Frameworks verzichten.
    oder selber eins schreiben xD
    oh wait… wie sind react, ember, angular etc. nur entstanden…

    Sammie schrieb:
    --------------------------------------------------------------------------------
    > Genauso wie sie da erklären, wie sie nachträglich am __proto__ an bereits
    > erstellen Objecten rumpfuschen ("When this happens the prototype chain
    > approach only works if the __proto__ is assigned after the newProps object
    > is created. ") usw. Das beträfe auch das neuere setPrototypOf, von dessen
    > Verwendung auch Mozilla explizit abrät: "[] mutation harms performance in
    > all modern JavaScript engines".
    klarer fall von devs die sich nicht als javascript gurus bezeichnen dürften…

    Sammie schrieb:
    --------------------------------------------------------------------------------
    > Eine Anwendung, die zur Laufzeit die Prototype-Chain verändert, verliert
    > grundsätzlich jede Performance-Optimierung in allen gängigen
    > Javascript-Engines und wird dadurch unheimlich langsam. Performant laufen
    > nur Prototyp-Chains, die beim Start der Anwendung einmalig initialisiert
    > wurden und vom Compiler optimiert im Speicher verweilen. Aber den Fehler
    > machen viele Entwickler, die von höheren Programmiersprachen kommen und
    > sich in der Prototype-Welt von Javascript zurechtfinden müssen und kein
    > typisches Klassen-Extending vorfinden. Da ändert auch ES6, der neue
    > Fake-class-Syntax nichts daran, dass Javascript unter der Haube immer
    > Prototype-basierend bleibt. Wer nachträglich die Prototypes bereits
    > erstellter Objekte manipuliert, bremst seine Anwendung immer massiv aus und
    > sollte seinen Coding-Stil einfach mal überdenken.
    jain. die interne struktur von es6 klassen ist in chrome eine andere als die prototype chain. siehe debugger oder sourcecode. (muss man ja nicht zwingend wissen)
    aber ich weis worauf du hinaus willst. viele raffen halt nicht dass javascript eine reine oop sprache ist und klassen sowie blocking operations in der js welt überflüssig sind.

    Sammie schrieb:
    --------------------------------------------------------------------------------
    > * developer.mozilla.org
    > * developer.mozilla.org
    > * developer.mozilla.org
    isso. beste.
    finger weg von w3schools kinder!

    el signature



    1 mal bearbeitet, zuletzt am 13.01.17 15:59 durch sfe (Golem.de).

  19. Re: Ich würde es mal ganz ohne JavaScript probieren.

    Autor: Geistesgegenwart 13.01.17 - 16:43

    > es ist je nach anwendungsfall wirklich weit performanter 10k elemente mit
    > nem stringbuilder zusammen zu kleben und in innerHTML zu schmeißen als sie
    > per DOM einzeln zu erstellen.

    Aha, und deswegen schreibst du deinen HTML Code nicht in Templates/JSX sondern klebst die Tags in Strings in StringBuildern in deinen Code und dann fügst den batzen via .innerHTML ein? Schnell ist das bestimmt, aber wartbar? Der Designer der dir zuarbeitet in dem 6 Mann Team im Großprojekt, versteht das auch? Die Events die auf den HTMLNodes liegen, fügst du danach händisch ein oder wie?

    Und bei Änderung der Daten, egal ob durch 2-Wege Bindung oder extern z.B. von ner Redux Action - wiederholst den ganzen StringBuilding Prozess und ersetzt die Daten im String dann mit ner Regex? Das geht bestimmt, aber den Code wollte ich nicht anfassen müssen...

    Und wenn du das ganze jetzt noch weiter treibst, und anstatt Strings dir eigene Datenstrukturen überlegst um dein HTML baumartig zu repräsentieren und nur an diesen Strukturen gezielt Änderungen machst und wenn diese Änerungen passieren wird in diskreten Abständen einfach alles komplett neu eingefügt... schwups dann hast du React nachprogrammiert :)

    Ist doch vollkommen klar das manche Seiten ohne JS auskommen. Wikipedia ist so ein Beispiel, hier würde kein Mensch React/Angular oder sonstwas nehmen. Das ist als Backend-Rendered Applikation gut und wird nur mit ein bisschen JS angereichert. Wer aber moderne Webapps schreibt (oder Tabletapps z.B. mit Ionic) der wird recht schnell dankbar sein dass das Framework ihm manche Sachen abnimmt.

  20. Re: Ich würde es mal ganz ohne JavaScript probieren.

    Autor: redmord 13.01.17 - 18:05

    Du blamest die Technologie wegen schlechter Entwickler? *applaus* ;-)

  1. Thema
  1. 1
  2. 2

Neues Thema Ansicht wechseln


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

Stellenmarkt
  1. SAPCORDA SERVICE GmbH, Hannover
  2. DRÄXLMAIER Group, Vilsbiburg bei Landshut
  3. LEW Service & Consulting GmbH, Augsburg
  4. Stadtwerke München GmbH, München

Golem pur
  • Golem.de ohne Werbung nutzen

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


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

Indiegames-Rundschau: Epische ASCII-Abenteuer und erlebnishungrige Astronauten
Indiegames-Rundschau
Epische ASCII-Abenteuer und erlebnishungrige Astronauten

In Stone Story RPG erwacht ASCII-Art zum Leben, die Astronauten in Oxygen Not Included erleben tragikomische Slapstick-Abenteuer, dazu kommen Aufbaustrategie plus Action und Sammelkartenspiele: Golem.de stellt neue Indiegames vor.
Von Rainer Sigl

  1. Indiegames-Rundschau Von Bananen und Astronauten
  2. Indiegames-Rundschau Verloren im Sonnensystem und im Mittelalter
  3. Indiegames-Rundschau Drogen, Schwerter, Roboter-Ritter

Nachhaltigkeit: Jute im Plastik
Nachhaltigkeit
Jute im Plastik

Baustoff- und Autohersteller nutzen sie zunehmend, doch etabliert sind Verbundwerkstoffe mit Naturfasern noch lange nicht. Dabei gibt es gute Gründe, sie einzusetzen, Umweltschutz ist nur einer von vielen.
Ein Bericht von Werner Pluta

  1. Nachhaltigkeit Bauen fürs Klima
  2. Autos Elektro, Brennstoffzelle oder Diesel?
  3. Energie Wo die Wasserstoffqualität getestet wird

  1. Elektroauto: Porsches Elektroauto Taycan im 24-Stunden-Dauertest
    Elektroauto
    Porsches Elektroauto Taycan im 24-Stunden-Dauertest

    Wie funktioniert das Fahrzeug bei hohen Temperaturen? Wie das Laden? Um das auszuprobieren, hat Porsche sein Elektroauto Taycan einen Tag lang rund um eine Teststrecke in Süditalien gejagt.

  2. WD Black P50 Game Drive: Schnelle USB-3.2-Gen2x2-SSD für Spieler
    WD Black P50 Game Drive
    Schnelle USB-3.2-Gen2x2-SSD für Spieler

    Western Digital stellt seine erste externe SSD mit dem neuen USB-Standard USB 3.2 Gen2x2 vor. Damit sind Datenraten von theoretisch 20 GBit/s oder 2,5 GByte pro Sekunde möglich. Die intern verbaute SSD hat jedenfalls das Potenzial zur Ausreizung.

  3. Pro Trek: Casio stellt Outdoor-Smartwatch mit Pulsmesser vor
    Pro Trek
    Casio stellt Outdoor-Smartwatch mit Pulsmesser vor

    Casios neue Pro-Trek-Smartwatch WSD-F21HR kommt erstmals mit einem Pulsmesser, der automatisch bei Bewegung aktiviert werden kann. Die Uhr ist an Outdoor-Fans gerichtet: Unter anderem lassen sich Karten offline direkt auf der Uhr verwenden, auch Casios duales Display ist an Bord.


  1. 14:42

  2. 14:16

  3. 13:46

  4. 12:58

  5. 12:40

  6. 12:09

  7. 11:53

  8. 11:44