Random Notes from a JAMstack Roundtable

A JAMstack roundtable seminar was held last weekend at Web Unleashed. Here are some scattered notes from this experience.

• I was surprised at first that the "M" in "JAMstack" stands for "Markup" ("M" in HTML, sometimes used interchangeably with HTML), not "Markdown" (the language compiled into HTML). This has indeed caused a lot of confusion. The answer is: JAMstack does not require Markdown. This confusion stems from the fact that Markdown is often used with static website generators, which are closely related to JAMstack.
• For the first time I realized that every website hosted on Netlify, GitHub Pages, or S3 buckets ("static hosting") is JAMstack. It's indeed SHAMstack! :). The static hosting (SH) part of JAMstack is perhaps the most important aspect.
• One has only one index.html file,<div> And a bunch of JavaScript websites, the client renders everything else, can also be JAMstack. Assuming that the data it needs is either built-in or comes from an API on another server (rather than the server hosting that index.html file), then it's JAMstack.<li> There is a difference between <em>a technical</em> JAMstack and a <em>spiritual</em> JAMstack. The above mentioned may be more technical, while the spiritual level hopes to pre-render more pages.<ul> <li> The advantages of pre-rendering are: fast, CDN hosting, secure and SEO-friendly. Many frameworks offer it as part of their capabilities, so you might as well take advantage of it. Pre-rendering doesn't mean static, JavaScript can still load and achieve cooler effects.</li> <li> There is no doubt that static website generators and JAMstack are the best partners. But JAMstack wants you to have a broader perspective. What if you have 50,000 product pages and the generation is too slow or impractical? No problem, you can pre-render other pages, but just create a framework for the product page and get product page data through the API as needed. What should I do if some pages are absolutely not statically hosted? No problem, you can proxy statically hostable pages to a static server without changing other pages. Want to go all out for static hosting, but need a server to implement some functionality? Consider using serverless functions, which can be said to be spiritual companions for static hosting.</li> <li> People really want to know <em>why</em> . Why bother to do these things? If you can build a website with WordPress that meets all your needs, why not? I ended up defending my use of WordPress from a feature standpoint. If I have unlimited time and a whole new starting point, even if I still use WordPress as a CMS, I think I might be on a path where at least some pre-rendering is done, if not completely decoupling and building my own front-end, just using the data through the API. But perhaps the most convincing answer to <em>why</em> comes down to <em>speed</em> , <em>safety</em> , and <em>resilience</em> , all of which are immediately available when you use JAMstack. It provides a great foundation to build.</li> </ul> </li> </div>

The above is the detailed content of Random Notes from a JAMstack Roundtable. For more information, please follow other related articles on the PHP Chinese website!