Das habe ich Neues gelernt ...

[JR Cologne]

Moin zusammen,

ich dachte mir gerade, ich starte mal einen Thread, in dem wir unsere Learnings über neue Technologien, Best Practices, usw. teilen können, wenn wir mal wieder über etwas Interessantes gestolpert sind, was vielleicht noch nicht jeder auf dem Schirm hatte oder eben besonders wichtig ist oder einen interessanten Insight darstellt.

Sei es ein bestimmtes Feature in einer Programmiersprache, ein bestimmtes Konzept aus der Softwareentwicklung/IT, oder gar ein Learning zum Umgang mit Kunden.

Ich schlage vor, dass jedes Thema mit einer kurzen Überschrift abgegrenzt wird, damit es einigermaßen übersichtlich bleibt.

Ich fange mal an:

a11y Tabs & HTML hidden-Attribut​

Ich bin heute über ein interessantes Video von Kevin Powell gestolpert, in dem es um die möglichst optimale Umsetzung von Tabs ging, damit diese u.a. barrierefrei sind und grundsätzlich gut, userfreundlich funktionieren.

Den Weg, den er dabei eingeschlagen hat, war ganz interessant:
Die Tabs wurden nämlich nach dem Prinzip Progressive Enhancement aufgezogen, was in dem Fall bedeutet, dass diese auch ohne JavaScript funktionieren, allerdings nicht wie richtige Tabs erscheinen, sondern einfach untereinander, vollständig sichtbar als normaler Text dargestellt werden und mittels Verlinkung durch einen Hashtag dann bei Klick auf den Link/Tab zu dem entsprechenden Abschnitt gesprungen wird.

Anschließend hat er mit JS alles Nötige, um tatsächlich ein Tab-UI mit Ausblenden der nicht aktiven Abschnitte umzusetzen, nachgeladen bzw. Schritt für Schritt hinzugefügt.
Letztendlich konnte man die Tabs dann auch vollumfänglich mit der Tastatur ansteuern, wobei auch das Markup für die Barrierefreiheit der Tabs (aria, role und Co) größtenteils mit JS dynamisch gesetzt wurde.

Abgesehen von den Learnings rund um die bestmögliche barrierefreie Gestaltung der Tabs gab es noch was anderes, was mir ins Auge gesprungen ist und neu war:

Zum Ausblenden der nicht aktiven Tabs hat er das HTML hidden-Attribut eingesetzt, das mir tatsächlich noch komplett unbekannt war. Ich wusste gar nicht, dass das existiert und habe es auch noch nie irgendwo im Einsatz gesehen.

Was mich im Nachhinein beim Lesen über das Attribut tatsächlich wundert:
Kevin Powell nutzt es meiner Ansicht nach in dem Fall ganz klar falsch, da bei MDN bzw. in der HTML-Spezifikation explizit steht, dass man es nicht verwenden sollte, um Tabs umzusetzen bzw. man nicht von sichtbaren Elementen auf mit hidden versteckte Elemente verlinken sollte.

Auch wenn es wohl von Browsern teilweise einfach wie display: none implementiert wird, ist es semantisch in dem Fall wohl nicht angebracht.
Stattdessen kann es bspw. wohl eingesetzt werden, um Inhalte aus einem eingeloggten User-Zustand zu verstecken/anzuzeigen, o.ä.

Mit CSS kann man das Ganze übrigens auch einfach überschreiben, sodass ein mit hidden ausgeblendetes Element dann wieder angezeigt wird.

Hat jemand von euch das Attribut schon mal verwendet? Würde mich interessieren, wofür.

 

[Mat]

hat jemand von euch das Attribut schon mal verwendet? Würde mich interessieren, wofür.

Noch nie genutzt. Macht es aber sicher einfacher für Skripte, die Dokumentstruktur zu verstehen und kapselt das Styling ein bisschen vom Dokument ab.

