Plain Vanilla JavaScript !

Neulich hatte ich mal wieder das Vergnügen ohne jQuery o.ä. ein bestehendes Javascript zu erweitern. Entgegen meiner Befürchtung, daß alles dreimal solange dauern würde, bis ich die notwendigen Snippets zusammen gegoogelt und modifiziert habe, ging es doch deutlich schneller als angenommen. Natürlich kann man auch typescript, ES6 usw schreiben und es dann transpilieren, aber es wäre vermutlich noch aufwendiger geworden, diese Frameworks aufzusetzen und damit zu starten. Also plain JS.

Es ist längst nicht mehr wie zur Jahrtausendwende, als es noch notwendig war, selbst einfache DOM-Queries für zwei verschiedene Browser zu schreiben. Sofern man nicht IE7 oder IE6 bedienen muss, was heutzutage wirklich eine sehr abwegige Anforderung wäre, entfallen derartige Browserweichen.

Es handelte sich in diesem Projekt um eine statische Formularanwendung, die mittels neuen Dimension ode Parameters dynamisiert werden sollte, sodaß unterschiedliche Konfigurationen ein und desselben Formulars ermöglicht werden. Ein einziges Dropdown sollte das Aussehen weiterer Multi-Selects steuern, zusätzliche Felder ein- bzw ausblenden etc etc. Alles in allen ein recht fortgeschrittenes Ding und eine sechzehn Jahre alte Javascript Codebasis. Diesesn bestehenden Code wollte ich möglichst unangetastet lassen und möglichst nur neuen Code hinzufügen. Das Formular selbst war eine verschaltelte Tabelle untergebracht, bestehend aus Tabellenzeilen, Unter-Tabellen usw. Das mutet heutzutage wirklich altertümlich an und das ist es auch. Diesen Frontend-Gerüst wollte ich ebenfalls erhalten. Wenn man strukturiert vorgeht und nicht einfach drauflos hackt gelingt es in Javascript häufig “nicht-invasiv” zu arbeiten, also sprichwört etwas um den bestehenden Code herumzustricken, während die vorhandene Funktionalität unangetastet bleibt. Ich habe festgestellt daß meine Art und Weise über DOM-Manipulationen und -Events zu denken schon sehr von jQuery infiltiert ist. Das ist ja auch keine Schande, schliesslich ist jQuery zurecht seit mindestens zehn Jahren weit verbreitet, leicht zu erlernen und sehr flexibel. Die beschriebene Aufgabe, also die Dynamisierung des Formulars habe ich mehr oder weniger gedanklich in jQuery gelöst und dann in Vanilla JS codiert, wohlwissend, daß jQuery natürlich auch nichts anderes ist, als eine Sammlung von Prototypen bestehend aus purem Javascript.

Ich will hier einfach ein paar Beispiele für die Methoden auflisten, die meine Recherche zutage gefördert hat. Dabei soll nicht unerwähnt bleiben, wie mich die Ausführungsgeschwindigkeit von Plain JS positiv überrascht hat. Anfangs waren meine Bedenken noch, daß Teile des Formulars beim Ein- und Ausblenden aufflackern könnten (ein Effekt der tatsächlich auftreten kann, wenn man umfangreiche Strukturen im DOM modifiziert). Aber nichts Dergleichen war zu beobachten, kein Gewackel, kein Geflacker. Schneller als Pure JS gehts im Browser nicht, vorausgesetzt man schreibt effektiven Code, verwendet also z.B. keine mehrfache Variablenzuweisung, keine unnötigen Schleifen usw.

Man findet verschiedene Angaben zum Geschwindigkeitsunterschied, meist liegt der Faktor zwischen 3 und 10, d.h. Plain JS ist 3-10 mal schneller als jQuery.

Hier sind nun eine Handvoll nützlicher Codeschnipsel:

Prüfung ob ein Array-Key existiert

Definiert man ein JS Array in Objektschreibweise


var myarray = {

one : [ 0, 1, 2 ]

two : [ 0, 1, 2 ]

three : [ 0, 1, 2 ]

}

Dann lässt sich auf diese Weise sehr einfach prüfen, ob ein gegebener Key existiert:


if( Object.keys(myarray).indexOf(key) > -1 )

Loop über die Zeilen einer Tabelle


var table = document.getElementById("mytable");

// loop durch alle tabellenzeilen

for (var i = 0, row; row = table.rows[i]; i++) {

if(row.getAttribute('id') !== null) {

row_id = row.getAttribute('id');

// zeile mit id, die "test" enthält ausblenden

if( row_id.indexOf("test") > 0 ) {

...

}

} // if

} // for

Äquivalent zu jQuery next()


var nextElem = next(elem);

