Can Gridsome do anything that Nuxt can't do?

[Maxhodges]

a developer tells me gridsome can't do anything that NUXT can't do regarding static site generation. Should I believe him?

[hjvedvik]

I don't think we can compare Nuxt and Gridsome based on what they can do. It's how you create a website that is the main differences between them :)

[ipranjal]

this question is little ambigous

[renestalder]

Okay let's elaborate on that because I'm also interested as I'm only used to Nuxt and have problems to find the answers to my questions.

• Can I animate between pages?
• When statically generated, on routing, is the framework able to load data async on client-side or will always the static file be loaded?
• Can I use Gridsome with TypeScript?

[hjvedvik]

• We are working on a solution for page transitions.
• Vue.js runs in the browser so you can load data from APIs.
• I haven't tried Gridsome with Typescript, but it should work with custom webpack config.

While Nuxt is a great framework and configurable to create anything you want, Gridsome is more focused on websites that contain mostly static content. We try to solve common problems for most use cases; Source plugins make it easy to use content from CMS'es (more plugins are coming). And a GraphQL data layer lets you easily access the data in any component. All routes are rendered automatically, including dynamic routes. Pagination for collections and taxonomy pages can be implemented with just a few variables in your query. Local images can be optimized automatically and lazy-loaded in the browser. All this can be achieved without writing any logical code.

You can use the Data Store API to insert data from custom APIs, but we are going to open up methods for more advanced usage before a 1.0 release.

When statically generated, the app only contains vue, vue-router and vue-meta with minimal custom code from gridsome to lazy-load images and preload data plus a few components. Vue.js hydrates the markup and turns into a SPA which allows you to do almost anything in the browser. All data is also rendered as static JSON and fetched before each route, so there is no connection with the CMS'es when generated. And only data you query for is rendered.

[tomtev]

Like what @hjvedvik said, Gridsome tries to simplify building modern, static websites for any data source. To compare Gridsome and Nuxt you also need to compare it to nuxt generate.

The biggest difference between is probably how you work with data.

In Nuxt you fetch directly from APIs per route. This can be from an external rest API or GraphQL API. It’s up to the developer on how to do this.

For example, to create a blog with pagination in Nuxt you’ll need to:

• Create a /pages/blog/index.vue file and fetch blog posts into this from any API.
• Manually create pagination functionality.
• Create a /pages/blog/_id and fetch from any API by using :id route param as a variable.

The biggest problem with Nuxt (Generate), in my opinion, is that it always fetches from the API on client-side after page load, even if it's static. I know they are working on fixing this, but this is how it is now. There could, of course, be some quick fixes for this.

In Gridsome you fetch all data at build time, or when starting development server, into an internal GraphQL data layer and THEN you start adding data to pages from this data layer with GraphQL queries. You don't need to deal with any API endpoints.

Data source plugins are designed to make it as easy as possible to add and work with data in Gridsome. For example, if you connect to a WordPress site you can get posts, categories & tags connections out-of-the-box.

To create a blog in Gridsome you’ll need to:

• Create a /pages/Blog.vue file and add a GraphQL query for the collection you want. This is super easy thanks to the GraphQL Playground where you can build and test queries.
• Use the built-in pagination for the GraphQL query, so archive pages like blog/1 blog/2 etc. works.
• Create a /templates/TheCollectionName.vue that will automatically be the template for the GraphQL collection.

Gridsome should also generate pages faster because of how it fetches data up front instead of per page.

[Maxhodges]

thanks everyone. this is very helpful. could be some useful content to distill into docs one day!

[renestalder]

Thanks for the details. Very helpful. I also see potential putting this comparison to the README. I still feel like these two can be compared, even generate in Nuxt is only a very very small part of its feature set. It comes with so many built in performance centered features that at least for me it needs quite something to get me hooked up to something else.

The biggest problem with Nuxt (Generate), in my opinion, is that it always fetches from the API on client-side after page load, even if it's static.

