5 Myths About Jamstack

Jamstack is not a new thing. Although the term officially emerged in 2016, the technology and architecture it describes have long existed. Recently, Jamstack has received widespread attention, and major websites and publications have published related reports, and many activities, newsletters, podcasts, etc. are emerging that focus on Jamstack. As a developer who closely follows Jamstack, I even observed a significant increase in related discussions on Twitter, many of whom are first exposed to the concept.

Hot discussions are also accompanied by criticism. Some of the criticisms are justified, and I'll talk about some of them later, but others seem to be based on some of the persistent common misunderstandings about Jamstack, and that's exactly what I'm going to solve first. So let's take a look at five common misunderstandings about Jamstack that I've encountered and refute them one by one. Like many misconceptions, they are usually based on some real situations, but lead to false conclusions.

Misunderstanding 1: Jamstack is just a replacement packaging for static websites

JAMStack 99.9% is brand marketing and 0.1% is actual content. ?? https://www.php.cn/link/33f976eca39cccf5a14627fc9f6cf1b9

— Nicole Sullivan – Black Lives Matter (@stubbornella) February 9, 2020

Yes, as I mentioned earlier, the term “Jamstack” is arguably a repackaging of what we previously called “static websites”. This is not intended to mislead or sell products that have not yet been fully formed—quite the contrary. The term “static website” has long been unable to describe what people are building. Websites built with Static Website Generator (SSG) often contain a variety of dynamic content and features.

Static websites are mainly considered blogs and documents, and their user interface is mainly fixed. The scope of the interaction may be just embedded comments and contact forms. On the other hand, the Jamstack website includes functions such as user authentication, dynamic content, e-commerce, user-generated content, etc.

Need evidence? Some well-known companies and websites built with Jamstack include Smashing Magazine, Sphero, Postman, Prima, Impossible Foods, and TriNet to name a few.

Misunderstanding 2: Jamstack website is fragile

Jay Freestone, in the article "Ask about JAMStack: You May Need a Backend"

Reading the dependency list of Smashing Magazine is like node_modules on the server, including Algolia, GoCommerce, GoTrue, GoTell and various Netlify services, to name just a few. It is of great value to know what can be outsourcing (and when) but it is worth noting that complexity is introduced in the obvious attempt to “return to the foundation.” That doesn’t have to say the potential vulnerability that comes with relying on so many different third-party services.

Yes, to implement dynamic functionality that distinguishes Jamstack from static websites, Jamstack projects usually rely on various services, including first-party or third-party services. Some believe this makes Jamstack website particularly vulnerable for two reasons. First, they say that if any part fails, the functionality of the entire website will crash. Second, your infrastructure becomes too dependent on tools and services you don't have.

Let's solve the first argument. Most of the content of the Jamstack website should be pre-rendered. This means that when a user visits the website, the page and most of its content will be delivered from the CDN as a static resource. That's why Jamstack gets most of the speed and security. Dynamic features—such as shopping cart, authentication, user-generated content, and search—rely rely on a combination of serverless functions and APIs to work.

Broadly speaking, an application will call a serverless function that acts as a backend to connect to the API. For example, if our e-commerce capabilities rely on Stripe's API to work and Stripe goes down, then, yes, our e-commerce capabilities won't work. However, it is important to note that the website will not go down. It can handle this issue gracefully by telling the user the problem. Server-side rendering pages that rely on the Stripe API for e-commerce will face the same problem. Assuming that the server-side rendering page is still calling back-end code asynchronously for payment, it will not be more vulnerable or less fragile than the Jamstack version. On the other hand, if server-side rendering actually relies on API calls, users may get stuck waiting for a response or receive an error message (anyone using the network is very familiar with this).

As for the second argument, it is difficult to measure the degree to which Jamstack web applications and server-side rendering applications rely on third parties. Many server-side rendering applications today still rely on APIs to implement a lot of functionality, as this allows faster development, leverage providers’ specific areas of expertise, offloading responsibilities for legal and other compliance issues, and more. In these cases, the server-side rendered version will again not be more dependent or less dependent than the Jamstack version. Admittedly, if your application relies primarily on internal or homemade solutions, then things may be different.

Misunderstanding 3: It's difficult to edit content

Kev Quirk, in the article "Why I Don't Use Static Website Generator":

Having to SSH into the Linux box and then edit the article on Vim seems like a very high barrier to entry when it comes to mobile writing. Whether you like it or not, the world today is mobile-first, so mobile writing should be easy.

This problem feels like a legacy of static websites in the past. To be clear, you don't need SSH to enter the Linux box to edit your website content. There are a wide variety of headless CMS options, from completely free and open source to commercial products that provide content for large enterprises. The editing features they offer are comparable to any traditional CMS (I've talked about this before). The point is that there is no reason to manually edit Markdown, YAML, or JSON files, even on your blog side project. Not sure how to connect all these parts? We have a solution, too!

A reasonable criticism is that headless CMS and the build process may cause disconnection between the content being edited and the changes on the website. It's hard to accurately preview the impact of changes on a live website before publishing, or without some complex build preview process. The ecosystem is solving this problem. Companies like Stackbit (where I work) are building tools that make this process seamless.

We are not the only ones who are committed to solving this problem. Other solutions include TinaCMS and Gatsby Preview. I think we're about to implement the simplicity of WYSIWYG editing on a tool like Wix on Jamstack.

