TypeScript
Typen, die liefern
React
UI, die konvertiert
Next.js
App Router, ernsthaft
Angular
Enterprise, modern
Nuxt
Vue, voller Stack
NestJS
APIs mit Kantenschutz
Vue
Präzise Oberflächen
Node.js
Runtime mit Verantwortung
Remix
Web-Fundamentals first
Medusa.js
Composable Commerce
HTMX
HTML, das arbeitet
JavaScript
Sprache der Kante
Alpine.js
Interaktion ohne Ballast
Vanilla JS
Null-Framework, volle Kontrolle
React Native
Mobile, ein Team
PostgreSQL
Daten, die halten
DevOps
Pipeline, die liefert
GitLab
Repo, CI, Release
Dedizierte Ressource · Vanilla JS
Nicht jedes Produkt braucht React. Ein dedizierter Vanilla-JS-Entwickler von Typescriptaz schreibt kleines, robustes JavaScript: Web Components, Canvas, sparsame Widgets und den Kern für Design-Systeme. Weniger Abhängigkeiten, bessere Lighthouse-Werte, klarere Verhältnisse im Repo.
Einsatz
Moderne Browser können heute vieles, wofür früher ein Framework nötig war: Custom Elements, Shadow DOM, native Dialoge, Animationen über die Web Animations API. Ihr Vanilla-JS-Entwickler nutzt diese Plattform-Features konsequent und baut Komponenten, die in jedem Framework funktionieren – oder ganz ohne.
Das zahlt sich besonders bei Widgets aus, die auf fremden Seiten laufen: Chat-Fenster, Buchungs-Widgets, Tracking-arme Embeds. Kleine Bundles, keine globalen Konflikte, sauber gekapselte Styles. Wenn mehr Interaktion nötig wird, lässt sich das mit Alpine.js oder einem Framework erweitern.
Für Entscheider bedeutet Vanilla JS vor allem Unabhängigkeit: keine Framework-Updates, die den Zeitplan diktieren, keine Lock-in-Fragen und Code, der auf Basis von Web-Standards auch in Jahren noch läuft. Das macht die Wartung planbar und die Kosten überschaubar.
Typische Mandate: Widgets, Dokumentationen, High-Performance-Marketing.
Werkzeuge: Vanilla JS, CSS, Web Components, Vite
Direkt buchen
9.500 € / Monat
150 Stunden, fest angestellt und nur für Ihr Backlog. Im Kickoff lernen Sie die Person kennen, bevor es losgeht.
Kurz erklärt
Vanilla JS bezeichnet JavaScript ohne zusätzliches Framework – also die Sprache und die Schnittstellen, die jeder moderne Browser mitbringt. Dazu gehören Web Components, Shadow DOM, die Fetch-API, die Web Animations API und vieles mehr. Was früher nur mit Bibliotheken wie jQuery möglich war, ist heute oft direkt im Browser verfügbar. Für Unternehmen ist der Verzicht auf Frameworks vor allem dort interessant, wo Performance, Unabhängigkeit und lange Lebensdauer wichtiger sind als Bequemlichkeit – etwa bei Widgets und Komponenten-Bibliotheken.
Expertise
Seniority zeigt sich nicht im Lebenslauf, sondern im Code-Review. Darauf achten unsere Leute bei Vanilla JS.
01
Custom Elements, Shadow DOM, Template-Elemente und die Fetch-API sind in allen modernen Browsern verfügbar. Ein Senior-Vanilla-JS-Entwickler nutzt sie gezielt und ergänzt nur dort Bibliotheken, wo sie echten Mehrwert bringen.
02
Widgets, die auf Kundenseiten laufen, müssen sich gegen fremdes CSS und JavaScript abschirmen. Shadow DOM, eindeutige Namensräume und defensive Programmierung verhindern Konflikte.
03
Bundle-Budgets, Lazy Loading, Animationen auf dem Compositor und sparsame DOM-Updates: Wer ohne Framework arbeitet, hat volle Kontrolle – und nutzt sie für messbar schnellere Seiten.
04
Ein Widget oder eine Komponenten-Bibliothek braucht eine klare, versionierte Schnittstelle. Ein erfahrener Entwickler dokumentiert Attribute, Events und Methoden so, dass andere Teams sie ohne Rückfragen einsetzen können.
05
Auch ohne Framework müssen Komponenten per Tastatur bedienbar und für Screenreader verständlich sein. Ein Senior setzt ARIA-Muster korrekt um und testet sie mit echten Hilfstechnologien.
06
Vite, Tree Shaking, moderne Ausgabeformate und ein sauberes CDN-Setup sorgen dafür, dass Komponenten schnell laden und sich einfach einbinden lassen.
Typische Situationen
01
Dann darf es weder Ladezeit kosten noch mit fremdem CSS kollidieren. Wir bauen es klein, gekapselt und robust.
02
React hier, Vue dort, ein CMS daneben? Web Components liefern Bausteine, die überall funktionieren.
03
Landingpages, Kampagnen, Dokumentation: Ohne Framework-Overhead erreichen Sie Lighthouse-Werte, die sonst schwer zu halten sind.
Risiko im Griff
Ohne Framework fehlt ein Teil der eingebauten Leitplanken. Diese drei Risiken fangen wir deshalb bewusst ab:
Wer alles selbst baut, baut auch Fehler selbst. Wir setzen auf Web-Standards, testen in allen Zielbrowsern und greifen auf bewährte, kleine Bibliotheken zurück, wo Eigenbau keinen Vorteil bringt.
Ein Widget, das die Seite eines Kunden stört, schadet dem Ruf. Wir kapseln Styles und Skripte konsequent, testen in unterschiedlichen Umgebungen und liefern versionierte Releases mit klarem Rollback.
Ohne Framework-Konventionen muss die Struktur ausdrücklich dokumentiert sein. Wir halten Architektur, Komponenten-APIs und Build-Prozess schriftlich fest, damit Ihr Team jederzeit übernehmen kann.
Auch moderne Browser unterscheiden sich im Detail. Wir definieren eine Testmatrix mit den Browsern Ihrer Nutzer, testen automatisiert und setzen Polyfills nur gezielt ein, wo sie wirklich nötig sind.
Transparenz
Business Case
Wirtschaftlich zahlt sich Vanilla JS über geringe Folgekosten aus. Ohne Framework entfallen regelmäßige Framework-Upgrades, und Komponenten auf Basis von Web-Standards laufen oft jahrelang ohne Anpassung. Kleine Bundles verbessern die Ladezeit – auf Ihren eigenen Seiten und auf den Seiten Ihrer Partner. Und framework-unabhängige Bausteine lassen sich in allen Produkten einsetzen, egal welcher Stack dort läuft. Das schafft Unabhängigkeit, die sich bei jeder neuen Plattform auszahlt.
Die ersten zwei Wochen
Analyse, erste Lieferung, klarer Plan. Wie wir grundsätzlich arbeiten, lesen Sie unter Wie wir arbeiten.
01
Wie groß darf das Bundle sein, welche Browser müssen laufen? Wir definieren messbare Ziele.
02
Die erste Web Component oder das erste Widget geht mit Tests und Doku in Review.
03
Sie bekommen eine Roadmap für weitere Bausteine, Versionierung und Auslieferung.
Nach dem Start
So entwickelt sich ein typisches Mandat nach den ersten zwei Wochen – natürlich abgestimmt auf Ihr Backlog.
01
Bundle-Budget, Testmatrix und die erste Web Component oder das erste Widget als Pilot.
02
Weitere Komponenten folgen, Releases werden versioniert, und automatisierte Tests laufen in allen Zielbrowsern.
03
Dokumentierte APIs, Demo-Seiten und ein Release-Prozess, mit dem Partner und Produktteams die Komponenten selbstständig einsetzen.
Beispiel-Szenario
Ein Anbieter von Freizeitangeboten möchte seine Buchung auf Hunderten Partnerseiten einbinden. Die bisherige Lösung per iFrame ist langsam und schlecht an die Seiten anpassbar. Ein dedizierter Vanilla-JS-Entwickler baut ein schlankes Widget als Web Component.
Das Widget lädt nur, was es braucht, passt sich per Attribut an das Design der Partner an und stört keine fremden Styles. Neue Versionen werden kontrolliert ausgerollt, und Partner binden das Widget ohne eigenen Entwicklungsaufwand ein.
Für den Anbieter bedeutet das einen Vertriebskanal, der mit wenig Supportaufwand wächst, weil das Widget stabil läuft und sich ohne fremde Hilfe einbinden lässt.
Zusammenarbeit
Einzelne Widgets oder Komponenten lassen sich gut als abgegrenztes Vorhaben mit einem Stundenpool umsetzen. Betreuen Sie eine ganze Bibliothek von Komponenten oder mehrere Widgets im Dauerbetrieb, ist eine Person im Monatspaket sinnvoller.
Mit dem Kennenlernpaket entsteht bereits eine erste Komponente – so sehen Sie früh, wie die Zusammenarbeit funktioniert.
Alle Sätze, Pools und Effektivpreise im Detail finden Sie in der Preistabelle.
Klartext
Für große, stark interaktive Anwendungen mit viel Zustand ist Vanilla JS selten die wirtschaftlichste Wahl. Hier bieten Frameworks Strukturen, die man sonst selbst bauen und pflegen müsste. Wir empfehlen den Verzicht auf Frameworks für Widgets, Komponenten-Bibliotheken und Seiten, bei denen Performance und Unabhängigkeit an erster Stelle stehen – und sagen Ihnen offen, wenn ein Framework besser passt.
Für IT-Entscheider
Kann die Person Web Components mit Shadow DOM sauber kapseln?
Wie stellt sie sicher, dass ein Widget fremde Seiten nicht ausbremst?
Welche Browser testet sie und wie?
Wie versioniert und dokumentiert sie öffentliche Schnittstellen?
Kann sie begründen, wann ein Framework doch die bessere Wahl wäre?
Glossar
Eigene HTML-Elemente, die sich wie native Tags verwenden lassen.
Gekapselter Bereich einer Komponente, der Styles und Markup vom Rest der Seite trennt.
Browser-Schnittstelle, um Animationen performant per Skript zu steuern.
Festgelegte Obergrenze für die Größe des ausgelieferten Codes.
Passt oft dazu
Häufige Fragen
Für komplexe Anwendungen ja, für Widgets, Komponenten und schlanke Seiten oft nicht. Moderne Browser-APIs nehmen viel Arbeit ab – und Sie sparen Ihnen Framework-Updates.
Ja. Custom Elements lassen sich in jedem Framework einsetzen. React unterstützt sie seit Version 19 vollständig, inklusive Properties und Events.
Als kleines, versioniertes Script mit gekapseltem Shadow DOM, sauberem Ladeverhalten und klarer Konfigurations-API. So lässt es sich einbinden, ohne die Host-Seite zu beeinflussen.
Inhalte im Light DOM sind für Suchmaschinen gut lesbar. Für wichtige Inhalte empfehlen wir, sie nicht ausschließlich im Shadow DOM zu rendern oder serverseitig vorzubereiten.
Über versionierte Dateien oder Pakete mit klarer Versionsstrategie. Partner können eine feste Version einbinden oder automatisch kompatible Updates erhalten – beides mit dokumentiertem Changelog.
Ja, etwa mit framework-unabhängigen Komponenten, Performance-Optimierungen oder Tooling. Für tiefe Framework-Arbeit empfehlen wir die jeweilige Spezialisierung.
So klein wie möglich. Für viele Widgets sind Budgets unter 20 kB komprimiert realistisch. Wir legen das Budget gemeinsam fest und prüfen es bei jedem Build automatisiert.
Ja, etwa über CSS Custom Properties und Parts. So passen sich Komponenten an Ihr Design an, ohne dass fremde Styles hineinwirken.
Mit Unit-Tests für Logik, Tests der Komponenten im echten Browser und End-to-End-Tests für die Einbindung auf Beispielseiten.
Weil sie auf Web-Standards basieren, oft viele Jahre. Browser bleiben abwärtskompatibel, und es gibt keine Framework-Updates, die Änderungen erzwingen. Pflege braucht es vor allem bei neuen Anforderungen.
Ja. Wir bauen sie als Web Components nach, prüfen das Verhalten mit Tests und tauschen sie Schritt für Schritt aus. So verschwinden alte Abhängigkeiten, ohne dass Nutzer etwas davon merken.
Ja, denn die Grundlage ist Standard-JavaScript, das jeder Frontend-Entwickler kennt. Mit guter Dokumentation und klaren Konventionen können auch Teams ohne Spezialwissen die Komponenten pflegen.
Unterm Strich
Ein dedizierter Vanilla-JS-Entwickler baut Komponenten und Widgets, die klein, robust und unabhängig von Framework-Zyklen sind. Sie Gewinnen Performance, reduziert Abhängigkeiten und bekommt Bausteine, die in allen Ihren Produkten funktionieren – heute und in einigen Jahren.
Nächster Schritt
Sagen Sie uns Stack, Umfang und Startfenster. Wir melden uns in der Regel innerhalb eines Werktags – mit einer konkreten Person statt einem Stapel Profile.
Schnellkontakt
TypeScript-Ressourcen aus Österreich und Deutschland, fest bei uns angestellt. Nennen Sie uns Stack, Umfang und Wunschtermin. Wir melden uns in der Regel am selben Werktag – mit Verfügbarkeit, passender Seniority und einem konkreten Startfenster.