Schepp, Peter und Anselm erklären nochmal, was beim npm-Gate so abging und warum wir endlich mal vorher nachdenken sollten, wie wir Tools und Workflows aufbauen, statt erst dann, wenn es zu spät ist. Und danach nehmen wir uns gleich noch ein Thema vor, was nach wie vor spannend bleibt: Warum bauen wir so lahme Seiten, vor allem für mobile Endgeräte?
[00:00:11] News
- Developers can run Bash Shell and user-mode Ubuntu Linux binaries on Windows 10
- Was sollen wir noch dazu sagen, außer: Endlich! Und: Das ist großartig!
Schaunotizen
- [00:00:47] Left-Pad / npm-Gate
- Der Entwickler eines npm Moduls für eine Left-Pad Function hat selbiges ge-unpublished und damit das halbe Internet kaputt gemacht. Da leider Babel und viele andere Projekte dieses als Dependency verwendeten, schlugen sofort alle CI Systeme fehl. Daraus entstand eine hitzige Debatte um kleine Module in JavaScript, npm und Workflows an sich. Wir sprechen darüber und versuchen herauszufinden, wie wir robustere Workflows bauen können ohne Module nur zu copy-pasten. Seitdem gibt es eine neue npm unpublish policy, Lösungs-Ansätze und auch direkt neue npm Problemchen. Aber da wäre ja auch noch Bower und auch sowas wie das relativ unbekannte IPFS, was sich ziemlich gut als distributed package manager eignen würde.
- [00:28:38] The Chrome Distortion: how Chrome negatively alters our expectations.
- Diesen doch sehr fraglichen Artikel-Titel haben wir zum Anlass genommen, zu hinterfragen, warum wir überhaupt feststellen können, dass mobile Browser langsam sind und ob das überhaupt die Ursache des Problems ist? Wir kommen selbstverständlich zu einem ganz anderen Schluss, denn wir bauen einfach immer unnötig größere Seiten, mit vielen unnötigen Spielereien. Trotzdem versuchen wir, unsere Verantwortung dann am Ende auf die Browser zu schieben, einfach um uns besser zu fühlen. Letztendlich sprechen wir auch noch über Projektmanagement und Verantwortung als Entwickler, sowie Hardware, die Nicht-Entwickler besitzen.
- link rel=noopener
- Ein neues Attribut, um zu verhindern, dass
window.openerdurch nutzergenerierten Inhalt missbraucht werden kann. - A kick-start into server push
- Ein leicht verständlicher Artikel zum Thema Server Push.
- Node.green
- Eine coole tabellarische Aufstellung, welches ECMA-Script Feature in welcher Node Version unterstützt wird.
- Referrer and cache control APIs for
fetch() - Auch wenn es noch ein klein wenig dauert, bis zum Firefox 48 Release, finden wir diese Features äußerst hilfreich und ihr könnt gleich mal anfangen, das zu nutzen.
[01:28:48] Keine Schaunotizen
Kommentare
Puddingpulver #
Geschrieben am 17.04.2016 um 20:34
Hallo,
zu dieser Episode sind mir doch einige Dinge aufgefallen, die ich hier gerne zum besten geben möchte.
1. Zum Thema Package Manager: Da gibt es doch in fast jeder Programmiersprache bessere Lösungen, die weniger Fehleranfällig sind. Beispiel ist hier sicher Maven (Java), NuGet (C#) und selbst C ist da glaube ich weiter. PHP ist bestimmt kein gutes Beispiel. Wichtig dabei sind aber auch die Regeln, die jede Firma für den Umgang mit Bibliotheken haben sollte. In der Regel, werden die Libs in einem eigenen Repository geladen und von dort aus an die Entwickler verteilt (Beispiel Nexus). Klar ist auch, dass dort dann nicht jede Libs aufgenommen wird un die Lib vorher auf geprüft wird z.B. auf Viren, doppelte Funktion, Kompatibilität usw.. Bis jetzt hat jede Firma bei der ich war, mit einem solchen Toolset gearbeitet und ich denke, für eine halbwegs Professionelle Umgebung ist das auch der Standard.
2. AngularJS, EmberJS und React
Mir fällt immer wieder auf, dass ihr nicht begeistert von MVC Frameworks seit. Ich finde die Client-basierten Frameworks sehr gut und wenn ich mir JSF,PHP oder ASP ansehe ist das Zeug im Vergleich ein Geschenk des Himmels. Dann Fällt mir auf, dass ihr davon redet, die JavaScript basierte MVC Frameworks für Webseiten zu verwenden. Das ist natürlich kompletter Schwachsinn. MVC Frameworks sind für die Entwicklung von Anwendungen gedacht und nicht für Webseiten. In der Anwendungsentwicklung machen diese Framworks auch Sinn, da der Benutzer die Anwendung für längere Zeit benutzt (z.B. für Experten Systeme in der Verwaltung bei Versicherungen, Banken oder Touristik), da ist die Ladezeit mal absolut egal. Wer jedoch für eine Webseite ein MVC Framework verwendet, dem ist nicht mehr zu helfen. Also wenn über JavaScript basierte MVC Framworks gesprochen wird, bitte etwas genauer differenzieren. Eine Einordnung, in welchem Kontext jetzt genau über den Einsatz von MVC gesprochen wird. Bei Webseiten braucht man nicht über MVC zu sprechen, da Webseiten kein Einsatzgebiet für MVC sind.
Anselm Hannemann #
Geschrieben am 18.04.2016 um 08:40
Danke dir für den Input!
Ich glaube, damit hast du es genau auf den Punkt getroffen. Das eine bedingt das andere. Da wir in der Front-End Welt bisher nie mit solchen Toolsets gearbeitet haben und die meisten Entwickler auch nicht aus der Anwendungsprogrammierung kommen, ist das Gebiet Package Management noch sehr neu. Das sehe ich für die Seite der Anbieter so (npm, bower, etc), als auch noch viel stärker auf Seite der Anwender (wir). Ich habe zumindest noch nie erlebt, dass man sich im Bereich JavaScript die Zeit nimmt, ein npm Modul ausgiebig anzusehen, auf seine Sicherheit zu prüfen oder gar zu forken und als eigenes Modul intern zu publishen (dazu bräuchte man ja eine eigene Registry, was bei npm nicht leicht gemacht wird, auch wenn es sinnvoll wäre, zum Beispiel eben für die interne Verteilung). Wenn es gut läuft, schaut sich der Entwickler mal ein bisschen die Source an, was da drin passiert und vermeidet doppelte Funktionalität. Alles andere ist aber eben das Wunschdenken, worüber wir sprachen. Hast du hier explizit im Bereich Front-End mit bower, npm andere Erfahrungen machen können?
Nein, das kann man so glaube ich nicht sagen. Ich z.B. finde selten und nur wenig lobende Worte für MVC Frameworks bei den Themen, die wir hier behandeln. Das heißt aber nicht, dass ich keinen Sinn hinter z.B. React sehe. Das Problem ist jedoch, dass genau das, wovon du sprichst, auch hier wieder Wunschdenken ist. Ich habe viel zu viele Projekte gesehen und daran mitgearbeitet, wo solche Libraries und Frameworks missbraucht werden, um eine Webseite oder “Mini-Webapp” (nein, nicht das, wovon du da redest) zu bauen. Wir sprechen hier ja von Performance-Defiziten. Und genau in dem Zusammenhang sehe ich Libraries wie React als massives Problem (siehe auch Folge 259, wo es mehr um React geht), da es Leuten viel zu einfach gemacht wird, auf alle Grundsätze der Webseiten-Netzwerk-Logik zu scheißen und eine lahme Krücke zu bauen, nur mit dem einzigen Vorteil, dass der Entwickler selbst es einfacher hat, weil er alles in JavaScript schreiben darf — es ihm aber vollkommen egal ist, was für ein Markup rauskommt (muss nicht, aber leider ist das eben in der Realität so), wie schnell die Ladezeit der Seite ist, ob sie überhaupt was ohne JS anzeigt, ob irgendwer Probleme bei der Bedienung hat.
Ich könnte da jetzt noch Stunden weiterschreiben, ich sehe das Hauptproblem, dass solche Frameworks und Libraries eben nicht für ihren eigenen Zweck verwendet werden, und selbst in den seltenen Fällen, in denen das mal richtig ist, dann eben trotzdem kein Wert auf Semantik, Accessibility, Server-Side Rendering, und Offline Funktionalität gelegt wird. Schön finde ich daher, dass sich wenigstens dann mal ein paar Leute Gedanken machen, und dann auch ein Boilerplate, welches diese Themen abdeckt, bereitstellen (Folge 259).
Nochmal vielen Dank für deinen Input, freut mich, dass du dir die Zeit dafür nimmst. :)
Puddingpulver #
Geschrieben am 23.04.2016 um 11:06
Hallo,
anbei meine Antwort auf deine Frage: Hast du hier explizit im Bereich Front-End mit bower, npm andere Erfahrungen machen können?
Nein, mit npm und bower habe ich keine Erfahrung. In den Firmen in denen ich Arbeite (Banken, Versicherungen, Telekommunikation) und die JS-Libs einsetzen, sind die Libs immer in einem eigenen Repository die von den Firmen selbst verwaltet werden. Die JS Dateien werden dabei aus vertrauenswürdigen Quellen geladen und untersucht bzw. gesichtet. Danach wird die JS Datei im Firmen Repository zur Verfügung gestellt. Keinem Entwickler ist es gestattet einfach Dateien aus dem Internet zu laden und in sein Programm einzubauen.
Benjamin Wagener #
Geschrieben am 18.04.2016 um 14:42
Ich bin auch total begeistert, dass die Bash usw. bei Win 10 integriert wird. Leider ist es mit der Nutzbarkeit im produktiven Alltag aber noch etwas hin: http://www.golem.de/news/ubuntu-on-windows-im-test-eine-neue-hassliebe-auf-der-kommandozeile-1604-120375.html
Ansonsten finde ich interessant wie abfällig ihr über Webfonts denkt, während bei t3n und haste nicht gesehen so extrem von diesen geschwärmt wird, sogar Fefe bei der Gestaltung seines extrem minimalistischen Blogs darüber philosophiert und in allen möglichen Kursen für Frontend-Entwicklung ausführlich darauf eingegangen wird, wie man das nutzen kann. Werde ich mir jetzt auch nochmal überlegen, ob ich das bei meiner anstehenden Überarbeitung meiner Webseite, wo ich auch Bootstrap raus schmeißen werde, da es für meine kleine Seite völlig überdimensioniert ist. Übrigens stimme ich, wer auch immer das nochmal von euch gesagt hat, zu, dass ein Framework Mist ist, dass einen nicht darin unterstützt es effektiv anzuwenden. Ich denke Bootstrap z.B. wird vor allem von Leuten genutzt die nicht viel Ahnung von CSS haben bzw. sich nicht damit sonderlich auseinandersetzen möchten und einfach eine Seite haben wollen die einfach mobil wie am Desktop funktioniert. Und davon ausgehend Bootstrap zu entschlacken ist kaum möglich, weil man sich schon ziemlich stark mit CSS auseinandersetzen muss um entscheiden zu können, was man denn nun wieder raus schmeißen kann und was nicht, ohne dass Funktion x abhanden kommt. Und ein ausführliches Trial und Error will da sicher niemand versuchen, mich eingeschlossen.
Sebastian #
Geschrieben am 19.04.2016 um 00:47
Hallo Benjamin,
ich kann dir mit der Einschätzung zur nutzung von Bootstrap und Konsorten (z.B. Zurb Foundation) nicht zustimmen. Viele verwenden es trotz das sie sich mit CSS auskennen, jedoch keine lust haben an alles denken zu müssen. z.B. das Styling der grundelemente, button, formulare usw. wird durch die Verwendung von Frameworks stark vereinfacht. Andererseits wurde es im Podcast auf den Punkt gebracht. Die wenigsten gehen hin und nehmen nur die benötigten Elemente aus dem Framework um es möglichst schlank zu halten…
Benjamin Wagener #
Geschrieben am 19.04.2016 um 10:55
Hmm, okay, da muss ich mich missverständlich ausgedrückt haben. Den von dir beschriebenen Nutzungsfall wollte ich jetzt nicht ausschließen. Und ich gebe dir absolut Recht, dass die wenigsten nur die nötigsten Elemente aus den Frameworks nutzen, um diese schlank zu halten. Ich meine aber, dass das eben auch daran liegt, dass diese Frameworks zu wenig modular sind bzw. ihre Modularität schlecht dokumentiert ist und man sich daher zu intensiv mit ihrer grundsätzlichen Funktionalität auseinander setzen muss, sodass man zu viel Mühe darin investieren muss heraus zu arbeiten was man überhaupt raus lassen kann. Das resultiert in nahezu so viel Mühe, dass man dann genauso gut gleich das Framework selber schreiben hätte können. Ich denke mal das liegt daran, dass diese Frameworks eben nicht erster Linie für die dritten Nutzer produziert werden, sondern eben aus Firmen kommen, die erst einmal darin ihren eigenen Bedarf abbilden und gar nicht richtig im Sinn haben, dass man wirklich weniger brauchen könnte und wie man eben nur einzelne Elemente nutzt ohne Teil der Firma zu sein.
Felix W. #
Geschrieben am 18.04.2016 um 21:14
Npm Debakel
Im Java/Maven Umfeld gibt es als Lösung Repository Manager. Wie z.B. Nexus.
https://maven.apache.org/repository-management.html
Funktioniert eigentlich recht gut.
tas2580 #
Geschrieben am 19.05.2016 um 06:26
Ich bin heute erst dazu gekommen mir diese Folge anzuhören. Das ihr das mit den über großen Webseiten angesprochen habt finde ich gut, mir ist auch aufgefallen das heute 1-2 MB schon normal sind. Das mag ja am Desktop mit DSL funktionieren, aber wenn man mal in andere Länder geht laden die Seiten einfach ewig und es macht echt kein Spaß dort das Internet zu benutzen. Das mit den Handys ist natürlich auch so ein Problem, oft wird ja einfach per Media Query ausgeblendet was auf dem Handy nicht angezeigt werden soll, so bleibt die Seite 1-2 MB groß auch wenn nur die hälfte davon überhaupt benötigt wird.
Ich bin das vor kurzem mal bei meiner Webseite angegangen und habe alles was nicht zwingend nötig ist raus geworfen. jQuery setze ich z.B. erst dann ein wenn der dadurch eingesparte JavaScript Code größer wie jQuery selber ist. Vieles kann man ja auch so umsetzen ohne die riesen Datei zu laden. Durch meine Optimierungen bin ich auf eine Gesamtgröße von unter 50kb bei der Startseite gekommen, das ist jetzt auch mein Ziel für die restlichen Unterseiten.
RSS-Feed zu diesem Beitrag
Kommentare sind für diesen Beitrag geschlossen.