Misunderstanding 4: SEO on Jamstack is hard

Kym Ellis, in the article "What JAMstack means for marketing":

Giving up the concept of plugin and choosing a "just HTML" JAMstack website doesn't mean you have to give up on features or suddenly need to learn coding like a front-end developer to manage the website and its content.

I haven't seen this issue happen frequently in recent years, and I think it's mostly a legacy criticism from the static website era, when managing metadata related to SEO involved manual editing of YAML-based frontmatters. People worry that doing SEO correctly can become tedious and difficult to maintain, especially if you want to inject different metadata into each generated unique page, or create structured data like JSON-LD, which is essential to enhance your search list.

Jamstack’s advances in content management often address the complexity of maintaining SEO metadata. Furthermore, since the page is pre-rendered, adding a sitemap and JSON-LD is relatively simple, provided that the required metadata exists. Pre-rendering makes it easy to create resources that search engines (i.e. Google) that require indexing websites, and they are also combined with CDNs, making it easier to achieve performance benchmarks that improve website rankings.

Basically, Jamstack is good at "technical SEO" while also providing content editors with the keywords and other metadata they need. For a more comprehensive understanding of Jamstack and SEO, I highly recommend checking out Bejamas's Jamstack SEO guide.

Misunderstanding 5: Jamstack requires a lot of JavaScript frameworks

A beautiful website that promotes the advantages of "JAMstack" is very useful if you try to sell a normal website to management obsessed with the latest frameworks.

– jdietrich, Hacker News

Recently, Jamstack seems to have become synonymous with front-end JavaScript frameworks. Indeed, many of the most famous solutions rely on front-end frameworks, including Gatsby (React), Next.js (React), Nuxt (Vue), VuePress (Vue), Gridsome (Vue), and Scully (Angular). This seems to be exacerbated by confusion about "J" in Jamstack. While it stands for JavaScript, this does not mean that all Jamstack solutions are JavaScript-based, nor does it mean that they all require npm or JavaScript frameworks.

In fact, many of the most widely used tools are not built with JavaScript, especially Hugo (Go), Jekyll (Ruby), Pelican (Python) and the recently released Bridgetown (Ruby). At the same time, tools like Eleventy are built with JavaScript, but do not rely on the JavaScript framework. None of these tools prevents the use of JavaScript frameworks, but they don't need it.

The point here is not to abandon JavaScript frameworks or use their tools. These are great tools that are successfully used by many developers. JavaScript frameworks can be very powerful tools that can simplify some very complex tasks. The point here is simply that the idea of ​​requiring a JavaScript framework to use Jamstack is wrong – Jamstack has 460 styles!

Where we can improve

Is that true? Jamstack is an ideal world of web development where everything is not only perfect, but it is very easy. Unfortunately, not. Jamstack has a lot of reasonable criticism.

Simplicity

Sebastian De Deyne, in the article "Things to Think (and Questions) after Dealing with JAMstack":

In my experience, JAMstack (JavaScript, APIs, and tags) is great until it isn't great anymore. When one day I need to add some dynamic content—and this day always comes—I start scratching my head.

To be honest: It's not easy to get started with Jamstack. Of course, it may not be particularly difficult to build a blog or a simple website using a static website generator. But, trying to build a real website with any dynamic functionality, things quickly get complicated.

You usually come across many options to complete tasks, which makes weighing the pros and cons difficult. One of the best aspects of Jamstack is that it is not prescriptive, but it can make it seem inaccessible, leaving the impression that it may not be suitable for complex tasks.

Binding Service

When you really start building those dynamic features, your website may end up relying on a range of services and APIs. You might call headless CMS to get content, call serverless functions for APIs to perform payment transactions, search services like Algolia, etc. Putting all these parts together can be a very complex task. Adding to the fact that each section usually has its own dashboard and API/SDK updates, things get even more complicated.

That's why I think services like Stackbit and tools like RedwoodJS are important because they bring together the different parts behind the Jamstack website and make those parts easier to build and manage.

Overuse of frameworks

In my opinion, our dependence on JavaScript frameworks in modern front-end development has been much-needed to question recently. As Tim Kadlec's recent article states, there are trade-offs. As I said before, you don't need a JavaScript framework to work in Jamstack.

However, this impression arises because many Jamstack tools rely on JavaScript frameworks, and the way we teach Jamstack is mainly focused on using frameworks. I understand the reason for this - many Jamstack developers are familiar with JavaScript frameworks and it is impossible to teach each tool, so you choose the one you like. Nevertheless, I personally think that Jamstack's long-term success depends on its flexibility, which (although I mentioned simplicity above) means we need to showcase the various solutions it offers – whether using JavaScript frameworks or not.

Where to go next

Wow, you did it! I know I have a lot to say, maybe more than I realized when I started writing, so I won't bother you with lengthy conclusions, other than to say, obviously, I've presented these misunderstandings from the perspective of someone who is very convinced of the value of Jamstack, despite its flaws!

If you are looking for a good article about when and when not choosing Jamstack over server-side rendering, check out Chris Coyier's recent article Static or not? 》.

The above is the detailed content of 5 Myths About Jamstack. For more information, please follow other related articles on the PHP Chinese website!