Statisch oder nicht?

Statischer Website -Generator? Warum benutze ich es nicht? KEV Quirks kurzer Kommentar: Kev verwendet WordPress:

Möchten Sie auf Ihrem iPad bloggen? Kein Problem. Möchten Sie auf Ihr Telefon schreiben? Das ist in Ordnung. Geschrieben auf Maschinen, die ich nicht oft benutze? Solange Sie einen Browser haben, gibt es kein Problem.

Zunächst einmal ist erwähnenswert, dass die Verwendung von WordPress nicht bedeutet, dass Sie keine statischen Website -Generatoren verwenden können. WordPress verfügt über eine API, die es ermöglicht, die API während des Erstellungsprozesses aufzurufen, um Ihre Website zu erstellen. Das ist, was Gatsby tut, es hat ein Plugin, das statische Websites exportiert, während Projekte wie die Frontität die Linien verwischen.

Aber ich stimme Kevs Grund zu. Aus all seinen Gründen und unzähligen anderen ist es eine vollkommen akzeptable und oft kluge Wahl. Ich denke, es geht um Robustheit und funktionale Vollständigkeit. Benötigen Sie E-Commerce-Funktionen? WordPress hat es. Benötigen Sie ein Formular? Es gibt viele ausgezeichnete Plugins. Müssen Sie die Funktionalität von CMS verbessern? Sie können den Inhaltstyp und seinen Inhalt steuern. Benötigen Sie Authentifizierung? Dies ist die Kernfunktion. Willst du ein ausgezeichnetes Bearbeitungserlebnis? Gutenberg ist großartig.

Immer wieder baue ich schnell und effizient das, was ich will, mit WordPress, was mich effizient und mächtig fühle. Aber ich möchte nicht besonders über WordPress sprechen. Gleiches gilt für jedes "klassische" CMS. Craft CMS hat nativ eine GraphQL -Api. Wir haben gerade einen Beitrag über das Drupal Jamstack -Webinar gepostet.

In einer relativ neuen Welt statischer Websites kann eine kleine Sache zu einem langen Prozess der Forschung und Implementierung werden, und es fühlt sich an, als wären Sie die einzige Person auf der Erde.

Trotzdem ...

Was halte ich von dem statischen Website -Generator und der Welt von Jamstack? Sie sind großartig .

Ich denke, es gibt viele Vorteile beim Aufbau einer Website auf diese Weise. Die Trennung von Daten und Front-End ist klug. Sehr sicher. Das Entwicklererlebnis ist auch großartig und alles ist großartig, um Vorschau und Git-basiert bereitzustellen. Die Startgeschwindigkeit ist erstaunlich (die HTML -Dienste von CDN ist eine Leistung).

Genau wie ein klassisches serverseitiges CMS verhindert Sie nicht daran, statische Websites zu erstellen, und die Verwendung statischer Websites wird Sie nicht daran hindern, dynamische Dinge zu tun-selbst super erweiterte dynamische Dinge. Josh Comeau hat einen großartigen neuen Artikel, der detailliert in diese Tiefe geht. Er baute eine raffinierte kleine App, die viel mit React in seinem Browser zusammenarbeitet, aber das bedeutet nicht, dass er den größten Teil des Inhalts nicht statisch nicht dienen kann. Er nennt es eine "Änderung in der Denkweise" und bezieht sich auf das, was Sie vielleicht für einen Datenbankanruf benötigen, aber brauchen Sie es wirklich? Wurde der Datenbankaufruf aufgetreten und eine statische Datei generiert? Wenn nicht, kann ein Teil des Inhalts immer noch statisch generiert werden und der Rest kann dynamisch erhalten werden.

Ich freue mich auf eine Welt, in der wir anfangen , das Beste aus beiden Welten zu sehen. Wir generieren so viel Inhalt wie möglich, erhalten so viel Inhalt wie möglich durch die API, dass wir nicht statisch generieren können, und opfern nicht die besten Werkzeuge während des gesamten Prozesses.

Wann wählen Sie eine statische Website ...

• Wenn Sie können, sollten Sie es in Betracht ziehen, da es in Geschwindigkeit und Sicherheit beispiellos ist.
• Wenn Sie an einem Greenfield -Projekt arbeiten.
• Wenn Ihr Projekt aus erstellt wurde und eine zugängliche API verwendet, können Sie die API während des Build -Prozesses aufrufen und sie verwenden, nachdem der anfängliche HTML geladen wurde.
• Wenn ein statischer Website -Generator gut für das aussieht, was Sie tun.
• Wenn die Kostenanalyse zeigt, dass sie billiger ist.
• Wenn bestimmte Funktionen (z. B. Erstellung Vorschau) für den Workflow sehr hilfreich sind.

Wann wählen Sie serverseitige Software ...

• Wenn Sie die Funktionalität eines klassischen CMS (wie WordPress) benötigen und die technische Schulden von dort zu hoch sind.
• Wenn Sie in einem serverseitigen Rendering-Projekt (Ruby on Rails, Python usw.) tief involviert waren und nicht vorhandenen Problemen aufgetreten sind.
• Wenn Ihr Team das meiste Fachwissen auf dem Gebiet hat.
• Wenn die Kostenanalyse zeigt, dass sie billiger ist.
• Wenn es keine gute statische Lösung für das gibt, was Sie erstellen möchten (z. B. Forum -Software).
• Wenn Sie sich in extremen Situationen wie Millionen von URLs befinden und die statische Bauzeit zu lang ist.

Der falsche Grund, eine statische Website zu wählen ...

• Sie müssen einen Server verwenden. (Warum? Sie können die API immer noch zur Erstellung oder Laufzeit auf dem Server aufrufen.)
• Sie brauchen Authentifizierung. (Warum? Jamstack kann die Authentifizierung mit JWT usw. perfekt implementieren)
• Sie haben noch nicht einmal den Jamstack -Ansatz in Betracht gezogen.

Der Fehlergrund für die Auswahl der serverseitigen Software ...

• Sie haben noch nicht einmal den Jamstack -Ansatz in Betracht gezogen.
• Da Sie der Meinung sind, dass die Verwendung komfortabler/vorhandener/klassischer/reifen/unterstützter gut unterstützter Tools Sie daran hindert, statisch etwas zu erstellen.
• Fragen wie SEO. (Wenn überhaupt, sollte das statische Rendering besser abschneiden. Es ist jedoch verständlich, ob sich die Umstellung auf statische Anrufe an Client -Anrufe wenden kann, um Produktdaten usw. zu erhalten.)

Das obige ist der detaillierte Inhalt vonStatisch oder nicht?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!