My Background

Before we go further into some of the lessons I've learned, I want to bring you up to speed on how I got here. I have been playing video games and building computers since I was seven or eight years old. I took my first coding class in high school, a semester class learning Java, I believe. When I got to college, I couldn't decide what I wanted to do and ended up graduating with a degree in business administration. A couple of years into the job force, I missed coding and thought I'd give that a shot since I wasn't super into my data entry job at a flooring company. I didn't have the ability at that time to go back to college for a computer science degree, so I went the route of a twenty-four-week coding bootcamp. Over the course of those weeks, I gained a working understanding of how to create websites that I would describe, looking back, as the bare minimum.

I spent the next year or so trying to teach myself the things that the bootcamp did not. They taught me how, but we didn't have the time to learn why. Seven months after I graduated from the bootcamp, I got my first job as a software engineer, working at a company local to Kansas City. My daily work involved using HTML, CSS, and JavaScript to build small improvements to our external website. I worked under a senior engineer, alongside a small team of five. I continued to try to learn and grow as I went, but I got comfortable quickly with what I was doing. This leads to the first of the lessons I have learned in my five years as a developer.

The Why Actually Matters

The first lesson I want to discuss is that the why actually matters. I was comfortable in my first two years just knowing that I knew how to build a website. I knew how to make it look good. I knew how to make it do stuff and how to allow users to interact with my websites. I knew that if I copied in some code, I could connect my website to a database. But as I grew more comfortable with how I could accomplish these things, I realized that I didn't know why my code did certain things. I didn't know how the internet worked or what JavaScript was doing under the hood. I didn't understand what happened when people landed on my website. I knew what they'd see and what they'd be able to do, but I did not know what was actually happening. Upon this realization, I came to the decision that I didn't care. I didn't care that I didn't understand why. I knew how, and that was enough to get me a good job to pay the bills.

Ignorance was bliss, but it was short-lived. As I got further into different languages, joined different communities, and took in different content in the programming realm, I realized quickly that at my current trajectory, my skills and abilities were permanently capped by my lack of understanding of why. I learned that eventually, the why and the how to do certain things were tied closely together. This was a hard lesson, but I realized that at that moment in time, I was a bad programmer. But that's okay because everybody is bad when they start. But I was capping my growth by refusing to dive into the why. In order to get good, you have to realize first that you are bad. And that's why this lesson was so vital to learn. So I started learning why. Instead of watching tutorial videos only, I started reading documentation. Instead of only copying and pasting, I started writing stuff on my own, failing and growing the whole way. Instead of thinking that the understanding of data structures and algorithms was not relevant to actually doing the job, I started pursuing an understanding of computer science.

I still have a long way to go. I still have understanding to build up. But I'm better today than I was yesterday. I know more about the why now than I did before, and that has made me a better programmer. Turns out, understanding how a computer handles memory does, in fact, allow you to create better software.

New Does Not Mean Best

The second lesson is that new stuff is not always better. Now, this one can be applied outside of software and our jobs, but I'm going to stick to that context to the best of my ability.

I have struggled my whole adult life with always needing the new thing. I needed the new MacBook, the new iPhone, the new TV, the new car. And that consumeristic attitude bled into my programming. Every couple of hours, a new JavaScript framework comes out. And I would rewrite apps and sites in the new frameworks because it was shiny and new and better. And sometimes, new stuff is just fundamentally better. But I turned into the guy that's always changing my toolsets to use the newest stuff. Because new is always better. Except, it's not. Us web devs are now realizing that client-side heavy single-page applications are not actually always what is best. Sometimes, instead of using React and Redux, several different libraries, and a few UI plugins, we can actually just serve HTML with a simple node server. Now, depending on what you're doing, the full framework solution is needed. But if we always use what's new just for the sake of it, we are going to have a ton of bloated, over-engineered websites that destroy the experience of the user.

The lesson is when new things come out, we should try them. Install the new tool, download the new language, create a todo app with the new framework. Explore the new things, and to call back to the first lesson, maybe even dig into what makes the thing work. But then, make a decision on whether or not to bring that new thing into your toolset based on parameters outside of just the fact that it's new. Decide on those parameters for yourself. Maybe it's speed, memory usage, developer experience. Just don't let your deciding factor be how new something is. Because you can make the same great CLI tool coding on a 10-year-old laptop running Arch Linux that you can on a brand new M3 MacBook Pro. You can make a great personal website using React. But you can make a great personal website using HTMX and Go.

