PHP vs JAM (Gatsby.js or Next.js) stack, or what's wrong with SSG sites?
The other day my client asked me if I would like to change the technology stack on his new eCommerce project from PHP (I will not specify the CMS and frameworks that I use) to NextJS with Vercel or Gatsby with Netlify, since he successfully uses this on his other projects .
Of course, I managed to dissuade him from changing technologies, but my arguments seemed to me a little far-fetched, since I have no experience in creating SSG sites, and on the Internet I managed to google only a lot of good things ...
Let's discuss if static sites are really as good as people write about them and why Gatsby.js and Next.js each have 50k stars on github
Please, those who have experience with these technologies help me answer the following questions:
1) Are Gatsby.js and Next.js really only suitable for building sites with static content (blogs and docs)?
2) What difficulties can you face when creating an eCommerce site with Gatsby.js or Next.js?
3) What difficulties can you face when creating a large site (let's say a blog with about a million pages) using SSG?
1. Gatsby uses GraphQL for dynamics, Next for static sites.
2. For Gatsby, you have to beat GraphQL (if you are not Facebook level, this is a bad idea). For Next, just implement an eCommerce project separately.
3. Recompilation and data update.
4. If the framework helps in solving the project's tasks - yes. But often this is just a hype.Anonymous
If the site does not have dynamic content that can change on its own, then it is quite possible for yourself to simply generate all the pages and re-generate them if necessary. But this is only suitable for landing pages. If you take something more complicated, for example a blog, you will quickly get tired of generating all the pages after each adding an article. Tolerable, if once a month, if more often it is no longer convenient. If there are many pages, then this business will take more and more time. If there are a million of them, then the whole thing may work slower than the usual cms, due to IO operations.
1. no, you can create sites of any complexity.
2. there will be no need to tune html templates for the engine, only data are chased between the client and the server, not markup. It may be difficult here because of the psychological barrier and unwillingness to change something.
3. I wrote a little higher, time, IO, extra hemorrhage and stress.
4. it is very subjective - who likes what.Evan May
To place the code, please use CodePen or similar tool. Thanks you!