The Thing About Nuxt
Few people understood why Git was so special and I wasn't among them at the time. Ryan's article captured the essence of Git and convinced me to make the switch.
I've addressed the issue of Vue and React before. Poorly, if I might add. This Reddit thread offers a much better explanation. The same argument applies when comparing Nuxt and Next, which are based on Vue and React respectively.
In the few times I did React work, I had to spend days coming up with the perfect boilerplate and build scripts, which to me always looked inevitably bloated. I just noticed there would always be too much going on, even for the simplest application.
Remember Steve Yegge's Code's Worst Enemy piece from 2007?
"I happen to hold a hard-won minority opinion about code bases. In particular I believe, quite staunchly I might add, that the worst thing that can happen to a code base is size."
With React, I had a bloated code base starting with the boilerplate.
I tell everyone I'm a minimalist, but at the same time, I have noticed when other people tell me they're minimalists, I'm just as likely to think they're lazy and unattentive as they're concise and efficient.
I think both these kinds of minimalists exist, and it might just be to some extent, the prejudice against the former that makes React developers unimpressed by Vue's minimal API.
Or as Steve Yegge goes on to say:
I say "size" as a placeholder for a reasonably well-formed thought for which I seem to have no better word in my vocabulary. I'll have to talk around it until you can see what I mean, and perhaps provide me with a better word for it. [...] unfortunately most so-called experienced programmers do not know how to detect bloat, and they'll point at severely bloated code bases and claim they're skinny as a rail.
Nuxt is the best attempt I've seen in my entire programming career to deliver exactly that: a bloat-free codebase. I've never seen any codebase as skinny as they are with Nuxt. Not with any PHP framework. Not with Ruby on Rails. Not with any Python framework. Not with Go. Never. Nuxt's conventions were perfect for architecting every app I built with it. In an ecosystem that is known for its endless fragmentation and complexity, that's rather amazing.
A command worth a thousand configurations
npm install -g nuxt-edge (soon to be Nuxt 2),
will just work in any directory. It'll look for a
nuxt.config.js file, but
you don't need one just yet. Just add a Vue SFC to
pages/ and you have
a working route:
echo "<template><p>Hello</p></template>" > pages/index.vue
http://localhost:3000/in your browser.
Of course, as your app grows, you'll need dependencies, a proper
file and to run
npm install on your project's root directory. But the ability
to start with minimal effort like this is a luxury I'll never give up.
The right conventions
So what are these great conventions?
Nuxt borrows some code organization ideas from Next and is already blessed with Vue's own philosophies.
- Your views are Vue single file components that go into
pages/. You can't change the name of this directory. You can change the routes themselves, but you can't change where the files are kept. If you don't change the default behavior, the directory structure of
pages/is used to map the routes.
- In addition to
pages/, you may add
components/. These names are pretty much self explanatory. Assets are automatically loaded via Webpack when referenced in pages, static files are automatically served in
/, middleware functions run before route changes, layouts define structure for pages and components hold the Vue components (or even Vue SFCs that compile to native Web Components) that are optionally used by pages.
Painless deployment options
There's not much else to it. Well, there is.
But this is enough to build a lot of apps elegantly and hassle-free. Want to deploy on a Node server with SSR? You get that built-in. Want to use an existing Koa or Express server? Use the Nuxt.render() middleware. Want a client-side app? Use SPA mode.
My experience with Nuxpress
Check out these other articles to see more people wax lyrical about Nuxt. I'll wrap up with my experience writing Nuxpress, the static blogging software this website is built with. My thought process with Nuxpress went like this:
- I need to list markdown files available before the build.
nuxt.config.jsgets loaded before the build.
Adds code to
- I need to inject the data into my pages.
Adds code to
- I need to actually load the markdown entries.
Adds code to
- I need to display the markdown entries.
Adds code to
- I need custom routes.
Adds code to
The less I have to think about where and in what order code runs, the more productive I am. Nuxt's conventions have become so natural to me I rarely have to look up documentation for them.
This is why I'm now contributing to Nuxt and don't plan on replacing it as my core stack for building apps in the foreseeable future.