The summary of this lesson is to bring in more parameters to your decision-making on a tool or language than just how new and fancy it is. Because sometimes, Neovim can write your software just as well as VSCode with 234 plugins.

In Conclusion

This got longer than I was expecting, so I'm going to put a few more lessons I've learned into a second post. I hope that these lessons benefited someone.

To the person just learning how to code - it's okay to not know everything. Everyone starts knowing nothing. Just write some code, and understand a little more today than you did yesterday. Enjoy the journey.

To the people who are a few years in - If you're like me, and somewhere between your first lines of code and now, you got complacent and stopped learning, don't feel bad. If you are okay where you are, that's alright. Enjoy the space, and make yourself some good cash. But if you're realizing you want to dig deeper, go after it! Go figure out some things you don't actually know, and learn something.

To the people that have more experience than me - I'd appreciate your input. If you can give advice and criticism without being rude or gatekeeping, please give me that advice. I have so much to learn, and I am always open to those who are paving the path ahead of me sending some wisdom my way.

Thanks for reading!

As a freelance web developer, I searched for a while to find a way to quickly spin up new web projects. Most of my clients require fully custom web applications, so it became apparent pretty quickly that I needed to speed up the startup process on a new project. Sure, I could write a script that scaffolds out a new project, but when I found out about GitHub template repos, it was obvious that for me and my work, it was the way to go. If you are unfamiliar, you can check out GitHub's documentation on the feature here. Essentially, you can create a repository as you normally would, with all the source code for your project, and then mark the repository as a template. You and others can then go to that repo, and create a new repository that is a copy of that repo you made. This means you set up the perfect project template once, update it in one place, and use it as many times as you want.

Why Use SvelteKit?

