5 Mythen über Jamstack

Jamstack ist keine neue Sache. Obwohl der Begriff offiziell im Jahr 2016 entstanden ist, gab es die Technologie und Architektur, die sie beschreibt. Vor kurzem hat Jamstack weit verbreitete Aufmerksamkeit erhalten, und wichtige Websites und Veröffentlichungen haben verwandte Berichte veröffentlicht, und viele Aktivitäten, Newsletter, Podcasts usw. konzentrieren sich auf Jamstack. Als Entwickler, der Jamstack genau folgt, habe ich sogar einen signifikanten Anstieg der verwandten Diskussionen auf Twitter beobachtet, von denen viele erstmals dem Konzept ausgesetzt sind.

Heiße Diskussionen werden auch von Kritik begleitet. Einige der Kritikpunkte sind gerechtfertigt, und ich werde später über einige von ihnen sprechen, aber andere scheinen auf einigen anhaltenden gemeinsamen Missverständnissen über Jamstack zu beruhen, und genau das werde ich zuerst lösen. Schauen wir uns also fünf häufige Missverständnisse über Jamstack an, denen ich begegnet bin, und widerlegen sie einzeln. Wie viele Missverständnisse basieren sie normalerweise auf einigen realen Situationen, führen jedoch zu falschen Schlussfolgerungen.

Missverständnis 1: Jamstack ist nur eine Ersatzverpackung für statische Websites

JamStack 99,9% ist Markenmarketing und 0,1% ist der tatsächliche Inhalt. ? https://www.php.cn/link/33f976eca39cccf5a14627fc9f6cf1b9

- Nicole Sullivan - Black Lives Matter (@Stubbornella) 9. Februar 2020

Ja, wie ich bereits erwähnt habe, ist der Begriff „Jamstack“ wohl eine Neuverpackung dessen, was wir zuvor als „statische Websites“ bezeichnet haben. Dies ist nicht dazu gedacht, Produkte in die Irre zu führen oder zu verkaufen, die noch nicht vollständig gebildet wurden - das Gegenteil. Der Begriff „statische Website“ konnte seit langem nicht beschreiben, was Menschen aufbauen. Websites, die mit statischer Website Generator (SSG) erstellt wurden, enthalten häufig eine Vielzahl von dynamischen Inhalten und Funktionen.

Statische Websites werden hauptsächlich als Blogs und Dokumente betrachtet, und ihre Benutzeroberfläche wird hauptsächlich behoben. Der Umfang der Wechselwirkung kann nur eingebettete Kommentare und Kontaktformulare sein. Andererseits enthält die JamStack-Website Funktionen wie Benutzerauthentifizierung, dynamische Inhalte, E-Commerce, Benutzer generierte Inhalte usw.

Benötigen Sie Beweise? Einige bekannte Unternehmen und Websites, die mit JamStack gebaut wurden, sind Smashing Magazine, Sphero, Postman, Prima, Impossible Foods und Trinet, um nur einige zu nennen.

Missverständnis 2: Jamstack -Website ist zerbrechlich

Jay Freestone, in dem Artikel "Fragen Sie nach Jamstack: Sie benötigen möglicherweise ein Backend"

Das Lesen der Abhängigkeitsliste des Smashing Magazins ist wie Node_Modules auf dem Server, einschließlich Algolien, Gocommerce, Gotrue, Gotell und verschiedenen Netlify -Diensten, um nur einige zu nennen. Es ist von großem Wert zu wissen, was Outsourcing sein kann (und wann), aber es ist erwähnenswert, dass Komplexität in dem offensichtlichen Versuch eingeführt wird, „zur Stiftung zurückzukehren“. Das muss nicht sagen, wie potenziell anfällig mit der Stütze auf so viele verschiedene Dienste von Drittanbietern einhergeht.

Ja, um dynamische Funktionen zu implementieren, die Jamstack von statischen Websites unterscheidet, beruhen Jamstack-Projekte normalerweise auf verschiedene Dienste, einschließlich Erstanbieter- oder Drittanbieterdienste. Einige glauben, dass dies die Jamstack -Website aus zwei Gründen besonders anfällig macht. Erstens sagen sie, dass die Funktionalität der gesamten Website, wenn ein Teil fehlschlägt, abstürzt. Zweitens wird Ihre Infrastruktur zu sehr von Tools und Diensten abhängig, die Sie nicht haben.