Mir fällt aber kein guter Anwendungsfall ein. Dafür kenne ich Frontendkram nicht gut genug. Vielleicht kann man das irgendwie mit HTMX kombinieren? Aber sehe da auch nicht direkt einen Vorteil, denn da können Platzhalter einfach dadurch unsichtbar sein, dass sie leer sind und dann ersetzt werden.

Zum Thread allgemein: Gute Idee. Bei mir vergeht eigentlich fast kein Tag, an dem ich nicht mit etwas Neuem konfrontiert werde und irgendwelche Notizen dazu mache, aber das meiste ist uninteressant oder wahrscheinlich den meisten schon bekannt.

Ich versuche es trotzdem:

Performance Profiling​

Ich hatte nie wirklich was mit Profilern gemacht. Nur in sehr seltenen Fällen habe ich rein geschaut, warum zum Beispiel eine Webseite ruckelt oder was eine Android-App beim Start so macht.

Ich stoße immer wieder mal auf Anwendungen, die übermäßig viel Speicher verwenden oder ohne ersichtlichen Grund kacke laufen. Ich habe zwar nichts mit Anwendungen zu tun, die besonders geringe Latenzen brauchen oder besonders stark durchoptimiert sein müssen, aber es kann nicht schaden, ein wenig über seinen Tellerrand hinaus zu schauen.

Deswegen habe ich mir vorgenommen, wenigstens bei meinem Code ab und zu mal genauer hin zu sehen. Auch wenn ich so eine ungefähre Vorstellung davon habe, was langsam oder verschwenderisch sein könnte, so ist ein Log da doch viel aussagekräftiger als ein Gefühl. Auch kann es sein, dass die Anwendung ganz anders läuft und "optimiert" wird, als man sich das vorgestellt hat. Besonders, wenn Garbage Collection mit im Spiel ist. Außerdem kann es manchmal auch besser sein, den Speicherverbrauch auf Kosten von CPU-Zyklen zu schonen. Viele Dinge, die man gar nicht auf dem Zettel hat.

Und weil ich faul bin, nehme ich hier noch direkt meine Notizen:

## Profiling

Immer gut, die eigene Anwendung im Profiler zu betrachten, auch wenn sie scheinbar problemlos läuft:

1. so hat man zumindest eine Basis zum Vergleich, sollte die Performance sich mal verschlechtern
2. verbessert das Verständnis von Speicherverbrauch und Abläufen
3. kann unerwartete Abläufe oder Nebeneffekte offenlegen

### Allgemein

Flaschenhälse durch Analyse von Trace Logs identifizieren

-   Benchmarks und Profilings sollten auf Release-Version laufen, nicht auf Debug-Version
-   wenn möglich kurze, immer gleiche, automatisierte Szenarien
    -   ⚠️ 1mio mal isoliert die gleiche Funktion aufrufen hat keine hohe Aussagekraft
    -   sollte schon auf reale Fälle angewendet werden
-   immer einen Baseline Tracelog behalten, als Mindestmaßstab
-   direkter Vergleich von Tracelogs oft nicht sehr aussagekräftig, stattdessen:
    -   besonders schlechten Tracelog/Ausreißer anschauen und kritische Stelle identifizieren
        -   andere Quellen ausschließen
    -   dann erst diese kritische Stelle mit Baseline vergleichen
    -   wichtigste Prozesse in Baseline anschauen (zB ein Suchfilter und die Interaktion mit dem UI)
-   nur auf Problemkinder fokussieren
    -   Funktionen mit kleinen Performanceeinbußen einfach ignorieren, Aufwand lohnt nicht (außer sie laufen in Schleifen/sehr oft)

### Emulatoren

-   Emulatoren sind gut, um Funktionalität und Speicherverbrauch zu messen
-   Benchmarks sind dort in der Regel unbrauchbar und sollten auf den echten Zielgeräten stattfinden
-   können allerdings eine gute Möglichkeit sein, Geräte mit schlechter Hardware zu simulieren