Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can Gridsome do anything that Nuxt can't do? #193

Closed
Maxhodges opened this issue Feb 14, 2019 · 25 comments

Comments

@Maxhodges
Copy link

@Maxhodges Maxhodges commented Feb 14, 2019

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

@hjvedvik

This comment has been minimized.

Copy link
Member

@hjvedvik hjvedvik commented Feb 14, 2019

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 :)

@physcocode

This comment has been minimized.

Copy link
Contributor

@physcocode physcocode commented Feb 14, 2019

this question is little ambigous

@renestalder

This comment has been minimized.

Copy link

@renestalder renestalder commented Feb 14, 2019

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

This comment has been minimized.

Copy link
Member

@hjvedvik hjvedvik commented Feb 14, 2019

  • 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

This comment has been minimized.

Copy link
Member

@tomtev tomtev commented Feb 15, 2019

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

This comment has been minimized.

Copy link
Author

@Maxhodges Maxhodges commented Feb 15, 2019

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

@Maxhodges Maxhodges changed the title Can gridsome do anything that NUXT can't do? Can Gridsome do anything that Nuxt can't do? Feb 15, 2019
@renestalder

This comment has been minimized.

Copy link

@renestalder renestalder commented Feb 15, 2019

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

This comment has been minimized.

Copy link
Member

@tomtev tomtev commented Feb 15, 2019

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

This comment has been minimized.

Copy link
Member

@hjvedvik hjvedvik commented Feb 15, 2019

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

This comment has been minimized.

Copy link

@renestalder renestalder commented Feb 15, 2019

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

This comment has been minimized.

Copy link

@brandonpittman brandonpittman commented Feb 15, 2019

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

This comment has been minimized.

Copy link

@renestalder renestalder commented Feb 15, 2019

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

This comment has been minimized.

Copy link

@tmorehouse tmorehouse commented Feb 18, 2019

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

This comment has been minimized.

Copy link
Member

@tomtev tomtev commented Feb 18, 2019

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

This comment has been minimized.

Copy link

@tmorehouse tmorehouse commented Feb 18, 2019

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

This comment has been minimized.

Copy link

@renestalder renestalder commented Feb 18, 2019

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

This comment has been minimized.

Copy link

@brandonpittman brandonpittman commented Feb 19, 2019

“Why did you stop developing Gridsome?”

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

@Maxhodges

This comment has been minimized.

Copy link
Author

@Maxhodges Maxhodges commented Feb 19, 2019

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

This comment has been minimized.

Copy link
Author

@Maxhodges Maxhodges commented Feb 19, 2019

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

This comment has been minimized.

Copy link
Member

@tomtev tomtev commented Feb 19, 2019

@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

This comment has been minimized.

Copy link
Member

@tomtev tomtev commented Feb 22, 2019

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

This comment has been minimized.

Copy link

@petar7777 petar7777 commented Mar 8, 2019

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.
capture
Looking forwards for your good reply.
Thanks.

@robaxelsen

This comment has been minimized.

Copy link
Member

@robaxelsen robaxelsen commented Mar 8, 2019

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

@petar7777

This comment has been minimized.

Copy link

@petar7777 petar7777 commented Mar 8, 2019

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

@sqram

This comment has been minimized.

Copy link

@sqram sqram commented Mar 14, 2019

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants
You can’t perform that action at this time.