Maybe the Nuxtent Module I use in my case is intercepting this behavior, but at least it doesn't load again client-side on first load for me. Only on routing.

I guess we can say the biggest advantage of Gridsome really is the data connectors, as in Nuxt you have to do it manually or create something on your own, that works for static generation but doesn't put the whole data into your JavaScript chunks. And here it gets tricky, because that means you have to know quite something about Webpack to extend that part. Or you try to find an existing module for it but in my experience it's hard to find one that is enough extended and has frequent maintenance.

Somehow I would love to be able only using the data layer features of Gridsome, but use Nuxt for the rest. The advantage of Nuxt is that I can decide between SPA, server-side or static generation. That allows me to make a full web application that uses the best of all 3 methods in parallel e.g. shows static-generated pages for public pages but makes the switch to server-side rendering when e.g. user logs in and needs data that only belongs to the user. SPA is almost never an option for me.

Does Gridsome also work with server-side rendering of Vue.js?

Also something that turns me off a bit is that the documentation contains many empty pages. In my humble opinion, I would only put stuff in there that is already implemented and only release features when it's documented. Because that's one of the biggest strengths Vue.js and Nuxt.js come with: A very strong documentation. But I know that my concerns are probably not valid as long as it doesn't reach v1.0.0.

[tomtev]

Somehow I would love to be able only using the data layer features of Gridsome, but use Nuxt for the rest. The advantage of Nuxt is that I can decide between SPA, server-side or static generation.

We're a strong believer in JAMstack. That means generating as much as possible up front (at build time) and then add dynamic stuff by fetching data on the client side. So I think Gridsome can be used for most things if you go this route. For example, user data could just be fetched on the client side if the user was authenticated. This makes it possible to host your app on a CDN and you don't need a Node.js server.

Here is how Gatsby does it (React alternative) https://www.gatsbyjs.org/blog/2018-11-07-gatsby-for-apps/

Does Gridsome also work with server-side rendering of Vue.js?

Gridsome is server-side rendered at built time.

Also something that turns me off a bit is that the documentation contains many empty pages.

Thanks for the feedback! This is there so people could contribute if they want. If not we'll try to add them before 1.0 is released.

[hjvedvik]

Does Gridsome also work with server-side rendering of Vue.js?

As @tomtev wrote, all pages are server-side rendered by Vue.js at build time. But Gridsome also has a built-in gridsome serve command (will work again in v0.5) which will run the website on an Express server with server-side rendering. All data is fetched from the GraphQL endpoint before each route, so it's very fast to not be JAMstack. But I wouldn't recommend using it yet.

[renestalder]

Gridsome is server-side rendered at built time.

I don't think that is what server-side rendering means. In my understanding that's just static-generation. Server-side rendering is what @hjvedvik means with the dev server.

This makes it possible to host your app on a CDN and you don't need a Node.js server.

Yes, that's nice and that's what I do for many cases, but I'll never ever just use SPA for things like user areas. A server-side or static-generated fallback is always required in my cases to ensure client-side error fallbacks, usability and accessibility workarounds.

---

I think I now understood that this is completely targeted in direction of the JAMStack. Still, I think your work with the data adapters is awesome and if I would have the possibility to use them outside of Gridsome for all those cases where I can't leverage the JAMStack thus need server-side rendering too, that would be a dream. But I understand that this is miles out of scope.

[brandonpittman]

If we can’t agree that server-rendered at build time and static generation are the same thing, we need to just pack it all in and become sheep herders.

[renestalder]

If we can’t agree that server-rendered at build time and static generation are the same thing, we need to just pack it all it and become sheep herders.

So then let me correct and say I just never heard it in that context and find it misleading as I clearly talk about server-side rendering as a fallback for SPA in the example context of user logins.

[tmorehouse]

SSR and static rendering are related, but not the same.

Static rendering generates a page once and then serves that same page to everyone who requests it. The content of the page is considered static and cacheable.

SSR typically renders the page on every request to the server, and typically has a low cache ttl (or never cacheable).

[tomtev]

