JAMstack? More like SHAMstack.

I'm a big fan of JAMstack. It feels like a genuinely positive development for the web. I'm eagerly anticipating the upcoming conferences.

Of any web trend, #jamstack seems like it will be the least regrettable.

— Chris Coyier (@chriscoyier) May 22, 2019

However, I wonder if the acronym fully captures its essence. While I wouldn't suggest changing it – established names have momentum – the core strength lies in static file hosting. This forms the bedrock of its power, unlocking several key advantages:

• CDN Hosting for Everything: Even the HTML (the 'M' in JAMstack) benefits from CDN hosting, a significant speed boost unavailable with traditional approaches. This inherent speed encourages maintaining optimal performance throughout development.
• Simplified Workflow: The development process is streamlined: git clone, npm install, build, and deploy via a dist folder push. Platforms like Netlify provide URLs for every build, even on branches, highlighting the immutability of deployments – a snapshot of files at a specific point in time.
• Powerful Cloud Functions: The absence of traditional server-side languages encourages the use of cloud functions for server-side logic. This architectural approach aligns perfectly with the JAMstack philosophy.

It's crucial to avoid limiting JAMstack to just Jekyll blogs. While static site generators are highly compatible, and pre-built markup is beneficial for speed and SEO, it's not mandatory.

A client-side JavaScript application deploying a <div> and a JavaScript bundle interacting with APIs to build the site still qualifies as JAMstack. It's statically hosted (likely) with cloud functions providing data. <blockquote> <p>I’d say “yes”. Perhaps a little more SSR would be good for all the reasons but meh, not required for a jamstack merit badge.</p> <p>— Chris Coyier (@chriscoyier) May 22, 2019</p> </blockquote> <p>The JAMstack approach encourages maximizing static files, promoting static content whenever feasible. While often referred to as "server-side rendered" (SSR), it's more accurate to describe it as markup generated during a <em>build step</em>, before deployment. Again, not a requirement, but a strong recommendation.</p> <p>We have statically hosted HTML and other assets (CSS, images). Then:</p> <ul> <li> <strong>J</strong>avaScript</li> <li> <strong>A</strong>PIs</li> </ul> <p>These are closely related. JavaScript files are statically hosted, execute, and communicate with APIs (e.g., a GraphQL endpoint) as needed.</p> <p>A hybrid approach is also possible – pre-building some markup, while relying on JavaScript and API calls for dynamic content. Consider an e-commerce site with pre-built homepage and product pages, but a dynamically generated product catalog fetched via API calls.</p> <p>If a new acronym were needed, incorporating static hosting and combining JavaScript and APIs into "APIs" might yield:</p> <p><strong>S</strong>tatic <strong>H</strong>osting, <strong>A</strong>PIs, and <strong>M</strong>arkup, or <strong>SHAMstack</strong>. Perhaps not the best choice!</p> </div>

The above is the detailed content of JAMstack? More like SHAMstack.. For more information, please follow other related articles on the PHP Chinese website!