function next(elem) {

do {

elem = elem.nextSibling;

} while (elem && elem.nodeType !== 1);

return elem;

}

Diese Funktion findet das nächste Element im DOM. Etwaige Textnodes werden übersprungen.

Alle <input> Elemente unterhalb eines Knotens erhalten

Äquivalent zu jQuery’s find()


var inputfields = node.getElementsByTagName('input');

Es ist nicht möglich mehrere tags per Komma aufzulisten. Stattdessen muss noch einmal getElementsByTagName aufgerufen werden.

Zum Abschluss noch ein paar Links

Hier ist eine coole Seite, auf der man die minimale IE Version einstellen kann, um dann eine ganze Reihe von Gegenüberstellungen jQuery – plain JS zu erhalten. Der IE ist offenbar der kleinste gemeinsame Nenner, nach dem Motto, was dort funktioniert, geht auch in allen anderen Browsern.

http://youmightnotneedjquery.com/

Benchmark Tests

https://medium.com/@trombino.marco/you-might-not-need-jquery-a-2018-performance-case-study-aa6531d0b0c3

https://www.measurethat.net/Benchmarks/Show/554/8/jquery-vs-vanilla-js-getid-speed-test

Hier ist eine weitere Gegenüberstellung neuer Methoden jQuery – plain JS

https://css-tricks.com/now-ever-might-not-need-jquery/

Wer das Pech hat, den Internet Explorer berücksichtigen zu müssen, wird an dieser Stelle enttäuscht, denn so praktische neue Methoden wie closest (inspiriert durch jQuery ?) können dann nicht verwendet werden.

Die Renaissance von Typo3

Es muss 2000 oder 2001 gewesen sein, als ich das letzte Mal mit typo3 in Berührung kam. Obwohl mir das CMS mächtig und vielversprechend erschien, verschwand es wenige Jahre später wieder von meiner Bildfläche. Andere CMS waren schlanker, moderner. Es war trendy eigene CMS zu entwickeln. Tatsächlich habe ich mit PHP3/4 auch einen ersten Versuch gestartet, ein eigenes CMS zu programmieren, aber dann kamen andere Sachen dazwischen. Mit PHP war der Weg dahin mehr
oder weniger straightforward. Allerdings liess sich jedoch auch erahnen, daß hier mit allen Mitteln der Softwareentwicklung vorgegangen weden muss, um ein tragfähiges, skalierendes Ökosystem zu schaffen, das mit den Ansprüchen mitwächst, und nicht eine immer unübersichtlichere Sammlung von globalen Funktionen und Ausnahmen wird. Jeder der in den Nuller Jahren ein CMS selbst gestrickt hat, um es spätestens in den 2010er Jahren wieder zu verwerfen, wird wissen was ich meine.
Aber zurück zu typo3: Für mein Empfinden krankte das System an der Verkapselung von Funktionalitäten. Zwar liess sich ziemlich einfach eine Website damit zusammenbasteln, aber was wirklich unter der Haube passiert (TemplaVoila, TypoScript) bliebt doch nicht selten ein Geheimnis.
Sobald man etwas eigenes brauchte, spezielle Ausgaben etc. stand man auf dem Schlauch. Auch gab es damals keine nennenswerte grosse Community, in welcher man fündig geworden wäre, wenn man vor einem bestimmten Problem stand. Ein sinnvolles Verschachteln von Templates war seinerzeit nicht möglich. Stattdessen gab es diese allgegenwärtigen Templatemarker.
Kurz gesagt, ich habe typo3 keine grosse damals Zukunft prognostiziert, zumal es auch fast keine Kundenwünsche dahingehend gab. Mit irgendeiner der 4er Versionen geriet typo3 für mich zusehenends in Vergessenheit, die 6er Version habe ich nicht weiter untersucht, bis ich 2017 in den Genuß kam die Website eines Klavierherstellers, erstellt mit typo3 6.2, zu übernehmen und modernisieren.
Die Site war ca 2014 erstellt worden und umfasst nicht weniger als acht custom extensions. Hier gab es also reichlich zu lernen. Zu meiner Überraschung hatte inzwischen eine neue Templateengine namens Fluid Einzug gehalten und erlaubte erstmalig ein strukturiertes Arbeiten inklusive Versionierung mit Templates. Auch gab es eine neue Methode, eigene Contentelemente zu kreieren, allerdings immer noch nur mit Hilfe der bereits in den Anfangstagen schwer zugänglichen Konfiguration des mysteriösen TCA. Schon vor zwanzig Jahren gab es nur wenig brauchbare Dokumentationen zu diesem CMS. Daran hat sich bis heute zwar Einiges geändert, aber wenn es darum geht, konkrete Beispiele zu finden, ist man nach wie vor damit beschäftigt im Netz nach Lösungen zu suchen. Am brauchbarsten sind die Ergebnisse von stackoverflow. Weniger brauchbar sind Lösungen auf der Seite “typo.net”. Letztere ist eine deutschsprachige Community. Selten sind die Anleitungen verständlich. Oft wundere ich mich darüber, wie Leute es schaffen mit Typoscript zwar Lösungen zu finden, aber nicht in der Lage sind ihre Methoden zu erklären.
Typo3 jedenfalls scheint erwachsen geworden zu sein und kann nun endlich seine Stärken ausspielen. Diese sind meiner Meinung nach das ausgeklügelte Berechtigungssystem für Benutzer, das solide Login Handling und der robuste Umgang mit grossen Mengen an Content.
Erst mit der Version 9 hat endlich das URL-Handling in den Core Einzug gehalten – eine Selbstverständlichkeit für viele andere CMS. Das Gefummel mit der Extension “RealUrl” scheint damit der Vergangenheit anzugehören.
Inzwischen hat sich meine Meinung über typo3 komplett zum Positiven geändert. Die genannten Vorteile zusammen mit der grösseren Verbreitung und der besseren Auffindbarkeit von Problemlösungen haben mich umgestimmt. Die aktuellen Versionen 8 und 9 sind definitv einen Blick Wert. Auch das Backend macht inzwischen einen zeitgemäßen Eindruck.
In einem anderen Post werde ich über meine Erfahrungen mit typo3 aus dem Developer Alltag berichten und meine best practices vorstellen.