SvelteKit is an open-source meta-framework that uses Svelte and Vite to allow developers to create web applications quickly and efficiently, with an excellent developer experience, and enough built-in features to make it powerful, but still light and flexible. Svelte places immense focus on the "HTML first, JavaScript if needed" approach to web development, which by default means we are sending smaller bundles to the client. SvelteKit is an open-source project and is backed by a very responsive core group of maintainers. It is also supported directly by Vercel, which makes deploying your apps as simple as possible (which we'll get to later). This makes SvelteKit a fantastic choice for freelance web developers.

Getting Our Template Started

We will start by creating a brand new SvelteKit app locally (for this, you'll need node and npm installed on your machine). Run the following command in your terminal.

npm create svelte@latest name-of-your-app

I named my app sveltekit-template, but feel free to be more original.

You will then be walked through a short setup cli. When asked about a Svelte app template, we'll choose 'Skeleton project'. Next, we'll decide to use type checking with JavaScript with JSDoc comments implementation (which is recommended by the project creators if you are needing type checking). For the additional options choices, I use prettier for code formatting but feel free to use your discretion here.

To finish our initial setup, we'll run the following commands in our terminal.

cd name-of-your-app
npm install
git init && git add -A && git commit -m "Initial Commit"
npm run dev -- --open

If we have successfully set up this project, you should now have a barebones SvelteKit app running on localhost:5173. We will not be going into depth on how to develop in SvelteKit in this post, because that is for another post (stay tuned for that one).

Adding TailwindCSS

Regardless of the continued debate on tech Twitter about the usefulness of Tailwind, I truly enjoy the experience of using it in my projects. Style configurations are easy to set up, and the utility classes are easy to remember, easy to use, and allow me to style components quicker than any other CSS-based tool I have used. You can learn more about TailwindCSS here!

To start configuring Tailwind in our template, start by running the following in your terminal, from the root directory of your project.

npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init -p

This will install a few packages we will need and creates two new files in our project root.

We will next need to edit the svelte.config.js file, found at the root of your project.

import adapter from '@sveltejs/adapter-auto';
/* add this --> */ import { vitePreprocess } from '@sveltejs/kit/vite' 

/** @type {import('@sveltejs/kit').Config} */

const config = {
    kit: {
        adapter: adapter()
    },
    /* add this --> */ preprocess: vitePreprocess()
};

export default config;

Next, we will update the tailwind.config.js file, adding our file types to the content property.

/** @type {import('tailwindcss').Config} */
export default {
  content: ['./src/**/*.{html, js, svelte, ts}'],
  theme: {
    extend: {},
  },
  plugins: [],
}

We are almost ready to use Tailwind! The last thing to do before we test it out, we need to create a new file called app.css in the /src directory. Add the following code to that file.

@tailwind base;
@tailwind components;
@tailwind utilities;

We are ready to test our configuration! Create a file called +layout.svelte in the /src/routes directory. Add the following code to that file.

<script>
    import "../app.css"
</script>

<div>
    <h3 class="text-blue-600">This should be blue!</h3>
</div>

<slot />

Now, we can go ahead and run our app! Run the following command, and go to localhost:5173.

npm run dev

If the text we added at the top of the page is now blue, you have correctly set up TailwindCSS! Important to note, due to how CSS is handled in SvelteKit, we only have to import the app.css file in the layout. All pages you create that use that layout (which will be all new pages by default) will automatically have tailwind imported through that layout files import statement.

Final Tweaks To The Template

The last thing I did before turning this project into a GitHub template repo, was just make a few tweaks to SvelteKit to make it even friendlier to use.

First, inside the /src/lib directory, I deleted the index.js file they put there as a placeholder. I then added a components directory and a services directory there. I placed README.md files in these directories so git would pick them up.

Finally, I updated the svelte.config.js and the jsconfig.json files to handle my preferred alias overwrites.

/* svelte.config.js */

import adapter from '@sveltejs/adapter-auto';
import { vitePreprocess } from '@sveltejs/kit/vite';
import path from 'path';

/** @type {import('@sveltejs/kit').Config} */
const config = {
    kit: {
        adapter: adapter(),
        alias: {
            '@comps': path.resolve('./src/lib/components'),
            '@lib': path.resolve('./src/lib'),
            '@services': path.resolve('./src/lib/services')
        }
    },
    preprocess: vitePreprocess()
};

export default config;

/* jsconfig.json */

{
    "extends": "./.svelte-kit/tsconfig.json",
    "compilerOptions": {
        "allowJs": true,
        "checkJs": true,
        "esModuleInterop": true,
        "forceConsistentCasingInFileNames": true,
        "resolveJsonModule": true,
        "skipLibCheck": true,
        "sourceMap": true,
        "strict": true,
        "baseUrl": ".",
        "paths": {
            "@comps": ["src/lib/components"],
            "@lib": ["src/lib"],
            "@services": ["src/lib/services"]
        }
    }
}

These updates will allow you to use the alias tooling SvelteKit provides to import components and other files throughout your app.

So, if we are importing a button component into one of our pages, we could import the following

import Button from '@comps/button/button.svelte'

instead of

import Button from '../../../lib/components/button/button.svelte'

Turning This Project Into A GitHub Template Repo

Go ahead and commit all of our changes to your local Git repo, and then add this whole repo to GitHub as you normally would. Finally, you can go into your repo on GitHub, go into the settings for this specific repository, and you can check the 'Template Repository' option near the top of the general settings tab.

You've done it! You officially have a fantastic template to use for new web projects, utilizing modern tools like SvelteKit and TailwindCSS.

To test it out, go create a new repo from GitHub's website. Near the top, you'll see a dropdown labeled 'Repository Template', which defaults to no template. If you did everything correctly, if you click on that dropdown, you should see the name of your template repo as an option. Select that, give your new project a name, and click 'Create Repository.' You now have a brand new repo, with its source code, that is an exact match of our template. Now all you have to do is clone that new project locally, run npm install in the directory locally, and all the setup we have done on the template is already done for you.

Summary

Thanks for following along! I appreciate the read, and hopefully, you gained some value from walking through this with me. I use this particular template whenever a freelance client needs a custom website because I can spin it up in literal minutes, and start development right away. And using tools like SvelteKit and TailwindCSS helped me create really beautiful and performant websites quicker than with any other tools I have used. I highly recommend giving this stack a try in your next web project!

Link to my GitHub SvelteKit + TailwindCSS Template Repo