We talk about "Server-side rendering at build time" because that is exacly what's happening. The pages are rendered at the server, not the client. They are pre-rendered at build time instead of when a user is requesting it. This results in better speed and no need for caching etc.

[tmorehouse]

They are pre-rendered at build time instead of when a user is requesting it.

That is it... A better term would be pre-rendered at build time.

This results in better speed and no need for caching etc.

No need for caching? Caching helps definitely with static html sites, especially large ones (i.e. either local cached copies on the user's browser, or cached on an intermediate cache, such as CloudFlare etc).

[renestalder]

Jah wouldn't now start mixing in any caching topics. It's also good practice to cache HTML and actually when you use a CDN e.g. Netlify, that will pretty sure cache things on a cache proxy server (as it's actually the point of the CDN to be fast).

Pre-rendered is exactly the right term here. Anyway, I didn't want to open Pandora's box about a SSR discussion. I got my answers and will keep Gridsome on the radar for production when it hits 1.0.0.

Keep on going with the great work. Looking forward to that animation/page transition support.

[brandonpittman]

“Why did you stop developing Gridsome?”

“People kept arguing the semantics of ‘server-rendered’.”

[Maxhodges]

a pretty good recent article on the topic

Static rendering happens at build-time and offers a fast First Paint, First Contentful Paint and Time To Interactive - assuming the amount of client-side JS is limited. Unlike Server Rendering, it also manages to achieve a consistently fast Time To First Byte, since the HTML for a page doesn’t have to be generated on the fly.

static rendered pages are interactive without the need to execute much client-side JS, whereas prerendering improves the First Paint or First Contentful Paint of a Single Page Application that must be booted on the client in order for pages to be truly interactive.

https://developers.google.com/web/updates/2019/02/rendering-on-the-web

[Maxhodges]

If you have a large blog, will Gridsome prefetch hundreds of pages of content? Isn't that pretty heavy, especially for mobile users?

We are building a new blog with Nuxt pulled data from Airtable. Right now it's just a prototype, and I'm interested in switching to Gridsome because I've done several sites in the past with Gatsby and have a high opinion of it. But 1) Gridsome development seems to be going pretty slow, so it looks like we might not see v1 in the near future, and 2) we may have hundreds or thousands of posts over time, so I'm not sure if the prefetching will be a problem will actually hurt Google's site performance ratings. With VuePress we found we actually scored higher on performance if we disabled prefetching.

Finally, if there a way to build an "infinite scroll" experience Gridsome? For our main page, we'd like to have a chronological list of all our articles, newest first. With a SPA model I'd just load the first 10 and them implement a scroll trigger to pull more content from the API. With a static site, should I just pretty much just load all the content in one huge page, or is there a more sophisticated strategy?

@hjvedvik @tomtev
Finally, how can we support your efforts on Gridsome? is there something like Paetron in Norway?

Cheers!

[tomtev]

@brandonpittman
Sorry about that :) Was just trying to explain what happens under the hood. Because it helps us understand how to deal with SSR plugins because it is the same for normal SSR and at build time.

I know Gatsby is using "Server-side rendering at build time" in their presentations.

@Maxhodges

If you have a large blog, will Gridsome prefetch hundreds of pages of content? Isn't that pretty heavy, especially for mobile users?

It only prefetches links that are in view. So it's perfect for mobile users.

Gridsome development seems to be going pretty slow, so it looks like we might not see v1 in the near future

We will release 0.5 today. It is a huge version with many important features and changes under the hood. We're actually not that far from 1.0 :)

Finally, if there a way to build an "infinite scroll" experience Gridsome? For our main page, we'd like to have a chronological list of all our articles, newest first.

We will have a built-in feature for this in the future. Just like our Pagination support. For now you need to load all posts with GraphQL and just manually split the post array.

Finally, how can we support your efforts on Gridsome? is there something like Paetron in Norway?

We might start a Patreon or Open Collective very soon.

[tomtev]

We'll close this now :)

Here is a great podcast about Next VS Gatsby:
https://syntax.fm/show/120/gatsby-vs-next

Next is the react alternative for Nuxt
Gatsby is the react alternative for Gridsome

Nuxt do some stuff better and simpler than Next tho :)

