Nuxt is more than sufficient as a static site generator. It’s better to use SSR if you have dynamic pages with changing content, which requires a server. But Nuxt has the option to generate the pages statically (using Vue component templates to create static HTML pages).
It’s my favourite development in web development in a long time.
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.
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.
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.
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.
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.
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.
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.
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:
* 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 erb
I 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.
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.
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.
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.
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.
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.
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.
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`.
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.
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.
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.
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.
Why is that? I use react at work and vue on my own projects and I have always found vue to be all the good ideas from react with a lot of extra niceness and less tooling bloat.
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.