11–20 of 49 posts
how does the database fit into this?
how does the 'Jamstack' compare to Wordpress or it doesn't?
how does content get edited in the 'Jamstack' like Wordpress?
how is the 'Jamstack' 'mainstream'? compared to what?
why do I have to use Git to use the 'Jamstack'?
What does he mean by pre-rendering? Do they spin-up a browser-like environment on the server and use that to render the page and cache it? Or has that idea been improved upon?
No, it's more like server side rendering with PHP or Ruby, back in the days. I wrote a bit about this topic here: https://dev.to/fllstck/where-when-should-you-render-your-htm...
From my point of view, the "JAMStack" is nothing more than a piece of jargon used to aggregate various "good" ways of building and deploying web applications to trick non-technical business people or entry-level developers into using their services.
There's an absurd amount of money and effort currently being spent marketing this term.
Whatever it is, it's ephemeral, and I recommend anyone to avoid spending time on this unless they want to fall into another marketing funnel.
Earlier quoted context omitted.
At the end of your SPA build process, you spin up a dummy HTTP server and run headless chromium on it (e.g. with puppeteer) to render each route and save the output html. Instead of only /dist/index.html, you have /dist/index.html, /dist/about/index.html etc.
This seems... convoluted.
What does he mean by pre-rendering? Do they spin-up a browser-like environment on the server and use that to render the page and cache it? Or has that idea been improved upon?
At the end of your SPA build process, you spin up a dummy HTTP server and run headless chromium on it (e.g. with puppeteer) to render each route and save the output html. Instead of only /dist/index.html, you have /dist/index.html, /dist/about/index.html etc.
I've been working for a company that heavily caters toward the "JAMStack ecosystem" for a while now. From my point of view, the "JAMStack" is nothing more than a piece of jargon used to aggregate various "good" ways of building and deploying web applications to trick non-technical business people or entry-level developers into using their services. There's an absurd amount of money and effort currently being spent ma…
I've been working for a company that heavily caters toward the "JAMStack ecosystem" for a while now. From my point of view, the "JAMStack" is nothing more than a piece of jargon used to aggregate various "good" ways of building and deploying web applications to trick non-technical business people or entry-level developers into using their services. There's an absurd amount of money and effort currently being spent ma…
Jamstack sounds good on paper but it causes too much trouble for marketing people. The role of a website is to do marketing and if your marketing people can't easily work with it then it's a failure of a website.
Not every website is in the hands of marketing people and even if it were so, any CMS can be used. No need to teach anybody how to use Git.
> Decoupling the frontend from back-end services and platforms enforces a clear contract for how your UI communicates with the rest of the system. It’s kinda weird that the author is trying to associate themselves as bringing this idea mainstream when it already existed and was popular before 2016.
> At that point [in 2016], the idea of fundamentally decoupling the front-end web layer from the back-end business logic layer was only an early trend, and not yet a named architectural approach.
The first named architectural approach I ever learned was three-tier application architecture (presentation, business logic, database,) named to contrast it to the two-tier approach of combining the presentation logic and the business logic in a single layer (often a desktop application that communicated directly with a database.) The problems arising from this mixing and the advantages of separating UI and business logic into different architectural tiers were well known to people writing internal business applications long before web applications took over this niche. I don't know the history prior to my own introduction to the industry, but I wouldn't be surprised if it dated back to the mid-1990s or even earlier.
so many questions about this: how does the database fit into this? how does the 'Jamstack' compare to Wordpress or it doesn't? how does content get edited in the 'Jamstack' like Wordpress? how is the 'Jamstack' 'mainstream'? compared to what? why do I have to use Git to use the 'Jamstack'?
JavaScript + APIs + Markup = JAMstack.
Markup is the content, which can be entered via any method. You can set up a CMS like WordPress or Ghost to serve this role, or you can build your own interface. That markup is then made compatible with various JavaScript libraries via APIs.
But it evolved over the years to the point where "JavaScript" part isn't entirely accurate. You can throw any static site generator in the mix and just use a plugin that will convert content edited via CMS into Markdown files.
It's basically a way for front-end developers to not particularly care about the backend. So instead of making WordPress themes or whatever they make a site using static site generators. Users don't like the look of an editor? You have the ability to change it completely, find a plugin, and the end result is the same website. No need to adapt the theme to the new CMS or bother with migrating content between editors.