I am still getting people reading this article nearly two years after writing it - which is awesome! But unfortunately, a lot of what is in this ar...
For further actions, you may consider blocking this person and/or reporting abuse
One thing I do wan't to mention (that sadly the article does not reflect)
Is the fact you can actually export your NextJS application as a static rendered app.
nextjs.org/features/static-exporting
And the documentation does also reflect this.
nextjs.org/docs#static-html-export
There are some limitations but generally you can copy just the dist folder and you have the app statically generated :)
(though there is some more to it, but it is not that hard, and pretty much reflects the same process as Gatsby)
sadly but true, after exported, dynamic routing like [somewhat].js path will not be working out-of-the-box :(
Hi @stackoverprof
Are you meaning that [somewhat].js is not working?
You have to precalculate the routes (or rather the possible outcomes of the route) for it to be exporting the specific pages - this is particularly done if the fallback is set to false:
nextjs.org/docs/basic-features/dat...
It will return a 404 (naturally) unless you specify the pages for export:
nextjs.org/docs/basic-features/dat...
If however you want to have some paths statically generated and then dynamically generate the rest (think a large ecommerce site, or blog/dynamic pages on a otherwise statically generated site) - you can use the fallback: true (as it will fallback to data fetching)
See this for more info:
nextjs.org/docs/basic-features/dat...
Thankyou
This is honestly the best article I've ever read on Gatsby vs Next.js. Thank you for your contribution!
That means a lot. Thank you, my friend 🙏
I started to learn JavaScript a few days ago and I keep hearing about these frameworks, the most common one I keep hearing about repeatedly is React.
Is there any framework that can make my "learning JavaScript" life easier from the start, and then also pay off later or should choosing a framework wait until I've properly learned JavaScript on its own?
Don't focus on frameworks, first master vanillaJS, there're thousands of resources out there such as YDKJS by Kyle Simpson or Eloquent JS or flavio copes JS handbook. I suggest buying Traversy Media course on udemy of vanillaJS, after that continue with react then the backend, NODE + Express
Once you got the grasp of 1 framework the rest are the same, IMO they're always trying to reinvent the wheel...
PS:forgot about testing, after Frontend and Backend make projects WITH TESTS, i vouch for jest... in today's market this is a must
Hm partially agree, but not completely ... sure, VanillaJS is an important foundation to master, but if you then want to get good at React (and for good reasons, e.g. because the job market for React devs is huge and booming), well that's a whole new different world, you'll again have to climb a big mountain ...
The basics of React are simple but when you reach the stage where you need to know all of these prototypical 'patterns' (HOCs, render props, hooks, context, suspend, and so on), and when to use Redux (and when not), with all of its countless variations (thunks, sagas, whatnot) and 'best practices' ... welcome to a brave new world - React, simple to learn, difficult to master :-)
I just want to make the point that, yes, VanillaJS is important, but A Knowledgeable JS Programmer does not automatically A React Guru make ... it requires substantial extra effort.
VanillaJS can replace most frameworks for building reactive static sites. If you get to master it, no need to learn React to make a simple site.
It is very important to learn the foundations.Once you master the foundation , you can switch to whatever the frameworks for your projects !
Go for vanilla, learn how to manipulate the dom, why jQuery is redundant, learn ES6, array/object methods. Then learn framework that is up to date and people are hiring for knowing it. Frameworks are like cars, everyone argues that certain brand is the best but learning to drive is what matters .
I'm now wondering what the most in-demand (from a hiring / salary perspective) framework is. My goal is to learn enough to get hired but I also want to ensure I have the best salary prospects at the same time. My initial thinking was that "full stack" development must surely be in the highest demand but now I'm thinking it might be smarter to really specialize in pure JavaScript and just one framework.
TL;DR : strategy I followed = cover basics + interview questions, get a job, learn rest on the go. Choice is yours tho.
I was a php dev 1 year before. Took a break for 4 months, learnt basics of JS, Node and Vue, got hired for a reactjs position! Now I'm a full stack dev (react and rails!).
I may not be crazy good these (which is very difficult to become, especially in highly volatile js ecosystem), but brave enough to believe I can make things working with any of these tech. Personally I felt learning speed is much faster when there are deadlines and while working on projects that matters.
I'll highly recommend to follow twitter accounts of devs like dan abramov, where you can get lot of relevant info. Being up to date is critical to survive in JS world IMO. I also follows some sub reddits for webdev, js, react etc. YouTube tutorials of traversy media, academind and net ninja helped me a lot in the initial days.
So these are specifically React-based frameworks. A framework for a framework shall we say ;)
I would stick doing what you are doing for now - check out javascript30.com - when you get comfortable hacking together little projects then, by all means, check out a framework. I think actually it can make the process easier, but I wouldn't recommend doing so before learning the JS fundamentals.
I personally would try and become an expert in vanilla JavaScript... es5 & es6+. Then learn how to serve it up with Node.js and Express. Then learn about webpack and Babel! 😃😃 It will help you understand moving parts of JavaScript and eventually you should learn React.js library . (not a framework) and then Redux. 👍
This is the same problem I had. Whats the point of learning React/gatsby for making sites when you can make reactive static sites with vanillaJs that behave exactly like a native app. This will allow you to master javascript and a do the same that a react app does. Still theres cases where you might want to use React, but it’s overkill for a simple site/blog.
Hmm but isn't the point of something like Gatsby to have you up and running with a blog in a manner of minutes? Who wants to spend all that time setting up each time, the boiler plate can be overwhelming.
I suppose the question is: do you want to master JS or do you want to turn ideas into reality? Its a touch tight rope to balance and it depends on what kind of engineer you are how you are employed (eg solo/contractor/full time).
Please dont do that mistake, dont go with hype, try vanilla js especially the es6 and beyond syntax find out why u need to switch to react, angular, etc. If u dive in now, nothing will make sense at all and you will be in a complete mess
James, thank you! Most of us all the time say that NextJS fits big projects and GatsbyJS is for small. Nobody says why. You pointed out a really important thing: "...content to grow a lot over time, then static generated web pages are not the best solution for you". Basically, it's a truth. A truth that lives now. GatsbyJS community claimed to improve this long time ago and looks like the core team did few steps forward (Read on my blog: webman.pro/blog/is-gatsbyjs-great-...).
What if GatsbyJS team will implement incremental builds support? Can they fight NextJS in context of big application? IMHO, depends, because NextJS
and dynamic SSR will still be more flexible. Let's say your GatsbyJS application based on some global configuration and any change will require rebuilding anyway. What if you had 1 million pages? You would still have to rebuilt all of them with GatsbyJS, right? In case of NextJS you have to invalidate cache only (if you have such). For sure, cost of NextJS infrastructure is a bit higher, but we are not talking about money here :D.
I first came across gatsby and tryied to convert a wordpress site by its API the question is that it have more than 9000 articles (its not the vegeta's joke) it has not even builded. Them I found next.js and it solved the problem, now I'm build a institucional site with a little blog posts system and gatsby are doing the job perfectly
very nice article :D
How long is the build and deploy processing time? Have you try or compare it with Hugo?
Would you recommend Gatsby or Next for a blog with the expectation to scale to 300 or 400 posts over the next one to two years? I'm developing a new website now that already has around 130 and takes about 5 minutes to build on Gatsby.
My personal instinct would be to go with Next.
If you still want to pre-build larger websites, site generators like Hugo and Nift still have surprisingly good build times on websites with thousands of pages or just lots of content. You can use React with at least Nift as well.
I have working on Next.JS project and I hate it.
Annoying routing. Annoying deploying.
And I really don't understand what is the difference between dynamic and static on this context.
You said, "If you have lots of content or if you expect your content to grow a lot over time, then static generated web pages are not the best solution for you."
It means that Next JS generate static web page when 5 school page when data from API just have 5 school data, and when data from API increased to 100 school Next JS generate static web for 100 school?
Plus, annoying deploying.
I have VPS with apache (only. my nginx is crashed) and it's SUPER difficult to deploy Next.JS project. So I am forced to 'static export' the project.
Tried out Gatsby recently, it's really awesome, hoping to go into next.js soon.
From the authors explanation that next.js involves generation of content from the server. In terms of performance making round trips to such server and getting our content would have to affect the speed of such application. I think that was why client side rendering (CSR) was introduced in the first instance.
Well unless we introduce some caching, but still our app would still be slower initially.
I guess we have some pros and cons.
Not necessarily. Rendering on the server-side has the benefit of less back and forth between the client and server as requests have to be made to bring content, so it could actually be potentially faster.
And as you mentioned, server-side rendering makes caching and working with CDNs a lot easier.
Next can now both of the things. I started using Next.js. Never looked back.
In Nextjs
export const getStaticProps = async () => { // getStaticProps for SSG, getServerSideProps for SSR
const data = await fetchData();
return {
props: data,
};
};
IN GATSBY
export const query = graphql
query {
site {
siteMetadata {
title
}
}
}
Rest of the codes are almost same.
Thanks, James. Good post! Just wanted to add for people who would like to know more, that Next.js allows a hybrid way to build your site, parts are static and parts are dynamic. Also a discussion about Static Generation (SSG) and Server-side Rendering (SSR) is here github.com/zeit/next.js/issues/9524
Hi, I am one day old in knowing Gatsby and 6 hours new to Next.js. Thanks for your great article. I would like to reconfirm a few questions after reading your article:
1) When you say Gatsby being less suitable for sites with thousands of pages, I suppose you mean page type right? Thousand of blog posts with contents feeding from other CMS such as WordPress and Strapi do not count as thousands of pages right but just one or two pages (listing + post details). So that's why Gatsby can be used for some kind of blog site.
2) If I want to build an industry specialised twitter like site with user able to submit their tweets, Gatsby can be up to the task right? This is a fun project just to give myself a goal to guild my learning. I don't mean to push to production.
3) I am an outdated-programmer. So naturally if I can get away with less coding, it will be better. Based on this constraint, should I start with Gatsby or Next.js?
Thanks a million for anyone helping.
I can answer question 2. Gatsby is not suitable for this. It is a dynamic website in every way. Unless you use nift or hugo it is not even a possibility. You see in normal static site generator a user would update a file and wait a few minutes for the site to build. But in this site the user expects the tweet to be visible to everyone instantaneously. The reason I do not recommend gatsby is that a small site takes around 2 seconds to build on netlify. You could run a dev server in hugo and which updates when a change is made and since hugo can build in milliseconds you could do that as a mini project and the site will reload automatically. But if traffic increases you will need to lazy load everything since the html file is extremely large so use next. If you really wanna use gatsby follow this guide netlify.com/blog/2020/06/11/5-opti... and make sure there is not much activity.
Thanks. I was hoping for something simple for this rusty programmer to build something amazing but deep down I kind of know Gatsby is not the solution. Anyway, it's not Gatsby's fault but mine unrealistic requirements.
The 3 paradigms of static sites and why people use react apps.
However all of this problems can be solved using pure HTML/CSS/JS and no frameworks.
@jameesy The updated link seems broken...Could you plz check it out?
Updated!
I migrated my content to a new site and that particular link broke. Thanks for the heads up!
The pleasure is mine :D
Still broken, unfortunately. If you have a moment to update it to jame.es/posts/gatsby-vs-next-js-2021, I'm sure it will save cumulative hours of googling for those coming here.
Thanks!
Thank you for a succinct, time-saving introduction to gatsby vs next.js difference.
Wonder if you can write about when to use a traditional CMS vs a headless one. All I see is posts touting the benefits of headless CMS. However, I think there must be cases where it makes more sense strategically to use traditional CMS.
Thanks for the article James! I find the gifs really distracting as I read, am I the only one?
I like your memes.
Why thank you, kind sir.
Hi James,
I am building a small react application but with two html entry points,1) login.html 2) signup.html and both pages will share many common components.
SEO : Nice to have
API : All api request will be done from browser only
SSR : Nice to have
Performance : Business critical
Considering that which option will be best for me?
1) CRA : I have worked on this but as I know it will require a lot of customisation e.g. ejecting CRA, customise webpack config for multiple entries etc.
2) Next.JS and Gatsby : I have not worked before.
Looking forward to know your thoughts. Thank you.
What do you recommend for medium e-commerce (300-500 products) site Gatsby or NextJS in 2020?
I'm thinking of building a personal site with Gatsby and this post was very helpful, thanks!
You're very welcome.
I would recommend checking out out this free video on Youtube which runs through the whole process of building a blog with Gatsby and hooking it up to a CMS
youtube.com/watch?v=8t0vNu2fCCM&t=...
Well technically you can also use HTTP request (with axios) in GatsbyJS at run-time. GraphQL is resolved at build time however : explained here gatsbyjs.org/docs/client-data-fetc...
Thanks for the article, the first one I read on those two technos, no need to read another one, I just have to go read both documentation now, knowing I already understand their differences
Great article!
I actually dont get how to pull the date at build time using Next js, for Gatsby its more obvious because its complexity is hidden over graphql from Gatsby
Thanks for sharing this! I'm currently developing 3 sites with Gatsby/Gridsome, this is perfect to use. The developer experience is nice, documentation and community growing.
Not a problem at all :)
excellent, thank you decision made :-) Nextjs it is for me.
Nice and concise. Thanks for the contribution!
Thanks for this contribution!
Thanks Jamees for this great comparison between NextJS and Gatsby framework, you laid out the core difference when to use these frameworks.
That's really the great article on this topic I have come across so far.
Great work man!
Thanks, James. Great post!
Hi Jamees Thanks for a valuable post. I'm curious what CMS platforms you use with Gatsby? My team have experience with a few, all with limitations(features or cost), and there's lots to choose from!
Gatsby does not force GraphQL you can do a normal fetch promise to pull in data — it is however preferred and reported to be faster.
Gatsby is rolling out incremental builds now to address the build time at scale.
But we can use graphql also for a next application.So, what difference it makes with respect to data handling?I'm just curious to know :)
Huge fan of this post, thank you for writing it! As someone new to Gatsby and Next.js it’s a great look into what both could offer me and when I should use one over the other.
Oh look, it's countryside coder <3
Though I'm a stronger user of Gatsby, Next is closing the graph and becoming a default rich toolkit to get people started.
Great comparison, thanks!
NextJS supports both server side rendering and static site generation and can also be used in hybrid mode.
nextjs.org/docs/basic-features/dat...
Great article I was honestly looking for the answer to this and you explained it well!
If you were to use AWS (amplify) to host your website. Considering that outgress costs you money (requests) , but not ingress (build), which one would be the best option? Next or Gatsby?
The link [jame.es/gatsby-vs-next-js-2021] seems to be now moved to:
jame.es/posts/gatsby-vs-next-js-2021
@jameesy
For anyone stumbling upon this on or after 2022-03-02:
The most up-to-date link I could find on his website is:
jame.es/posts/gatsby-vs-next-js-2021