Once you start learning web development, sooner or later you'll learn React and use
create-react-app to kickstart the building of your first React app. Or at least that's what CodeCademy taught me to do (in 2019). And I built my first React app, Line-height Picker, out of
However, I've noticed web developers often point out two limitations of
create-react-app: (1) it takes time for the landing page to be rendered; and (2) search engine crawlers may fail to index the app.
In addition, what keeps bugging me while I'm building an app from
All these limitations stem from the reliance of
Here's how CSR affects each of the three above-mentioned limitations of
With an app built with
create-react-app, it takes time for the landing page to appear on the user's browser.
The third limitation with
create-react-app will create the file called
/public/index.html which contains the following code inside the body element:
The message enclosed in the
A workaround is to insert an HTML version of your React app into the
noscript tags. But this approach is super tedious: whenever you revise the React code, you have to manually change the HTML code as well.
Let me cite a few of these comments. Matt wrote as recently as on 18 April, 2020:
Phillip Parr also wrote on 9 March, 2019:
"I regularly browse the web with JS disabled. Too many sites are using JS now 'just because', and overloading my connection / CPU time with frivolous multi-megabyte framework downloads. It's VERY easy to build a fast, efficient, valid, accessible site with no JS at all, and I absolutely implore everyone to do so. Quite a few sites are completely broken with JS disabled, despite being perceptually static when enabled."
But reading their own voices—rather than just the cold number of "0.2%"—makes me feel that we should not ignore them. The web content is for everybody. Access to information doesn't require personal connections with knowledgeable people. That's the beauty of the web.
Now that we understand the limitations of create-react-app - or client-side rendering (CSR) in general - the question is: how can we do better to build a React app?
The answer is pre-rendering, which may involve static generation, server-side rendering (often abbreviated as SSR), or both.
These jargons are often used without clear explanation in web dev articles. I myself was confused a lot, until I read a crystal-clear description by Vercel (2020), the official tutorial of Next.js (more on Next.js below).
Here is my own understanding of what pre-rendering is and how it solves the limitations of client-side rendering (CSR) while preserving the merits of React.
These two merits come at a cost of the three limitations of create-react-app described above.
One form of pre-rendering is static generation, the most popular tool for which has been Gatsby, a static generation framework for React-based web development. I kept hearing its name for powering "blazing fast" websites, without knowing what Gatsby was special about. Now I know why.
This is a great solution for websites such as blogs which do not involve interactive features other than hypertext links. You can use React to compose HTML documents without sacrificing the speed of rendering the landing page.
Aside from Gatsby, static generation can be implemented with Next.js since its version 9.3, released on March 10, 2020 (Neutkens et al. 2020a). Below we compare these two options for static generation in the final section of this article.
If you have already created a React app with
create-react-app, refactoring the code for Gatsby or Next.js is a big headache. In this case, consider Navi, which allows you to convert the code based on
create-react-app into a statically generated one.
Another form of pre-rendering is sever-side rendering (SSR), which deals with a drawback of static generation at the cost of a slower rendering speed.
Static generation cannot work with live data such as social media feed, because HTML documents were already created before deployment.
As far as I can tell, Next.js has long been the React framework for SSR, and it still is.
For static generation, you need to decide which framework to go with, Gatsby or Next.js. Here are some pieces of information to help you make a choice.
There are a countless number of articles that compare these two React frameworks. But I advise you to ignore all of those written before March 10, 2020, because Next.js was incapable of static generation until then (Neutkens et al. 2020a).
In an article written one month after the release of Next.js 9.3, sidney (2020) claims "Gatsby Won Against Next.js" after he himself built the same website with both frameworks. LightHouse performance scores are slightly higher for Gatsby (78 vs 74). He also mentions that documentation is better with Gatsby.
But this is the only article that I've found is in favor of Gatsby.
Gatsby's own website provides the comparison chart between the two (Gatsby 2020). Unsurprisingly, it claims that Gatsby provides more features than Next.js, although it is unclear which version of Next.js they refer to. As Next.js keeps updating itself, most recently on Oct. 27th, 2020 (Neutkens et al. 2020b), this comparison chart may be outdated by now.
Laing (2020), written one month later after Next.js becomes a static generation tool, argues that Next.js is a better option because of its SSR capability. Maybe you start out building a static website. But then when you realize you need SSR, Next.js just allows you to implement it while Gatsby does not. For each feature that he mentions Gatsby is better at, there is a comment to this article saying Next.js, too, has that feature.
In the Twitter sphere, Next.js appears to get more popular.
A Twitter poll by Buaiscia (2020) on July 6, 2020, shows that 7 out of 13 voted for Next.js as a blogging platform while 5 voted for Gatsby.
McDaniel (2020), tweeting on August 4, 2020, is in favour of Next.js:
"Switching this new site to #nextjs from #Gatsby. The more I started getting everything together the more I realized next js was going to be a better choice. Love me some gatsby though."
The NPM weekly download data backs up this trend:
A screenshot of NPM trends on November, 30, 2020
The popularity of Next.js is on the rise from around 400,000 to 1,000,000 downloads per week while Gatsby's is stagnated around 400,000 per week.
Of course, the number of package downloads doesn't mean the number of people who actually keep using it. But it is an indication of reputation. People won't download it unless they hear something good about the package.
As of November 2020, Next.js appears to be more suitable for a static generation tool.
If you want to decide which to use on your own judgement, instead of relying on what people say, Smashing Magazine recently interviewed the person behind each React framework, for the audience who doesn't even know what static generation is. Listen to each's sales pitch, and decide which one you will go with.
- Smashing Podcast Episode 20 With Marcy Sutton: What Is Gatsby? - Smashing Magazine
- Smashing Podcast Episode 23 With Guillermo Rauch: What Is Next.js? - Smashing Magazine
This article is part of Web Dev Survey from Kyoto, a series of my blog posts on web development. It intends to simulate that the reader is invited to Kyoto, Japan, to attend a web dev conference. So the article ends with a photo of Kyoto in the current season, as if you were sightseeing after the conference was over.
Hope you have learned something today! Happy coding!
I use the Author-Date referencing system in this article, to refer to various articles on web development.
Buaiscia, Alex (2020) "A Tweet on July 6, 2020", Twitter.
Can I Use (2020) "Browser Usage Table" caniuse.com, 8 September, 2020.
Gatsby (2020) "Comparison of Gatsby vs Next.js", gatsbyjs.com.
Laing, Malcom (2020) "Which To Choose in 2020: NextJS or Gatsby?", Frontend Digest, Apr. 18, 2020.
Lawson, Nolan (2016) "Progressive enhancement isn't dead, but it smells funny", Read the Tea Leaves, Oct. 13, 2016.
McDaniel, Josh (2020) "A Tweet on August 4, 2020", Twitter.
MDN Contributors (2020) "<noscript>", MDN web docs, Apr. 12, 2020.
Miller, Jason, and Addy Osmani (2019) "Rendering on the Web", Web Fundamentals, Nov. 26, 2019.
Neutkens, Tim, Joe Haddad, JJ Kasper, Luis Alvarez, and Shu Uesugi (2020a) "Next.js 9.3", Next.js Blog, Mar. 10, 2020.
Neutkens, Tim, Joe Haddad, JJ Kasper, Connor Davis, Luis Alvarez, Shu Uesugi, Belén Curcio, and Steven (2020b) "Next.js 10", Next.js Blog, Oct. 27, 2020.
sidney (2020) "Gatsby Won Against Next.js in this Heads Up Competition", Hacker Noon, Apr. 27, 2020.
Vercel (2020) "Two Forms of Pre-rendering", Next.js Docs.