Code, Kram und Kaffee aus Bonn
⚠ Kein Support. Kein Newsletter. Kein Bullshit.
☕ JavaScript – die Sprache die alle benutzen und die Hälfte nicht wirklich mag
| 31 Beiträge · jQuery war mal modern · node_modules wiegt mehr als das Universum
| neues Framework erschienen während du das hier liest. Vermutlich.
☕
javascript.exe – Beiträge mit gemischten Gefühlen
_
□
✕
JavaScript – eine komplizierte Beziehung
Ich muss JavaScript benutzen. Das ist keine Wahl, das ist eine Tatsache des Lebens
als Webentwickler, so wie Regen in Bonn oder das unvermeidliche
"könntest du kurz mal drüberschauen" vom Kunden freitags um 16:45 Uhr. Man arrangiert
sich damit.
Ich hab angefangen mit JavaScript als es noch bedeutete: ein paar
document.getElementById Aufrufe, ein bisschen Form-Validierung,
fertig. Dann kam jQuery und alle fanden's toll. Dann kam Angular und alle fanden's
toll. Dann kam React und alle fanden's toll. Dann kam Vue, dann Svelte, dann
Solid, dann... irgendwann hab ich aufgehört zu zählen. Das Muster ist inzwischen
bekannt.
Was auf dieser Seite steht: meine ehrliche Einschätzung zu dem was ich benutze,
was ich ausprobiert hab und was ich bewusst ignoriere. Kein Tutorial-Kanal, kein
Framework-Fanboy. Einfach ein Backend-Entwickler der JS da einsetzt wo's Sinn
macht – und Vanilla nimmt wo's reicht.
Wer professionelle WordPress Websites
mit ordentlichem JS-Fundament braucht – das ist nicht mein Angebot hier,
aber es gibt Leute die sowas machen. Ich schreib lieber drüber.
📋 Der JavaScript-Hype-Zyklus – schlabonski's Beobachtungsprotokoll
2006jQuery – endlich kein Browser-Compatibility-Albtraum mehr
2010Node.js – JavaScript auf dem Server! Revolutionär!
2013Angular – Enterprise-JS, MVC, Dependency Injection, sehr viel Boilerplate
2015React – Components! JSX! Virtual DOM! Alle migrieren sofort.
2016Angular (das neue) – alle verwirrt, viele weg zu React
2018Vue 2 – "React aber netter". Stimmt irgendwie.
2019Svelte – kein Virtual DOM! Compile-Time! Sehr gehypt.
2023Bun, Astro, Solid, Qwik – und drei andere die ich vergessen hab
2026??? – läuft gerade. Irgendwas mit "keine Hydration".
Was ich tatsächlich benutze
Für die meisten meiner Projekte reicht Vanilla JS. Wirklich. Fetch API, querySelector,
ein paar Event-Listener, vielleicht ein kleines eigenes Modul – und fertig ist
ein interaktives Frontend das keine 800-KB-Bundle-Größe hat und das ich in
fünf Jahren noch lesen kann ohne ein Versionierungs-Chaos zu entwirren.
React benutze ich wenn's der Kunde fordert oder wenn die Interaktivität wirklich
komplex genug ist um den Overhead zu rechtfertigen. Das ist seltener als die
React-Community einem glauben machen will. Für einen Blog, eine Firmenwebsite
oder einen normalen Shop: Vanilla reicht. Für eine komplexe Single-Page-App
mit viel State: okay, dann React. Aber dann bitte mit Bedacht und nicht weil
alle anderen's auch haben.
// Das hier braucht kein Framework. Wirklich nicht.asyncfunction ladeInhalte(url) {
try {
const res = await fetch(url);
if (!res.ok) throw new Error(`HTTP ${res.status}`);
const data = await res.json();
document.getElementById('ausgabe').textContent = data.titel;
} catch (err) {
console.error('Fehler:', err.message);
}
}
// 12 Zeilen. Keine Dependencies. Funktioniert in jedem Browser seit 2018.
Aktuelle JavaScript-Beiträge
Warum ich React immer noch nicht mag – aber es trotzdem benutze
· schlabonskiNEU
REACT / MEINUNG
React ist der De-facto-Standard für komplexe Frontend-Arbeit. Das akzeptier ich.
Was ich nicht akzeptiere: dass man React für jedes Projekt nimmt, egal ob's
passt oder nicht. Die Punkte die mich stören – JSX-Syntax die immer noch seltsam
aussieht, der useEffect-Hook der gefühlt immer falsch läuft, die schiere Menge
an Boilerplate für simple Dinge – die sind real. Trotzdem: wenn State-Management
komplex wird und das Team React kennt, ist's die richtige Wahl. Ich hab Frieden
damit geschlossen. Ungefähr.
Vanilla JS in 2024 – was geht, was nicht geht, was überrascht
· schlabonski
VANILLA JS
Die moderne Web-API ist erheblich besser als ihr Ruf. Fetch, IntersectionObserver,
ResizeObserver, CSS Custom Properties via JS, das neue Dialog-Element –
vieles wofür man früher jQuery oder ein Framework gebraucht hätte, geht heute
nativ. Ich hab ein paar Projekte komplett ohne Build-Step und ohne Framework
umgesetzt und die Erfahrung war... angenehm entspannt. Kein Webpack-Config-Drama.
Kein "breaking change in Version 18.2.1". Einfach Dateien, Browser, fertig.
node_modules – ein Horrorfilm in mehreren Akten
· schlabonski
NODE / RANT
Ich hab mal nachgeschaut wieviele Packages ein frisches Create-React-App-Projekt
mitbringt. Die Antwort ist "zu viele" und ich werde sie hier nicht nennen
weil ich keine schlechte Laune verbreiten will. Was ich sagen kann: das
node_modules-Verzeichnis meines letzten React-Projekts war größer als
meine gesamte Musiksammlung. Das sollte irgendwie ein Warnsignal sein.
Der Beitrag schaut sich an woher das kommt, was dependency hell eigentlich
bedeutet und warum "npm audit fix" manchmal mehr kaputt macht als es repariert.
jQuery 2023 – ist das noch zeitgemäß?
· schlabonski
JQUERY / KLASSIKER
Kurze Antwort: für neue Projekte nein, für Legacy-Projekte oft ja. Lange Antwort:
jQuery ist auf mehr Websites aktiv als alle modernen Frameworks zusammen – weil
das Web voll ist mit Projekten die 2012 gebaut wurden und noch laufen. Wer
sowas wartet, der kennt jQuery gut oder lernt es. Wer neu anfängt hat mit
nativem JS heute kaum noch Nachteile gegenüber jQuery – außer vielleicht
ein paar Zeilen mehr Tipparbeit für DOM-Manipulation.