[petar7777]

Hello. @hjvedvik
I noticed you are expert in Gridsome area.
Now I am developing Gridsome project.
It worked well for a while.
But for now I am getting the following error.
Please help me.

Looking forwards for your good reply.
Thanks.

[robaxelsen]

Hi @petar7777. That issues has already been reported here, with suggestions for fixes: #252

[petar7777]

Hi @robaxelsen
Thanks for your quickly reply.
OK. I will follow it.
Thanks.
👍

[sqram]

@tomtev

Gridsome should also generate pages faster because of how it fetches data up front instead of per page.

Indeed that's how it's typically done, Nuxt does allow to fetch all your data at once before compile time, and pass the data to the pages.

ie, you could fetch all users from an api in the config's generate() function, and pass that data to pages via a payload, and use it in the async() method and pre-render that data

Both frameworks are great though.

[peachp]

@Maxhodges we also use Airtable as our backend, though for much more than just Blog posts. We organize weddings all over Europe, so we have 100s of venues and "projects" (past weddings) we showcase on our website, plus all you typical pages like /contact, /faq etc., as well as blog posts.

I plan to use something like Nuxt or Gridsome to pre-render 99% of the content, of which the bulk will come from Airtable records (+Cloudinary for images ...we have 1000s of them) and a few really static ones (homepage, /contact etc.) from YAML files, which my content guys will edit directly on GitHub first and later with something like Forestry (if needed). Later we might add few SPAs for things like "MyWedding" page where our clients will manage / track progress of their wedding being planned etc.

Gridsome makes really good impression and I like the idea of "source plugins" (though the Airtable plugin is no good for us, because it only gets data from single Airtable table), though after doing huge corporate ERP projects for 10 years, I always also keep other things in mind such as maturity, stability, docu, availability of freelance talent, paid support from the creators with SLA, potential longevity etc., so as of now I'm also debating Gridsome vs. Nuxt.

Having said that, it will be another 2-6 months until we actually will start implementing this project, so I'll keep an eye on Gridsome until then!

Are you on Discord?
Let's stay in touch to exchange ideas etc.

@tomtev

The biggest problem with Nuxt (Generate), in my opinion, is that it always fetches from the API on client-side after page load, even if it's static.

...and...

In Gridsome you fetch all data at build time

I'm not 100% sure, isn't this how you do it in Nuxt?
https://nuxtjs.org/api/configuration-generate/#routes
(see Function which returns a Promise)

So in other words:
Gridsome:

// gridsome.server.js
const axios = require('axios')

module.exports = function (api) {
  api.loadSource(async actions => {
    const collection = actions.addCollection('Post')

    const { data } = await axios.get('https://api.example.com/posts')

    for (const item of data) {
      collection.addNode({
        id: item.id,
        title: item.title,
        content: item.content
      })
    }
  })
}

...equals Nuxt:

nuxt.config.js

import axios from 'axios'

export default {
  generate: {
    routes () {
      return axios.get('https://my-api/users')
        .then((res) => {
          return res.data.map((user) => {
            return '/users/' + user.id
          })
        })
    }
  }
}

?

Note I am noob in the whole headless, JAMstack, SPA, ...and even JS world, so I might be totally confusing things here, only judging from reading the docus.

[renestalder]

@peachp Nuxt isn't fully static and in my understanding, follows the way how Gatsby (correct me if I'm wrong) does it: Generate static pages for first load, but allow client-side async loading for navigation (as soon as you navigate after first load).

Nuxt allows you to do stuff like page transitions or transitions for loading and including async data. But it also requires more traffic from your API as, in addition to the build that makes API requests on every change, every user also makes API requests on the running application. This can especially be a drawback if you use something like Dato CMS or Contentful, when you have API request limits.

