Building a Vue.js SPA to Sell Developer Tees
Stereotypes can be a funny thing.
Some are nice like Swedes are gorgeous; some are mean like Americans are fat and Italians are “passionate;” and some seem downright true like all Canadians are polite.
But if you travel enough, you know these are typically gross over-generalizations and, usually, are more divisive than anything else.
And that’s why I love coding so much. It’s way more open-minded. When I meet someone writing in PHP, they’re more than happy to listen about my Vue.js SPA project, for example. And I’m more than happy to listen to what they’re working on, so long as it isn’t a WordPress site (just kidding).
But, hopefully, you get my point. It’s this international inclusiveness among developers that inspired a friend and me to start Maison Futari.
In this post, I am going to:
Tell you what inspired Maison Futari
Discuss why I chose Vue.js to create it
Give a step-by-step Vue.js SPA tutorial
Share my experiences (good and bad) with using Snipcart as my shopping cart
Let's get started!
Inspiration for my Vue.js SPA project
First, a little bit of history. I’ve been big into coding since I was 16 years old which means my programming anniversary just hit double digits (oh, how time flies). My love of coding dances between passion and obsession, depending on my mood. So sometimes, when I see someone playing with a few lines of code, I love to dive into meaningful conversations with them.
Again, that’s just the charm and power of programming: it connects people.
Fast forward to Maison Futari, my online T-shirt store that lets people know your passion for programming matches their own. You can read the full story on our site which describes how and why we created Maison Futari (plus how we came up with French/Japanese name!).
Choosing Maison Futari’s Tech Stack
Ok, so we had the shirt design. The next step was obviously getting the product online which begged the question: how do I want to build this site?
In the past, I’ve worked as a backend developer, but not too long ago I shifted gears. I’m all frontend now! And I needed something that would allow me to stay on the frontend while keeping my site both sleek and interactive.
So I looked over my options. First up was using JAMstack, though I had some initial hesitations.
JAMstack is great but comes with its pros and cons like any new model or technology. Overall, I think that JAMstack is definitely going to be the future of simple websites with minimal content, if it isn’t already.
But that doesn’t mean there aren’t disadvantages to this holy grail. The biggest flaw for me is the fact that the compiling data gets slower and slower after a certain amount of content. I know Gatsby is planning on fixing this problem, but they just aren’t there yet. Also, I’m aware that there are some exceptions like MailChimp and Redbull. But globally speaking, if you have a site with millions of pages, JAMstack just isn’t as viable—yet.
But there was definitely option #2: going all retro-JAMstack by using a SPA.
What is a SPA?
A single-page application (SPA) is a dynamic web page which enhances UX by rewriting your current page rather than going to the server to reload new pages. In other words, SPAs allow you to stick to the frontend because the application runs entirely through your browser. The benefit is that there’s less back and forth between the front and backend.
Less back and forth = faster page loads = better UX
Even if you don’t know it, you’re probably already familiar with single-page applications as they’ve been around for a long time. Gmail was the first to really become popular. And by the late 2000s, SPAs were definitely a well-established concept for devs; but as static sites became more and more popular, programmers decided to give a name to the decade-long trend that encompassed both. Hence, we now put SPA’s under the wider JAMstack umbrella.
Just try not to confuse the two. SPAs are browser-based applications and JAMstack is a frontend paradigm. They’re related but different.
And like everything, there’s always a downside.
It can be hard to mix a basic SPA with other popular frameworks in the JAMstack, like Nuxt.js for example. Hard, but not impossible. Parts of your site can be statically generated, and other parts can be left dynamic in a classic SPA manner.
So, for my purposes, I wanted to have static pages and login pages, but I didn’t want my login pages generated. The only solution for something like this today is server-side rendering (SSR). And while I was tempted to use a CMS with a framework like Next, I really just wanted to make the frontend without even worrying about backend templating.
The good news is that my site wasn’t going to have millions upon millions of pages or even really complex features. So I decided my best option for building a website while sticking strictly in my wheelhouse, the frontend, would be a SPA with an e-commerce integration (i.e. Snipcart).
Now I had my gameplan but needed the framework. After a bit of playing around, I settled on Vue.js.
Building the Vue.js SPA
I graduated from University in 2013 which is when you could say I started coding professionally. That said, I didn’t get into Vue.js until late 2014 because the framework took a while to gain popularity in France after its release earlier that year. I had actually been working with AngularJS but found, for me, there were just way too many performance issues. If you’re an Angular fan, it’s nothing personal! It just wasn’t working out for me. So I searched for alternatives.
With time, Vue.js became the solution I was looking for.
Truth be told, I was learning Vue at the same time as React and, to make a long story short, all the Vue.js features won me over. The biggest difference was in the templating. With Vue, I was able to use regular HTML which was more complicated with React. Plus, Vue has really great tooling.