Umgebung und Tools zur Webprogrammierung

Heute will ich Euch vorstellen, mit welchen Werkzeugen ich meine Projekte bearbeite und aus anfragenden Kunden zufriedene, wiederkehrende Kunden mache, wenn denn alles gut geht und die Chemie stimmt.
Tatsächlich entsteht alles auf einem Laptop der Marke HP, um genau zu sein ist es ein HP Probook 450 G4, das ich gebraucht für 500 € gekauft habe. Das ist nichts Besonderes, es ergab sich einfach so daß ich letztes Jahr dieses halbwegs aktuelle Mittelklasse Laptop erwerben konnte. Ich habe da keine Präferenzen, zuvor hatte ich ein ASUS Laptop, das war ebenso geeignet. Wesentlich wichtiger ist die Software, also das Betriebssystem und die Anwendungen.
Seit über zehn Jahren arbeite ich an Webprojekten am liebsten mit Linux. Irgendwie macht das Sinn für mich, vielleicht ist es auch Nostalgie oder das Wissen, daß diese ganze Internetgeschichte auf einem X-System entstanden ist (auf einem NeXt System wenn ich mich richtig erinnere). Jedenfalls war es für mir keine grosse Hürde auf Linux umzusteigen, denn ich hatte während des Studiums schon damit zu tun, wenn auch nur ganz rudimentär. Es gab ein kleines Rechenzentrum für den FB Physik Anfang der 90er Jahre. Dort hatte ich den ein oder anderen Kurs belegt, um dann auf der Konsole ein paar Dateien zu erstellen, kopieren, löschen usw. Das war es aber auch schon. Ich hatte keine Ahnung von Shellscripts, Perl usw.
Ich verwende Ubuntu weil es leicht zu installieren ist und die meisten grundlegenden Programme mitbringt. Über die Jahre habe ich mich daran gewöhnt. Welche Desktop Engine dabei zum Einsatz kommt ist relativ egal. Es gibt sicher schlankere und schnellere Alternativen dazu, aber das ist Geschmackssache.
Genug der langen Vorrede, hier sind meine wichtigsten Programme:
Visualstudio Code
Nachdem ich lange Jahre auf jEdit geschworen habe, bin ich tatsächlich auf diesen Microsoft-Editor umgestiegen und musste feststellen, MS hat seine Hausaufgaben gemacht. Super angenehmenes Arbeiten mit diesem Editor, der alle gängigen Programmiersprachen beherrscht.
Meine am häufigsten verwendeten Tastatur Shortcuts:
CRTL-K-O : Projekttree öffnen
CTRL-F : Suche in der aktuellen Datei
CTRL-H : Suchen/Ersetzen in der aktuellen Datei
CTRL-SHIFT-F : Suche im Projekt Tree
CTRL-SHIFT-K : Zeile löschen