Lassen Sie uns das erste Argument lösen. Der größte Teil des Inhalts der Jamstack-Website sollte vorbereitet sein. Dies bedeutet, dass wenn ein Benutzer die Website besucht, die Seite und der größte Teil seiner Inhalte von der CDN als statische Ressource geliefert werden. Deshalb bekommt Jamstack den größten Teil der Geschwindigkeit und Sicherheit. Dynamische Funktionen-wie der Einkaufswagen, die Authentifizierung, benutzergenerierte Inhalte und die Suche-verlassen sich nicht auf eine Kombination aus serverlosen Funktionen und APIs, um zu funktionieren.

Im Großen und Ganzen ruft eine Anwendung eine serverlose Funktion auf, die als Backend für eine Verbindung zur API fungiert. Wenn unsere E-Commerce-Funktionen beispielsweise auf der Arbeit von Stripe angewiesen sind, um zu arbeiten und Stripe sinkt, funktioniert unsere E-Commerce-Funktionen nicht. Es ist jedoch wichtig zu beachten, dass die Website nicht sinken wird. Es kann dieses Problem anmutig behandeln, indem es dem Benutzer das Problem mitteilt. Die serverseitigen Rendering-Seiten, die auf der Stripe-API für E-Commerce angewiesen sind, werden dem gleichen Problem konfrontiert. Unter der Annahme, dass die serverseitige Rendering-Seite noch asynchron Back-End-Code zur Zahlung anruft, ist sie nicht anfälliger oder weniger zerbrechlicher als die Jamstack-Version. Wenn dagegen das serverseitige Rendering tatsächlich auf API-Aufrufen angewiesen sind, können Benutzer auf eine Antwort warten oder eine Fehlermeldung erhalten (jeder, der das Netzwerk verwendet, ist damit sehr vertraut).

Was das zweite Argument betrifft, ist es schwierig, den Grad zu messen, in dem Jamstack-Webanwendungen und die serverseitigen Rendering-Anwendungen auf Dritten stützen. Viele serverseitige Rendering-Anwendungen stützen sich heute weiterhin auf APIs, um eine Menge Funktionen zu implementieren, da dies eine schnellere Entwicklung ermöglicht, die spezifischen Fachgebiete der Anbieter, die Verantwortlichkeiten für rechtliche und andere Compliance-Probleme und vieles mehr ausladen. In diesen Fällen ist die serverseitige Version wieder nicht abhängig oder weniger abhängig als die Jamstack-Version. Zugegeben, wenn Ihre Bewerbung hauptsächlich auf interne oder hausgemachte Lösungen beruht, können die Dinge unterschiedlich sein.

Missverständnis 3: Es ist schwierig, Inhalte zu bearbeiten

Kev Quirk, im Artikel "Warum ich keinen statischen Websitegenerator verwende":

SSH in das Linux -Box und dann den Artikel über VIM bearbeiten zu müssen, scheint eine sehr hohe Barriere für den Eintritt zu sein, wenn es um mobiles Schreiben geht. Ob es Ihnen gefällt oder nicht, die heutige Welt ist mobile First, daher sollte das mobile Schreiben einfach sein.

Dieses Problem fühlt sich in der Vergangenheit wie ein Erbe statischer Websites an. Um klar zu sein, benötigen Sie kein SSH, um das Linux -Feld einzugeben, um Ihren Website -Inhalt zu bearbeiten. Es gibt eine Vielzahl von kopflosen CMS -Optionen, von komplett freien und Open Source bis hin zu kommerziellen Produkten, die Inhalte für große Unternehmen bieten. Die von ihnen angebotenen Bearbeitungsfunktionen sind vergleichbar mit jedem traditionellen CMS (ich habe bereits darüber gesprochen). Der Punkt ist, dass es keinen Grund gibt, Markdown-, YAML- oder JSON -Dateien selbst in Ihrem Blog -Seitenprojekt manuell zu bearbeiten. Sie sind sich nicht sicher, wie Sie all diese Teile verbinden können? Wir haben auch eine Lösung!

Eine angemessene Kritik ist, dass kopfloser CMS und der Erstellungsprozess eine Trennung zwischen dem bearbeiteten Inhalt und den Änderungen auf der Website verursachen können. Es ist schwierig, die Auswirkungen von Änderungen auf einer Live -Website vor der Veröffentlichung oder ohne komplexe Vorschau -Vorschau -Prozesse genau voranzutreiben. Das Ökosystem löst dieses Problem. Unternehmen wie Stackbit (wo ich arbeite) bauen Tools, die diesen Prozess nahtlos machen.

