shipyard basiert auf einigen Kernprinzipien, die jede Design-Entscheidung leiten.
Anstatt gegen ein Framework zu kämpfen, umarmt shipyard was Astro am besten kann:
Das bedeutet du bekommst Astros Performance und Flexibilität während shipyard die Page-Builder-Belange handhabt.
Anders als Starlight, das alles an sein Doku-System koppelt, trennt shipyard Concerns in unabhängige Pakete:
| Paket | Zweck | Anwendungsfall |
|---|---|---|
| @levino/shipyard-base | Kern-Layouts, Navigation, Styling | Marketing-Seite, Landing Pages |
| @levino/shipyard-docs | Dokumentations-Features | Hinzufügen wenn du Doku brauchst |
| @levino/shipyard-blog | Blog-Funktionalität | Hinzufügen wenn du einen Blog brauchst |
Mischen und kombinieren. Nutze ein Paket oder alle drei. Deine Seite, deine Wahl.
Viele Projekte starten als einfache Landing Page, brauchen dann Doku, dann einen Blog. Mit Starlight müsstest du alles umstrukturieren um Non-Doku-Content hinzuzufügen. Mit shipyard installierst du einfach ein weiteres Paket.
Umgekehrt, wenn du nur eine Marketing-Seite mit Blog brauchst – keine Doku – zwingt dir shipyard keine Dokumentations-Infrastruktur auf.
Anstatt eine eigene Komponentenbibliothek zu bauen, die stagnieren könnte (wie Infima), nutzt shipyard DaisyUI – eine ausgereifte, gut dokumentierte, aktiv gepflegte Komponentenbibliothek auf Tailwind CSS.
Das lässt shipyard sich auf Page-Builder-Belange fokussieren während Styling an Experten delegiert wird.
Dein Content ist einfach Markdown. Das ist eine bewusste Entscheidung, die deine Optionen offen hält:
Tipp: Nutze einen KI-Assistenten wie Claude um bei der Migration zu helfen. Da es nur Markdown-Dateien verschieben und Konfiguration anpassen ist, können KI-Tools die meiste Arbeit für dich erledigen.
shipyard erfordert nicht:
Wenn du entscheidest, dass shipyard nicht das Richtige für dich ist, nimm deine Markdown-Dateien und zieh weiter. Diese niedrigen Wechselkosten bedeuten, dass du shipyard ohne Commitment ausprobieren kannst – wenn es nicht klappt, hast du nichts verloren.