Gridsome – A Vue.js static site generator(gridsome.org)
gridsome.org
Gridsome – A Vue.js static site generator
https://gridsome.org/
18 comments
I would recommend pre-building html markup as much as possible for performance boost and hydrate on the client for dynamic content, instead of going the SSR route. Obviously this may not be applicable for all use cases though.
Shameless plug: I just wrote a guide to approach dynamic content on static sites a few days ago.
https://blog.hasura.io/approaches-to-add-dynamic-content-sta...
Shameless plug: I just wrote a guide to approach dynamic content on static sites a few days ago.
https://blog.hasura.io/approaches-to-add-dynamic-content-sta...
Can you elaborate on your recommendation not to go SSR? Seems there are pretty well understood pros and cons to full SSR vs. static prerendered pages. The "right" choice depends on your app.
Also a big fan of Nuxt. The way it takes care of potentially tricky tasks like SSR and code splitting is a joy. The only thing I've had difficulties with is getting the Lighthouse speed rating above 50.
maybe your testing on your dev environment, because I just scored a solid 98 using nuxt.
I've recently developed a website using nuxt and got 100 lightspeed for both mobile and desktop (as long as I'm not using any kind of throttling as that will penalize the performance category).
Admittedly it was more of a personal goal but it's definitely possible and I'm pretty sure nuxt isn't the reason for you not getting it over 50.
Ironically, the only pages where I can't get a 100 score is when I'm using google maps due to a "Does not use passive listeners to improve scrolling performance" rule.
Admittedly it was more of a personal goal but it's definitely possible and I'm pretty sure nuxt isn't the reason for you not getting it over 50.
Ironically, the only pages where I can't get a 100 score is when I'm using google maps due to a "Does not use passive listeners to improve scrolling performance" rule.
I found Nuxt absolutely terrible to work with when I tried it about 1.5 years ago. Bad documentation, confusing terms and architecture. I ditched it.
Has it become any better? I'm pretty comfortable with Vue.js.
Has it become any better? I'm pretty comfortable with Vue.js.
Probably not. A few weeks ago, I went from zero to building something with it.
The documentation is certainly not as good as Vue. Which is a shame. I wish someone from their team talked to the documentation master over at Vue and made their documentation as good.
The only other criticism that I have, is that with Vue there are a lot of people over at discord. So if you can get stuck, you'll get some help. For Nuxt, you'll just get flat out ignored. Especially if you are developing on a Node JS framework no one is using.
I really wish there was more competition in this space. Happy Gridsome is stepping up and hopefully will be better in aspects compared to Nuxt.
That said, in a few weeks. Will build something with Gridsome and then I can have a better opinion.
The documentation is certainly not as good as Vue. Which is a shame. I wish someone from their team talked to the documentation master over at Vue and made their documentation as good.
The only other criticism that I have, is that with Vue there are a lot of people over at discord. So if you can get stuck, you'll get some help. For Nuxt, you'll just get flat out ignored. Especially if you are developing on a Node JS framework no one is using.
I really wish there was more competition in this space. Happy Gridsome is stepping up and hopefully will be better in aspects compared to Nuxt.
That said, in a few weeks. Will build something with Gridsome and then I can have a better opinion.
Vue's documentation is a work of art, backed by a clear philosophy about the underlying software. If a consultation with them was all it took to produce docs that compelling, they probably should go into the consulting business so we can all have perfect docs.
Laravel's documentation is also great to read. It's well done, concise enough and presented in a pleasant manner.
I haven't used Nuxt but I just recently read some complaints about it basically eating errors and making debugging a nightmare.
Ran into that. I don't day-to-day manage or work on those projects but I've been involved in troubleshooting build issues. Certain key functionality/plugins could "fail" with an error to the console but the build will continue and exit with success.
You find out about the problem when pieces or the entire site are not working.
You find out about the problem when pieces or the entire site are not working.
Vue CLI + DIY
The CLI is actually pretty powerful and has some great configs out of the box that people think they need Nuxt for.
The CLI is actually pretty powerful and has some great configs out of the box that people think they need Nuxt for.
My stack of choice is Nuxt + Pug templating + Sass.
It makes my life a lot easier.
It makes my life a lot easier.
Vue+Pug is a nice combo. If you're going with custom template syntax, may as well go all the way.
If you're looking for a Static Site Generator: consider building your own.
You can build your own static site generator in an afternoon. It's super simple to do and you avoid all the complexity of these off-the-shelf static site frameworks.
A few examples of my own:
You can build your own static site generator in an afternoon. It's super simple to do and you avoid all the complexity of these off-the-shelf static site frameworks.
A few examples of my own:
* A blog made with makefile, m4, multimarkdown, and scss
* A personal website made with shell scripts and php
* A business website made with ruby, rake and erbI agree with this. Honestly, it's super simple assuming you want to convert Markdown files to HTML.
You can also leverage 3rd party libraries to do the heavy lifting of:
1) Reading local file tree (the IO/FS module of your $LANGUAGE standard lib will suffice)
2) Parsing front matter (parsing the YAML block of meta at the top of the Markdown file)
3) Transforming Markdown to HTML (plenty of good libraries)
4) Using HTML templates (also plenty to choose from)
I don't think it's appropriate to link to my site here but if you're interested, I wrote a blog post on how to build your own static site generator. Link is in the bio.
You can also leverage 3rd party libraries to do the heavy lifting of:
1) Reading local file tree (the IO/FS module of your $LANGUAGE standard lib will suffice)
2) Parsing front matter (parsing the YAML block of meta at the top of the Markdown file)
3) Transforming Markdown to HTML (plenty of good libraries)
4) Using HTML templates (also plenty to choose from)
I don't think it's appropriate to link to my site here but if you're interested, I wrote a blog post on how to build your own static site generator. Link is in the bio.
I have gone that route in the past, only to find myself in lost amidst config files, documentation, and never ending ideas for more features.
Not that that’s impossible, but I lacked the restraint to turn away and do what actually matters: write content.
Not that that’s impossible, but I lacked the restraint to turn away and do what actually matters: write content.
Or for something in-between try Nanoc. It's a static site generator but much less prescriptive and more flexible than tools like Jekyll and Hugo.
Seconded. Following React's paradigm of "markup is a function of data", I recently built a new personal site generator where I just swapped JSX for JS template literals. Pages are a set of those functions composed together. Markdown is handled by a library, which (you guessed it) also just generates HTML strings. Works like a charm, incredibly easy to build and use.
Plus, because my rendering is all just pure JS functions, it'd be a flip of a switch to go from static site generator to an Express server that renders pages at request time.
Plus, because my rendering is all just pure JS functions, it'd be a flip of a switch to go from static site generator to an Express server that renders pages at request time.
A few years ago, I build my own static site generator in a 200 LOC Makefile [0]
I am still using it and built several sites with it, including image galleries for several weddings.
[0] https://github.com/patrickbr/hagel
I am still using it and built several sites with it, including image galleries for several weddings.
[0] https://github.com/patrickbr/hagel
Coming soon a static site generator generator framework.
I would recommend to use Parcel. Once you are done with HTML, SCSS, it's one line to build it:
parcel build *.html --public-url https://yourdomain
I migrated my site from WordPress to Jekyll a few years back and I fought a lot with Jekyll and had to write a lot of custom ruby plugins to get everything I wanted.
In retrospect, I really should have just written my own.
In retrospect, I really should have just written my own.
The advantage of doing this is that it gives you the power of using your favourite language to build this and its a fun project as long as its just dealing with markdown.
If you are building static sites with content sourced from a database or APIs then these static site generators removes friction involved in setting those up.
Can you point me to any resources for this? I'm somewhat of a beginner. I tried using Gatsby+ReactJS but realized I didn't understand React that well, and my GraphQL stuff didn't work. Thanks. matthewnewton (dot) info was the site.
Totally agree. I built my own last year. I don't use it anymore (decided to move to vanilla JS rendering for performance, and to remove the need for a build step), but the process was very instructive.
I really liked Metalsmith, mostly because it was fairly agnostic. It's a simple pipeline with pluggable components.
Love Sinatra for this
These kinds of static site generators are really nice because they enable better support for smarter interactive components in articles. Things like graphs or interactive demos to showcase something (e.g. user input delay on an article about ui design and responsiveness).
Vue is a particularly good choice for these kinds of applications because it's a lot more incremental and comes builtin with things like reactivity so there's no need for an external dependency for state management.
Like a complete app is:
---
import Vue from "vue/dist/esm.js";
app = new Vue({el: "#app", template:"<div>{{name}}</div", data: ()=>{{name: "john"}};
---
No jsx, no babel transpiler nonsense, no redux/mobx,
It's also possible to completely forget about vue and do something like
---
let data = app.$data;
data.name = "adam";
---
This is so nice because you don't even have to think about the fact that you're using a framework, it's all taken care of for you. No setState(...) nonsense. The tradeoff is that there's magic (which I don't think is bad because in vue's case it's pretty straightforward once you get to learn it) but that's a separate discussion because I don't think that magic matters for very small simple cases like this.
Vue is a particularly good choice for these kinds of applications because it's a lot more incremental and comes builtin with things like reactivity so there's no need for an external dependency for state management.
Like a complete app is:
---
import Vue from "vue/dist/esm.js";
app = new Vue({el: "#app", template:"<div>{{name}}</div", data: ()=>{{name: "john"}};
---
No jsx, no babel transpiler nonsense, no redux/mobx,
It's also possible to completely forget about vue and do something like
---
let data = app.$data;
data.name = "adam";
---
This is so nice because you don't even have to think about the fact that you're using a framework, it's all taken care of for you. No setState(...) nonsense. The tradeoff is that there's magic (which I don't think is bad because in vue's case it's pretty straightforward once you get to learn it) but that's a separate discussion because I don't think that magic matters for very small simple cases like this.
MDX[1] enables you to embed working JSX (eg React components) directly in your Markdown files. It doesn't need to be a separate file; you can just write the code in to the content file and it'll render an interactive component. One quite useful aspect of this is that you can have example code and a working example next to each other driven by the same content.
I'm not sure that's actually a good thing, but it does exist.
[1] https://github.com/mdx-js/mdx
I'm not sure that's actually a good thing, but it does exist.
[1] https://github.com/mdx-js/mdx
You can also write react without jsx or using any transpilers if you want, and for small apps there's no need for redux, there's great state management with functional components and hooks. I am not familiar with Vue but I like the setState or the useState hook with the delegate because it makes it clear that data access and change propagation aren't synchronous.
Does Vue use Proxy objects for the reactive state magic? I implemented something similar and that's what I ended up using.
We are using Vuepress for our blog, docs and tutorials. It's really fast and supports markdown.
https://vuepress.vuejs.org/
If you don't need SSR, then Gridsome is a better choice. Girdsome generates complete HTML content (better for SEO) whereas Nuxt generates only a minimal HTML page that always needs to be hydrated first.
In a recent project, I needed a blog where each article would contain a button to tweet it. The problem with nuxt was that all generated HTML pages contained just the globally defined meta tags. A workaround was to hook to the build process of `nuxt generate`.
In a recent project, I needed a blog where each article would contain a button to tweet it. The problem with nuxt was that all generated HTML pages contained just the globally defined meta tags. A workaround was to hook to the build process of `nuxt generate`.
I am using Gridsome in combination with CraftCMS (and CraftQL) for a client project. The moment you understand how to write a content-plugin based on your own needs, everything falls into place and makes it a pretty useful piece of tech. So if you like Vue and are a little jealous towards React-people about GatsbyJS – give it a shot!
I've tried to use Gridsome recently, after the .7 release I think, and it was just kind of painful. Managing the graphql layer just seemed over the top for my needs: static generation from markdown with dynamic vue components. I settled on zola[0] + webpack, but I'm still not super happy.
Sometimes the things I'm building I know aren't going to be very large, building a SPA with vue/vue-router and using react-snap[1] seems to be working well... almost seems like cheating.
[0]: https://www.getzola.org/
[1]: https://github.com/stereobooster/react-snap
Sometimes the things I'm building I know aren't going to be very large, building a SPA with vue/vue-router and using react-snap[1] seems to be working well... almost seems like cheating.
[0]: https://www.getzola.org/
[1]: https://github.com/stereobooster/react-snap
I peronally like Vue more than React so just hope Gridsome will gain more widespread use in the near future. Gatsby is great honestly.
I’ve built and launched nearly a dozen sites using Gridsome + Netlify since 0.5.0. It’s a fantastic tool and is a joy to use.
Have you managed to handle multilingual sites? I've browsed through Gridsome's documentation but couldn't find any info on that.
Dumb question, but why do you need a static site generator vs just writing an html file?
Say you write 10 blog articles. In HTML that's 10 files with some trivial cut & paste. In jekyll that's 10 markdown files and 1 HTML template. Equal time sink for both tasks.
Now you want to add Disqus comments to your blog. In HTML you edit 10 files. In jekyll that's probably 1 plugin. Same with adjusting theme, fonts, recent posts, generating RSS feed, recent Tweets, ads.
Now you want to add Disqus comments to your blog. In HTML you edit 10 files. In jekyll that's probably 1 plugin. Same with adjusting theme, fonts, recent posts, generating RSS feed, recent Tweets, ads.
Basically, template compiling. Not having to copy/paste reusable parts around, which is error prone and time consuming. Depending on the tool there's other stuff, like generating sitemaps, optimizing images, CSS treeshaking and other optimizations, all the good stuff that would otherwise happen manually or not at all.
Ah thanks for the explanation.
Because HTML doesn't have a way to import another piece of HTML.
Another option is to include the prerender-spa-plugin, which makes it trivial to turn a vue spa into static files that hydrate into a vue app on the client.
The parcel-plugin-prerender is great, https://www.npmjs.com/package/parcel-plugin-prerender.
The parcel-plugin-prerender is great, https://www.npmjs.com/package/parcel-plugin-prerender.
Any pros/cons vs Vuepress?
Awesome! What are the feature differences between this and gatsby?
The main difference seems to be that this is for Vue, while Gatsby uses React. Other than that, It actually looks exactly the same.
One more thing in gridsome, It has a lot of data sources support to make the site static.
Literally any source you can think of.
Literally any source you can think of.
Gatsby has this as well.
Airtable instead of AirTable.
> The future of the web is JavaScript
I disagree.
I disagree.
It’s my favourite development in web development in a long time.
https://nuxtjs.org/
I’m starting to feel like I want to use JS now for sites instead of just being forced to because of its power on the frontend. I hope the future is top heavy component based SSR with an API style backend which also runs off your web server.
With much simpler API requirements it’s easier to use languages like Rust and Haskell since the whole templating, view helpers, routing, layouts, asset management, and rendering stuff is all handled for you by the SSR app. Then you focus the backend on models, logic, authentication, and databases.