Wir sind nicht die einzigen, die sich für die Lösung dieses Problems entscheiden. Weitere Lösungen sind Tinacms und Gatsby Preview. Ich denke, wir werden die Einfachheit der Bearbeitung von Wysiwyg in einem Tool wie Wix auf Jamstack implementieren.

Missverständnis 4: SEO auf Jamstack ist schwer

Kym Ellis, in dem Artikel "Was Jamstack für Marketing bedeutet":

Wenn Sie das Konzept des Plugins aufgeben und eine Jamstack-Website "Just HTML" auswählen, müssen Sie Funktionen aufgeben oder plötzlich das Codieren wie ein Front-End-Entwickler lernen, um die Website und deren Inhalt zu verwalten.

Ich habe dieses Problem in den letzten Jahren nicht häufig gesehen, und ich denke, es ist hauptsächlich eine alte Kritik aus der statischen Website-Ära, als die Verwaltung von Metadaten im Zusammenhang mit der SEO manuelle Bearbeitung von YAML-basierten Frontmatters verwaltet. Die Leute machen sich Sorgen, dass SEO richtig mühsam und schwierig zu pflegen sein kann, insbesondere wenn Sie in jede erzeugte eindeutige Seite unterschiedliche Metadaten injizieren oder strukturierte Daten wie JSON-LD erstellen möchten, was für die Verbesserung Ihrer Suchliste unerlässlich ist.

Die Fortschritte von Jamstack im Content -Management befassen sich häufig mit der Komplexität der Aufrechterhaltung der SEO -Metadaten. Da die Seite vorgefertigt ist, ist das Hinzufügen einer Sitemap und JSON-LD relativ einfach, vorausgesetzt, die erforderlichen Metadaten existieren. Durch das Vorrendern werden Ressourcen erstellt, die Suchmaschinen (d. H. Google) für Indizing-Websites erfordern, und sie werden auch mit CDNs kombiniert, sodass es einfacher ist, Leistungsbenchmarks zu erreichen, die die Rangliste der Website verbessern.

Grundsätzlich ist JamStack gut in "Technical SEO" und bietet gleichzeitig Inhaltseditoren die Keywords und andere Metadaten, die sie benötigen. Für ein umfassenderes Verständnis von Jamstack und SEO empfehle ich dringend, Bejamas 'Jamstack SEO -Leitfaden zu überprüfen.

Missverständnis 5: Jamstack erfordert viele JavaScript -Frameworks

Eine schöne Website, die die Vorteile von "Jamstack" fördert, ist sehr nützlich, wenn Sie versuchen, eine normale Website an das Management zu verkaufen, das von den neuesten Frameworks besessen ist.

- JDietrich, Hacker News

In letzter Zeit scheint Jamstack ein Synonym für Front-End-JavaScript-Frameworks geworden zu sein. In der Tat stützen sich viele der berühmtesten Lösungen auf Front-End-Frameworks, darunter Gatsby (React), Next.js (React), Nuxt (VUE), VuePress (Vue), Gridsome (VUE) und Scully (Angular). Dies scheint durch Verwirrung über "J" in Jamstack noch verstärkt zu werden. Während es für JavaScript steht, bedeutet dies nicht, dass alle JamStack-Lösungen JavaScript-basiert sind, und dies bedeutet auch nicht, dass sie alle NPM- oder JavaScript-Frameworks benötigen.

Tatsächlich werden viele der am häufigsten verwendeten Werkzeuge nicht mit JavaScript, insbesondere Hugo (Go), Jekyll (Ruby), Pelican (Python) und dem kürzlich veröffentlichten Bridgetown (Ruby), gebaut. Gleichzeitig werden Tools wie ELEDS mit JavaScript gebaut, verlassen sich jedoch nicht auf das JavaScript -Framework. Keines dieser Tools verhindert die Verwendung von JavaScript -Frameworks, benötigt es jedoch nicht.

Hier geht es darum, JavaScript -Frameworks aufzugeben oder ihre Tools zu verwenden. Dies sind großartige Werkzeuge, die von vielen Entwicklern erfolgreich eingesetzt werden. JavaScript -Frameworks können sehr leistungsstarke Tools sein, die einige sehr komplexe Aufgaben vereinfachen können. Der Punkt hier ist einfach, dass die Idee, ein JavaScript -Framework für die Verwendung von JamStack zu benötigen, falsch ist - Jamstack hat 460 Stile!

