Introduction
This page is meant to serve as an extended portfolio entry for the website you're browsing right now. If you're looking to read more about me personally, I have a pretty neat home page to introduce myself. Actually, if you haven't already, try visiting the home page to scroll through the flashy effects, then come back here to learn about the work that went into it!
Fun's All That Matters!
I actually built this site a fairly long time ago now. The experience of building this website has surely benefitted my skillset, but I've been learning and growing so much since then. If I were to start this project over again, there are many decisions I would probably make differently today. Even so, I think it's important to improve by continuing forward, instead of obsessing on the perfection of times passed, so I want to fondly hang this in my proverbial gallery and move on to other ambitious things!
That being said, I had fun developing this thing! It was my first time doing a lot of stuff - cutting edge stuff I had never done before, and stuff I had very little opportunity to do on the clock. These kinds of projects always teach me the most about what to do and what not to do, so I consider it a valuable stepping stone in my career. As such, I want to cover some of those lessons while I talk about what I did to make this thing tick!
What I Did Right
With a site like this, the first and most important decision is all about the tools. I still feel today that I chose the right tech stack for the job.
For the most part, this is just a static website. The most I need for maintenance is a content management system (CMS) and that didn't really call for a whole lot of server-side responsibility. I heard about a website called Storyblok , which offers a headless CMS with customizable schemas that can correspond with components in any given front end library or framework. Basically, it's a CMS that serves your content from a RESTful API. I thought it was such a neat idea, in contrast to Wordpress and others which marry you to their codebase. It turns out, I was very right to choose this service. I've used Storyblok in many projects after this one, and I've never had an issue. It gracefully separates code from content, which solves a boatload of issues, especially on teams where marketing requires access to modify the content.
That answers nearly all of my needs for a server, so I could just use Vue.js on the client-side without worrying about anything else... or could I? There's a common criticism I've heard even today about all of these modern front end solutions using single-page designs: SEO may be negatively impacted if you serve an empty page to be rendered on the client. It feels like old news by now, but this is easily solved by using isomorphic templates, which may render on either the server OR the client. This way, you can use a router on the back end to serve up a fully rendered HTML page when each of them is visited, then for speed's sake, it won't do that again unless you manually change the URL or refresh the page. That's where Nuxt.js comes in - it can do all the aforementioned and more.
I couldn't find a satisfactory solution for scrolling effects that didn't involve an outdated jQuery plugin, so I went with a homegrown solution of my own for a parallax effect, and the native Intersection Observer helped with a lot of the other scrolling effects too.
As for layout, I'm happy to have gone full native, with "separation of concerns" in mind. Grid is so widely supported these days, and Flexbox has been for years, so I saw no point in using a CSS framework like Bootstrap for grid layout. All my mentors have drilled into my head that class names should always describe the content and never the presentation. I feel that naming classes after rows and columns is rapidly becoming as outdated as using <table> for layout.
Speaking of styles, I also opted not to use SCSS. I don't tend to make use of its nesting syntax, because that kind of specificity can be tough to manage. Mixins can sometimes be nice, but I rarely find myself longing for them, especially since modern CSS gives us calculated values, filters, and variables. Scoping all my styles to each component has simplified nearly all the complexity that might otherwise require non-native syntax to simplify. Instead, I chose to use PostCSS , which let me write native CSS without worrying about browser support or prefixes.
As far as my actual execution goes, I think I did alright! Of course, I will criticize myself in the next section, but this is far from unmanageable, should I ever decide to clean it up. Even when I didn't have enough separation in my components, I stuck with the BEM naming convention which made the styles easier to keep separate. In the event that I do revisit this, that will have made it easy to pick up where I left off.
Going beyond the code, I even implemented a CI/CD pipeline all the way up to production. When something changes on my develop branch, my staging site automatically rebuilds and redeploys. Same goes for my master branch and the production website. This is honestly so nice that I will never manage another personal project any other way.
What I Could Have Done Better
More than anything, I think the structure was a bit weak in each department.
Components - I should have broken many components into smaller digestible parts. After facing some of the issues with larger files, I've learned to hone in on this more carefully during the early stages.
Scripts - I lacked good composition in some of the more script-heavy components. Now that I've learned more about functional-style programming, I would probably export pure functions from a utilities file and call them inside the component. This would also make everything a bit more testable, which is another thing I lacked in this project.
Styles - I started realizing after it was too late, but there are some good rules of thumb I've come to learn over the years. Generally speaking, styles should be applied very conservatively on outer elements to give the inner elements the most flexibility and control. For example, there should seldom if ever be side padding on a page-level element, it should be up to the innermost element to decide whether or not it will touch the edge of the viewport. That one in particular has tripped me up a lot throughout my career, because the business team always wants a full-width banner in the most inconvenient of places. A little foresight goes a long way, even in personal projects.
Environment - Honestly, no matter how small the project, I can never find a good enough reason not to use a Docker container. The advantage of having the production environment match the environment on your development machine is just too great to overlook, putting aside the scalability with Kubernetes. It's also great for the event that you have to work on multiple projects that require different versions of Node, or anything else for that matter. NVM only gets you so far, and it can be a major pain in the neck to find the node version and switch all the time. Everything is easier with containers.
Stricter lint rules - Okay, yes, it's just a small personal project, but linters exist to save you from common preventable bugs so you don't have to get frustrated by troubleshooting later. I had the pleasure of working on one project for work which was set up with strict pre-commit hooks. It may be overkill when it's just me on a project, but boy did I appreciate it. Before it would allow you to commit, it would run tests, run a strict linter (this thing would even force you to switch your unchanging
lettoconstand complain if your functions were impure,) then it would have to build successfully. It annoyed some of my peers, but just between us... that made me even happier. They were no longer allowed to commit subpar code, haha!
In Conclusion...
If you're here to size me up, I feel like the above explains where I'm at with this website pretty thoroughly, though there's a lot more I can say about my experience in general. If you have any specific questions, feel free to shoot me an email or call me ! Otherwise, you can also have a look at some of my more recent projects in my portfolio, or read through my latest resume.