Git
Nichts geht mehr ohne git. Auch nicht bei Ein-Personenprojekten. Als Deployment Tool verwende ich git-ftp auf der Kommandozeile. Dem Thema Deployment werde ich nochmal einen extra Post widmen.
Zwar lässt sich VS Code so konfigurieren, daß Änderungen nach dem Speichern sofort deployed werden, aber ich schaue mir Änderungen sowieso gerne erstmal lokal an und deploye dann aus dem Terminalfenster heraus ganz einfach per: git add . ; git commit -m „css“ ; git ftp push
Natürlich gibt es auch visuelle Git Tools wie Git-tk usw. Aber das macht eher Sinn, wenn mehrere Developer an einem Projekt arbeiten, um z.B. umfangreiche merge Klammern zu betrachten. Für meine Zwecke reicht git auf der Kommandozeile vollkommen aus. Es kommt ohnehin selten vor, daß ich mal einen commit zurückdrehe oder eine Änderung wieder auschecke, eben weil ich vor dem Deployment lokal verifiziere, daß die Änderung den gewünschten Effekt bringt und im besten Falle keine Komplikationen an anderer Stelle nach sich zieht.

Gimp
Alles was der Webgrafiker braucht, ist hier zu finden. Gimp ist die OpenSource Alternative zu Photoshop. Perfekt um mal eben ein Foto zu skalieren, zu komprimieren, ein PNG freizustellen etc.
Gimp ist für mich ein reines Bildbearbeitungstool. Wenn es daraum geht, eine visuelle Idee zu entwickeln, halte ich ein Vektorzeichenprogramm für die bessere Wahl. An dieser Stelle sei “Inkscape” empfohlen. Ein super Tool um z.B. ein Logo zu entwerfern oder mit Typografie herumzuspielen.

Chrome / Firefox
Hierzu ist nicht viel zu sagen. Nur in Ausnahmefällen brauche ich mal Safari. In der Regel funktioniert alles was im Chrome funktioniert auch in allen anderen zeitgemäßen Browsern. Es sei denn man steht vor der Aufgabe noch den betagten IE 11 zu bedienen, was in einigen Firmen oder Institutionen gar nicht mal so selten vorkommt. Kurz gesagt, ich habe mich auf Chrome eingeschossen, nur gelegentlich nutze ich auch mal FF um mich beispielsweise mit einem anderen Account auf einer Website anzumelden.

Klaus Stiegemeyer

Diese typo3 Website der Foto-Repräsentanz Klaus Stiegemeyer mit einigen tausend Fotos und Videos habe ich in Hinblick auf Ladegeschwindigkeit optimiert. Alle Fotos wurden per „mogrify@imagemagick“ in einem Rutsch verkleinert. Die Ladezeit konnte ich per Lazyloading erheblich reduzieren. Es besteht nun auch die Möglichkeit, auf der Startseite Fullscreen-Videos zu zeigen. So macht die Seite schon viel mehr Spass. More to come !

Yolii

Dies ist eine weitere WordPress-basierte Seite, erstellt für den Fitnessgeräte-Hersteller Yolii. Hier handelt es sich um ein
grafisch dezent-anspruchsvoll gestaltetes Portfolio mit multimedialen Inhalten, Social Media Verlinkung, Kontaktformular sowie einer
Newsletteranbindung.

Coolkidsbelongtogether

Webpräsenz für Model-Scouterin Anna Rechul auf der Basis eines WordPress Themes. Model-Einträge sind als Custom Post Types realisiert um die einfache Erstellung einer Sedcard zu erleichtern. Slide-Animation mit jQuery auf der Startseite.

Bluesleeve

Zweisprachiger Onlineshop auf Basis von wooCommerce für den Hamburger Designerfashion-Store Bluesleeve. Der Schwerpunkt lag auf der Umsetzung des minimalistischen Layouts und der Entwicklung eines stimmigen und
einheitlichen Bedienkonzepts.

Avia

Mehrsprachige und responsive TYPO3-Website des Schweizer Tankstellennetzes AVIA. Nach vorgegebenen Layouts wurden TYPO3-Fluid-Templates programmiert. Mit DCE-Modulen können Redakteure an beliebigen Stellen vorgefertigte Inhaltscontainer einfügen. TYPO3 Extensions ernöglichen die themenabhängige Verteilung von Kontaktanfragen an mehrere Empfänger.

Brazetec Onlineshop

Für diesen Kunden wurde ein responsiver B2B-Shop basierend auf dem Shopsystem OXID entwickelt. Das Standardsystem wurde um diverse Zusatzmodule erweitert um z.B. eine vom tagesaktuelle Silberpreis abhängige Preisberechnung zu gewährleisten. Hinzu kamen Backend-Module, die das Erstellen von Rechnungen für den Endkunden erleichtern.

YouSellWeSend

Die Website dieses Fulfillment-Anbieters aus Hamburg basiert auf dem sehr beliebten und inzwischen ausgereiften CMS System WordPress. Diverse spezielle Programmierungen wurden vorgenommen wie z.B. ein Online-Kostenrechner.