Wo wir uns verbessern können

Ist das wahr? Jamstack ist eine ideale Welt der Webentwicklung, in der nicht nur alles perfekt ist, sondern auch sehr einfach. Leider nicht. Jamstack hat eine Menge angemessener Kritik.

Einfachheit

Sebastian de Deyne, in dem Artikel "Dinge zu denken (und Fragen) nach dem Umgang mit Jamstack":

Nach meiner Erfahrung ist Jamstack (JavaScript, APIs und Tags) großartig, bis es nicht mehr großartig ist. Wenn ich eines Tages dynamische Inhalte hinzufügen muss - und dieser Tag kommt immer -, fange ich an, meinen Kopf zu kratzen.

Um ehrlich zu sein: Es ist nicht einfach, mit Jamstack zu beginnen. Natürlich ist es möglicherweise nicht besonders schwierig, einen Blog oder eine einfache Website mit einem statischen Website -Generator zu erstellen. Der Versuch, eine echte Website mit dynamischen Funktionen zu erstellen, wird jedoch schnell kompliziert.

Normalerweise stoßen Sie auf viele Optionen, um Aufgaben zu erledigen, was das Wiegen der Vor- und Nachteile erschwert. Einer der besten Aspekte von Jamstack ist, dass es nicht vorgeschrieben ist, aber es kann unzugänglich erscheinen, so dass der Eindruck, dass es möglicherweise nicht für komplexe Aufgaben geeignet ist.

Bindungsservice

Wenn Sie diese dynamischen Funktionen wirklich erstellen, kann sich Ihre Website auf eine Reihe von Diensten und APIs verlassen. Sie können kopfloses CMS anrufen, um Inhalte zu erhalten, serverlose Funktionen für APIs aufzurufen, um Zahlungstransaktionen durchzuführen, Suchdienste wie Algolie usw. zusammenzustellen, kann eine sehr komplexe Aufgabe sein. Hinzu kommt, dass jeder Abschnitt normalerweise über ein eigenes Dashboard und die API/SDK -Updates verfügt, und die Dinge werden noch komplizierter.

Deshalb denke ich, dass Dienste wie Stackbit und Tools wie RedwoodJS wichtig sind, da sie die verschiedenen Teile hinter der Jamstack -Website zusammenbringen und diese Teile leichter zu erstellen und zu verwalten.

Überbeanspruchung von Frameworks

Meiner Meinung nach war unsere Abhängigkeit von JavaScript-Frameworks in der modernen Front-End-Entwicklung in letzter Zeit dringend benötigt. Wie der jüngste Artikel von Tim Kadlec besagt, gibt es Kompromisse. Wie ich bereits sagte, brauchen Sie kein JavaScript -Framework, um in Jamstack zu arbeiten.

Dieser Eindruck entsteht jedoch, da viele Jamstack -Tools auf JavaScript -Frameworks beruhen und die Art und Weise, wie wir Jamstack unterrichten, hauptsächlich auf die Verwendung von Frameworks konzentriert. Ich verstehe den Grund dafür - viele Jamstack -Entwickler kennen JavaScript -Frameworks und es ist unmöglich, jedes Tool zu unterrichten. Sie wählen also die, die Sie mögen. Dennoch denke ich persönlich, dass Jamstacks langfristiger Erfolg von seiner Flexibilität abhängt, was (obwohl ich die Einfachheit oben erwähnt habe) bedeutet, dass wir die verschiedenen Lösungen präsentieren müssen-ob sie JavaScript-Frameworks verwenden oder nicht.

Wohin als nächstes gehen

Wow, du hast es getan! Ich weiß, dass ich viel zu sagen habe, vielleicht mehr als ich beim Schreiben merkte, also werde ich Sie nicht mit langen Schlussfolgerungen stören, außer zu sagen, offensichtlich habe ich diese Missverständnisse aus der Perspektive von jemandem vorgestellt, der den Wert von Jamstack trotz seiner Mängel sehr überzeugt ist!

Wenn Sie nach einem guten Artikel darüber suchen, wann und wenn Sie nicht JAMStack über das Server-Side-Rendering wählen, lesen Sie den aktuellen Artikel von Chris Coyier statisch oder nicht? 》.

Das obige ist der detaillierte Inhalt von5 Mythen über Jamstack. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!