Gridsome is fully static and thus doesn't come with the overhead of client-side async requests. This can especially be useful if you want to hide the API you are using and want to save requests. Most of the static-site generators work the way Gridsome works.

A fully static generated mode for Nuxt is also in the works.

[peachp]

@peachp Nuxt isn't fully static and in my understanding, follows the way how Gatsby (correct me if I'm wrong) does it: Generate static pages for first load, but allow client-side async loading for navigation (as soon as you navigate after first load).

Nuxt allows you to do stuff like page transitions or transitions for loading and including async data. But it also requires more traffic from your API as, in addition to the build that makes API requests on every change, every user also makes API requests on the running application. This can especially be a drawback if you use something like Dato CMS or Contentful, when you have API request limits.

Gridsome is fully static and thus doesn't come with the overhead of client-side async requests. This can especially be useful if you want to hide the API you are using and want to save requests. Most of the static-site generators work the way Gridsome works.

A fully static generated mode for Nuxt is also in the works.

@renestalder
Hm... interesting. I'm quite new to the whole headless / static and even JS world, so it is not always clear that there are all these flavors of static / pre-rendered / SSR / headless and so on.

The way you describe it, it sounds like this Nuxt's generate: routes ... config is really just to generate the routes for navigation, but the data is fetched at run-time for each request (unless cached) from your API of choice?

However, when I read further, it says something about payload and generate.interval, which indicates that some data (payload) is indeed pre-fetched / pre-rendered at generate / build time, and not jsut at run-time?

Speeding up dynamic route generation with payload
In the example above, we're using the user.id from the server to generate the routes but tossing out the rest of the data. Typically, we need to fetch it again from inside the /users/_id.vue. While we can do that, we'll probably need to set the generate.interval to something like 100 in order not to flood the server with calls. Because this will increase the run time of the generate script, it would be preferable to pass along the entire user object to the context in _id.vue. We do that by modifying the code above to this: ...

Not sure if I interpret it correctly.
In any case, for our business, we would indeed need to fetch / render as much of the data and HTML etc. as possible, because our website is 95% static (content changes every few weeks) and we'll only have 2-3 SPAs.

[Maxhodges]

I'm the OP, but after our team built sites with Nuxt, Gridsome, VuePress, we prefer both Gridsome and VuePress over Nuxt. I'll see if our CTO @frandiox would like to chime in
we used gridsome for this site: https://blackship.com
and vuepress with i18n here: https://whiterabbitexpress.com

We prefer Gridsome once it has i18n

[shouvikfullstack]

Thank everyone, quite helpful content, easy to get a big picture for someone who wants to choose either of one for their application. :)

[Maxhodges]

@tomtev

We might start a Patreon or Open Collective very soon.

It seems Gridsome dev has really slowed. Is funding an issue? Did you setup a Patreon?

[tomtev]

@Maxhodges Money is not a problem. It's the time. We're still working a lot on Gridsome and planning how 1.0 will be. There is also a lot of work and planning happening outside of the repository. Like for example how to make sure v1.0 will be 100% ready for Vue 3.0.

i18n works different for every data source, so it's hard to make an official solution. It's best to solve i18n by just creating a new data source and setup different routes per language. I think this is how Gatsby is solving it. There is no official solution for Gatsby I think?

[Maxhodges]

thanks, I tried reaching out to you guys off-repo...

is there anything I can do to help accelerate development? Maybe start an official Paetron for Gridsome and use it to incentivize other contributors (if money isn't an issue for you two core devs)?

[flexchar]

It is very sad to see that the only Vue alternative for GatsbyJS is having such a slow progress. Not to be rude or so, in fact I am very happy to see what product it is evolving into however I believe it also misses out a lot on potential users due its lack of development. VueJS 3.0 is a big thing and I waiting for it as well. Especially for native TypeScript support but it shouldn't be a major slowdown as it will not introduce any major breaking changes. :)

By writing, I simply express my concern and interest in Gridsome. And of course, I would happy to become Patreon if that would help!