Ich sehe, dass VuePress gerade 1.0 erreicht hat. Einfach ausgedrückt ist es ein Static Site Generator, der auf Vue basiert. Aber natürlich arbeitest du in Vue, was bedeutet, dass du in Komponenten arbeitest.
Alle modernen JavaScript-Frameworks basieren auf Komponenten. Selbst wenn sie sich in bestimmten Dingen widersprechen (wie z. B. dass Svelte eine Kompilierung benötigt), scheinen sie sich alle auf das Modell der Arbeit in Komponenten zu einigen. React ist nur Komponenten. Ein beliebter Static-Site-Generator für React ist Next.js. Die Vue-Version davon ist Nuxt.js.
Dann gibt es Gatsby, das nur aus React besteht. (Hören Sie sich unsere neueste ShopTalk Show an, während wir darüber diskutieren.) Gridsome scheint der direkteste Vergleich im Vue-Universum zu sein, wobei der bemerkenswerte Vergleich darin besteht, wie beide darauf ausgelegt sind, Daten aus jeder Quelle zu beziehen. Komponenten natürlich. Ich bin mir nicht sicher, ob es einen Flaggschiff-Angular-basierten Static-Site-Generator gibt, aber es gibt sie, und Angular besteht durch und durch aus Komponenten.
Komponenten sind so allgegenwärtig, dass Sie vielleicht gar nicht mehr darüber nachdenken. Aber Sie spüren es vielleicht, besonders wenn Sie zwischen Projekten wechseln, die nicht komponentengetrieben sind. WordPress-Entwicklung ist im Allgemeinen, meiner Meinung nach, nicht komponentengetrieben. Sicher, Sie haben Ihre header.php und footer.php Dateien und so weiter. Sie können diese beliebig aufteilen, aber das ist eher ad hoc. Sie bauen keine expliziten Komponenten und füttern diese Komponenten mit lokalen Daten und testen sie entsprechend. (Mit etwas wie Timber kommen Sie dem schon viel näher.)
Front-Ends aus serverseitigem Code zu erstellen, ist absolut in Ordnung. Server-Side Rendering bietet zahlreiche Vorteile. Aber serverseitige Sprachen scheinen Komponenten nicht so umarmt zu haben, wie es JavaScript getan hat. Und da jeder Komponenten mag (Frontend-Entwickler lieben sie offensichtlich, Designer denken sowieso so, Backend-Entwickler verstehen es...), ist es für mich keine Überraschung, diesen Anstieg beliebter Projekte zu sehen, die serverseitig (oder zur Build-Zeit) generierte Websites aus JavaScript erstellen, einfach weil sie komponentenbasiert sind und Komponenten eine gute Idee sind.
NuxtJs Nummer 1!
„Aber serverseitige Sprachen scheinen Komponenten nicht so umarmt zu haben, wie es JavaScript getan hat.“
React und Angularjs haben ihre Ideen von JSF und Spring für Java und ASP MVC für .NET übernommen. Frameworks, die den Benutzer zwingen, in Komponenten zu denken und mit ihnen zu arbeiten.
Das ist cool! Nur für meine Neugier, gibt es Artikel oder Ähnliches, die über diese frühen Tage sprechen und woher die Ideen stammen? Ich bin sicher, es gibt eine noch tiefere Abstammung... es gibt wirklich keine neuen Ideen mehr, oder? :)
Aber trotz der Ursprünge denke ich immer noch, dass meine Aussage, dass serverseitige Sprachen Komponenten nicht auf die gleiche Weise umarmen, einige Gültigkeit hat, zumindest in den Blasen, in denen ich mich bewege. Java- und .NET-Entwicklung liegen mir fern, nur zur Info. Ich höre eher, was Ruby-, Python- und PHP-Entwickler sagen, und es scheint nicht, dass sich die Konversation dort um Frameworks dreht, die die Komponentenzusammensetzung absolut erzwingen.
Zustimmung, die JavaScript-Welt übernimmt die Idee von serverseitigen Frameworks, die die Idee von Komponenten sehr stark umgesetzt haben.
ASP.NET begann mit „Benutzersteuerelementen“, jetzt „View Components“ in ASP.NET MVC. Dies sind in sich geschlossene Komponenten, die ihre eigenen Controller und ihren eigenen Zustand haben können (ähnlich einer „Klassenkomponente“ in React). Es gibt auch „Partial Views“, die den „Funktionskomponenten“ in React entsprechen.
Serverseitige Sprachen haben diese schon immer gehabt. Tatsächlich wurden die frühen Werkzeuge für Komponentenbibliotheken aus Ruby on Rails und Django geboren. Storybook kam und ging den gleichen Weg für JavaScript, aber eigentlich ist es nichts Neues.
Mann, ich erinnere mich an SSI (Server Side Includes) von früher... Kann das als HTML-basierte Komponententechnologie betrachtet werden?
Hier ist ein gutes Beispiel für ASP.NET-Benutzersteuerelemente. Sie können die Entstehung von gekapselten Komponenten mit eigener Geschäftslogik sehen, die überall auf einer Seite platziert werden können. Sie können auch den Anfang der Syntax zum Übergeben von Attributen an sie sehen. Es war ziemlich normal, die UI zu „Benutzersteuerelementen“ zu zerlegen, wenn man mit dem Erstellen einer Seite begann, ähnlich wie wir es heute mit „Komponenten“ tun würden.
https://www.codemag.com/Article/0209031/ASP.NET-Extending-the-Power-of-Web-Pages-with-User-Controls
Dieses Modell brachte eine ganze Branche von fertigen, in sich geschlossenen UI-Komponenten hervor, die in Projekt-UIs komponiert werden konnten, wie z. B. https://demos.telerik.com/aspnet-ajax/. Frühe Beispiele dafür waren buchstäblich Benutzersteuerelemente (Komponenten mit Props) und etwas globales CSS/JS.
Rails und andere MVC-ähnliche Frameworks haben starke Konventionen für die Erstellung von UIs aus einer Reihe von HTML-Partials. Stellen Sie sich eine Seitenansicht als „Containerkomponente“ vor und viel kleinere Ansichten sind einfache „Funktionskomponenten“, denen Parameter (Props) übergeben werden, um Komponenten zu rendern. Natürlich erzwingen sie das Modell nicht, aber Rails hat so starke Namenskonventionen, dass sie, solange Sie Ihre Partial-HTML-Dateien (Komponenten) korrekt benennen, sie findet, wenn Sie versuchen, ein Objekt zu rendern. Die Syntax von
<%= @order %>unterscheidet sich nicht wesentlich von<Order />— nur eine andere Möglichkeit, Werte in ein Ding zu übergeben, das HTML zurückgibt.