DEV Community: Patricio Salazar

You Don't Need A Framework - Build A Dynamic Blog with HTML & Vanilla JavaScript

Patricio Salazar — Wed, 28 May 2025 18:37:57 +0000

Months ago, when I was reworking parts of my website, I began questioning every part of the tech stack. During that process, I thought about how I would build a dynamic blog with vanilla JavaScript. Eventually, I realized I was still going to end up using a framework. So, I worked through the main concepts in my head to scratch the itch, then shelved the idea...until, I couldn't ignore the fact that the itch was still there.

This article is simply about the JavaScript side of building a dynamic blog. It is not a claim on the best approach for such a system, nor an argument for or against using vanilla JS or a framework. We're just looking at how this could get done.

Let's get into it

First things first, we need a few HTML and JS files, so let's get a new project going in your favorite editor (feel free to code along).

Create a new folder, name it whatever you want, and open it in your editor. Create the following files and folders:

index.html
blog.html
blog/post.html
js/blogCards.js
js/blogPost.js
js/blogPostsData.js

No Webpack, no Vite, no package.json... and no Tailwind 🤯. Ahhh, how refreshing.

Boilerplate code

Here is the relevant HTML

blog.html:

Include the script tag for blogCards.js in the head
<script type="module" src="/js/blogCards.js" async></script>

blog-post.html:

Include the script tag for blogPost.js in the head
<script type="module" src="/js/blogPost.js" async></script>

Also, the blog post data

blogPosts.js:

Add as many blog post objects as you want. I had ChatGPT generate some dummy data here.

Start and preview

This is a good time to start the project to see what we have so far. If you're using something like VS Code, view the project using Live Server.

Dynamically populate the blog listing page with blog-post cards

Let's start by importing the data at the top of the blogCards.js file:

import { blogPosts } from "./blogsPosts.js"

We're going to have to place each blog card inside of a the container element we created in the blog listing page, so let's declare a blogCardsContainer variable and store a reference to the container in it:

const blogCardsContainer = document.querySelector("#blog-cards-container");

Now, we can loop over each blog post in our data, create the cards, and then finally append them to blogCardsContainer:

The first three lines inside of the forEach loop:

Creates a div element to be styled as the card
Adds a "blog-card" class to the div
Sets a "data-id" attribute on the div with the value of current post id to uniquely identify each blog post card (in case you want control for individual cards).

Here's one of the most important parts of the blogCardHTML content we created above: We set the href attribute to the individual post.html page, but, and here it is, we add in a slug parameter which is the value of the blog post slug. This is how the individual post.html page knows what blog post it's supposed to be loading when navigated to.

Now that we know which post is supposed to be showing, all we have to do is create the HTML structure for our blog post and load in the post data, similar to how we did for the blogCards - except we're not doing a loop this time. Let's apply the logic...

Dynamically building the individual blog post page

When our post.html file loads, we already know that we're going to have a post slug as a parameter. This is how we know which post to work with, so let's set it up.

At the top of blogPost.js, import blogPosts

You may know about the window.location object. But, to isolate the query parameters from the URL, we can access the search property on window.location, and we'll pass that into the URLSearchParams interface:

`const params = new URLSearchParams(window.location.search);

`The URLSearchParams interface exposes a 'get' utility method allowing us to retrieve the exact parameter we're looking for:

const slug = params.get("slug");

Perfect. Now, let's find the exact post:

const blogPost = blogPosts.find((post) => post.slug === slug);

Like with the blogCards, let's grab the blog post container on our post.html file so that we know where to inject the post after we build it:

const blogPostContainer = document.querySelector("#blogPost");

Okay, now let's build the blog post HTML structure, and inject into the blog post container, but only on the condition that the post was actually found. For now, we handle the situation where the post isn't found by displaying some simple text.

Try it out

Go back to the blog listing page. Navigate to different posts, and watch them be displayed onto the page.

🎉 Congrats! You now know some essential concepts needed to build a dynamic blog system in vanilla JavaScript 🎉

If all this has made you curious to find out how much more it would take to get this blog to a complete, production-ready level, I encourage you to scratch that itch - It'll be worth it.

Here's a hint to some modifications and optimizations that would make this project better:

SPA experience
- load all content and pages using a single div in the index.html file, just like frameworks do
- this will offer better URLs and faster load times since you won't be loading full pages
Store blog posts in an external db
Use a mouseover event listener on blog post cards to prefetch html content

Conclusion

Although there are many changes you could make to this project, the point is you don't always need every framework feature. Often, all you need is simplicity.

If this article helped you learn something, I'm so glad. But there are three important takeaways I hope you’ll leave with:

Remember to question things from time to time.
Go beyond the question, and let your curiosity scratch the itch (think about the solution)
You don't always need a framework 😏️

https://patriciosalazar.hashnode.dev/you-dont-need-a-framework

How to Use Laravel Sail with Docker for PHP 8.2 (No Global PHP Upgrade Needed)

Patricio Salazar — Tue, 06 May 2025 18:21:18 +0000

How to Use Laravel Sail with Docker for PHP 8.2 (No Global PHP Upgrade Needed)

Working on a Laravel project that requires a newer PHP version can be tricky if your system’s PHP is older. My personal computer is a Mac, but my work computer is a Linux machine where I sometimes run small projects for exploring and learning new technologies. In that case, upgrading my global PHP installation is not an option since I’d risk messing with work projects.

This is exactly the kind of situation Laravel Sail is for. Laravel Sail lets you use Docker to run your Laravel app with the required dependencies, all while keeping your global system versions untouched.

Here is how I set up new Laravel projects on a Linux computer (works on macOS, Linux, or Windows via WSL2) with Sail and the latest versions of PHP (without touching the global version).

First, get your project and terminal ready

Once you have your Laravel project files ready it’s time to run some commands.

If you’re using a Laravel starter kit with Inertia and React or Vue, the installation process might have already run npm install for you. If not, go ahead and run that. Otherwise, skip this command.
Now, try running composer install. If you get an error because you have an older version of PHP than required…good! We’re on the same page.

Next, we need to run a temporary Docker container to get the latest versions of the required dependencies. Run this command:

docker run --rm \ -u "$(id -u):$(id -g)" \ -v "$PWD":/var/www/html \ -w /var/www/html \ laravelsail/php82-composer:latest \ composer install

What the above command does: It spins up a temporary Docker container using the Laravel Sail PHP 8.2 image, executes composer install inside the project folder, and then stops and removes the container.

docker run --rm: Start a new container, and remove it (–rm) when it’s done (so it won’t hang around on your system).
-u "$(id -u):$(id -g): Run the container with your user’s UID:GID. This ensures any files Composer creates (like the vendor folder) will have the correct permissions matching your user, not root.
-v "$PWD":/var/www/html: This command mounts your current host directory into the container at /var/www/html, allowing the container to access and modify files in your project.
-w /var/www/html: This sets the working directory inside the container to /var/www/html, ensuring that subsequent commands run in the correct context.
laravelsail/php82-composer:latest: This specifies the Docker image to use. It’s an image with PHP 8.2 and Composer installed (provided by Laravel Sail).
composer install: This is the command we want to run inside the container. It will install all the dependencies as if you ran it on a machine with PHP 8.2.

Configure Sail and Docker

Run the Sail installation (Artisan) command inside Docker. This command publishes the docker-compose.yml file and updates your .env with environment variables for Docker.

Note: If you want to use a different database in your project rather than the default MySQL, add the --with= flag to the command. To keep the default MySQL db, omit the additional flag.

Run:

docker run --rm \ -u "$(id -u):$(id -g)" \ -v "$(pwd)":/var/www/html \ -w /var/www/html \ laravelsail/php82-composer:latest \ php artisan sail:install --with=pgsql

This docker command is similar to the previous one, except now we’re executing the artisan sail:install setting up Docker/Sail along with the optional PostgreSQL db configuration.

You should see a docker-compose.yml file in the root of your project now.

Note: The values added to your .env (and the ones in docker-compose.yml) are mostly default/local settings. For example, Sail might set DB_PASSWORD=password and DB_USERNAME=sail (or postgres) for your database, which are local credentials for the Docker containers. If you’re anything like me and have multiple Laravel projects running at the same time, you might need to adjust port numbers. For instance, you probably need to add APP_PORT in the .env file and customize the value with something like APP_PORT=7070 to have your app run on port 7070 instead of the default port 80, where 80 is already in use. Just make sure you update your docker-compose.yml file to match this. The same is true for SERVER_PORT, and SERVER_HOST (and VITE_PORT, if you have an inertia frontend).

It’s time to launch Sail

Run:
./vendor/bin/sail up -d. OR
sail up -d, if you already created the alias for sail. The -d flag runs containers in the background and frees up your terminal shell.

At this point, the above command should run successfully.

If you cloned a repo your .env file won’t have an app key value. If this is true for you, run this command while Sail is running: sail artisan key:generate.

Now, run migrations: sail artisan migrate.

If you’re using Inertia, this is where you want to start the frontend application: sail composer run dev.

Congrats, now you can happily code to your programmer hearts content. Go build, but don’t forget to ship!

Getting My First Users From Building Something Unexpected

Patricio Salazar — Tue, 17 Dec 2024 07:38:23 +0000

This one has to start with the story. I’ll try to keep it short.

A Random Memory

When I was younger, say in my teens, I would do this thing in my head where I would double numbers. Sometimes random numbers, but most of the time from the number 2. So for example, 2, 4, 8, 16, etc. And I put a mental timer on it, so my goal was to see how fast I could do it without thinking much and see how far I could take it.

Side-note: I don’t know why I did that. I was never big on math. It was like a mental fidget during random in-between moments.

I had absolutely forgotten that I did that. Three months ago, I suddenly remembered while I was having lunch with my wife. I asked if she’d ever done anything like that, and yup, you guessed it—she hadn’t. Now, I’ve never been interested in building a web game, but one of the next thoughts I had was “I have to build this thing”.

Okay stop. Story over. There you have it, that’s the unexpected thing. I built a web game. BUT, please don’t leave just yet. I also want to tell you about what happened after I built the game.

Building and Sharing

Building the game took me about a couple days, it was done in a weekend (this post isn’t about the code, so I won’t get into that). I didn’t focus on making it look fancy or anything like that. I made it for myself, as an ode to the memory of an old mental fidget. I did however, know I would take a chance on sharing it. After all, if people like it, they’ll like it for the experience, not a shiny UI. By the way, it’s called Doubles.

Enter Reddit. I went looking for the right subreddits and ended up posting in these:

r/math
r/gamedev
r/IndieDev
r/learnmath
r/WebGames
r/IndieGaming

Sharing on Reddit taught me that the right audience will amplify visibility.

Right away, and to my complete surprise, strangers on the internet loved it. I got responses like this:

🤯🤯🤯 As the title of this post suggests, these are my first-ever users. A.K.A. you’re watching me create my first public side project, learn how to get and interact with users, and iterate on a project based on those interactions.

I have to say, getting users on something you built, and having positive feedback has to be one of the best feelings ever. Not in an ego way, in a purely shocking way. It’s gotta be the “indie dev’s” version of a musician’s first time hearing themselves on the radio. Alright, chill—I’m dating myself 🤣.

The first few days my Cloudflare analytics showed somewhere around 200—300 users had visited the site. That was incredible already. Then, days after not having posted anything, I checked the analytics and there was a spike of 1K+ visitors overnight! Whaat?? Excuse mee?! I started investigating.

It turns out they were all referred by B3ta.com. A UK based newsletter. I’m not sure how long they’ve been around, but they claim it “currently has nearly 80,000 subscribers”. Someone on their team must have seen my game, liked it enough, and shared it to their subscriber base. They also share a version of their newsletter on their website, and guess what? I FOUND IT. Here’s what they shared:

Hahaha. Good by me.

Fast forwarding a bit, I saw traffic from them trickle in for a long time. Nothing as big as the first couple days after they shared, but it was amazing enough. I’ll never forget that.

Since then, I still haven’t shared anything new, but I saw Doubles get picked up by another couple sites. One was this guy’s website. Shoutout to him. I saw a small amount come from there, but he never had to do that in the first place. Another is a site called CloudHiker. I see a couple visitors from that site every day. I’m not sure how it ended up there.

Traction continued for a couple months every single day all on its own. I saw anywhere from 20-80 regular users a day. I know because they were navigating directly to the site, not from any referrer.

Monetization

Nothing to report here, lol!

I tried to figure out a way, but this kind of site is not easy to monetize. And as far as ads go, no worthwhile ad service wants to serve ads on my little game website. Oh well. This is something I will consider more deeply ahead of future projects, but not everything needs to make money.

How’s It Doing Today?

Truthfully, it’s died down hahaha. I never talked about it again, and obviously I think that was a mistake, but you can consider this the start of me talking about it again. You can still play it here Doubles.

Here’s what I learned:

Picking the right project matters.
As a solo creator, I can make decisions, build, iterate, fail, and learn fast.
Caring about user feedback was highly valuable. Talking to the users and responding to them as soon as I implemented a feature request or bug fix is major and made them feel closer to the project. For example, after working with one of my users requests, he replied like this: “Love to see a dev actively responding and excited for feedback :)”
You spent time and effort building something, you should do the same for communicating and marketing it.
Some users will give you the best ideas to make your project better. Build relationships with them.

There you have it. That’s my story of getting my very first users from a game.

Thanks for sticking around until the end.

If you enjoyed this content, stay tuned for more updates on the projects I build, along with more stories and lessons, by subscribing below (no spam). And if you haven't already, click on one of the emoji’s on this page!

Until next time!

How I Added CSV Importing In My React-Node.js Project

Patricio Salazar — Wed, 11 Dec 2024 21:20:36 +0000

Touch Base was fine. It was a cool project. It worked. But, let's face it—was it usable? (Touch Base is a full stack React contact management app that I made).

I was thinking about this and realized something obvious. When a user starts using Touch Base they have to add contacts manually. Which might be fine if you have 5 contacts. If you have 1,000 contacts you want to add, this sucks… and you probably won't want to use this system. So of course, I knew I had to add the ability to import contacts.

Researching Options

My first Google search was “csv importers”, or something like that. I looked through some of the options available and found FlatFile. Their main heading read “The fastest way to collect, onboard and migrate data.” Perfect… except, it wasn't all that for me. Now, this is probably my fault (they seem like an amazing service) but the process of implementing their importer was taking more effort than I was willing to put in for this. This is the perfect time for a little sidebar context:

Lately, I've been really valuing scrappiness. I want to get things done, fast. This isn't about cutting corners, I just don't want to have any excuses or unnecessary delays. After all, I'm just one guy working on side projects. So my current attitude is fail, learn, and iterate fast. All while doing good work.

Back to FlatFile. As much as I wanted to use their promising software I asked myself if I really needed all their bells and whistles and if fighting their docs was worth it. Definitely not. So I went back to my search and landed on Papa Parse. I recalled seeing it in my previous search. Their main heading read “The powerful, in-browser CSV parser for big boys and girls.” 😆 I was in.

Implementation

First things first, I added a POST route to my API.

verifyToken is a function I use in all my routes that does exactly that—verifies the users id token. I use multer in my app which is a node.js middleware for handling file uploads. upload.single('file') is a multer function that helps me upload files to my s3 bucket.

Inside the route, I grab the user id and file through destructuring.

Like the npm package docs for Papa Parse state, “Papa Parse can parse a Readable Stream instead of a File when used in Node.js environments (in addition to plain strings).”

So I prepared to stream the file directly to Papa Parse by creating said stream from my s3 bucket as well as an empty array to hold the results data. Can't forget about handling potential errors.

Then I finally pass the stream to Papa Parse, set my config options and handle any errors coming from the results.

In the code above, complete is a Papa Parse property that takes a callback function. It executes once the parsing is complete. I then grab a hold of the data provided by results as parsedData.

After this, it's time to run some queries on the database and process the contacts. But, I need to store a connection the the db to run the queries on first.

This next part is a lot of code in a try catch statement, so I'll just give it to you straight with some comments on it.

As you can see, I

fetch existing contacts
filter out duplicate contacts using emails, since no two emails can be the same
bulk insert the non-duplicate contacts into the table

Frontend

The frontend will be largely specific to my approach of the app, but let's connect the dots here.

The Import Contacts page does one thing so it's very simple. I use the native file upload button which is really an input.

When the input detects a change I trigger a handleFileUpload function.

Inside of the handleFileUpload function, I first set the loading state to true so that I can display my little loading spinner to the user while this process takes place.

When a user successfully uploads their .csv file, I append it to a new formData object and send it to my backend route above to process it. I directly use a fetch request here since it's the only place in my app that's going to hit the /import-contacts endpoint. If another part of my app needed to hit the route, I would store the request using context and use that to avoid repeating code. Also, you can see the error handling I have set up…

Upon successful handling of the file or if it errors out, the loading state gets set back to false, and I trigger an appropriate toast alert to let the user know exactly what happened in a nice way.

It feels so nice to log in, upload a .csv file of contacts, get a successful toast alert, and then see all of the new contacts populated in your account. And it's so quick. You might see the loading spinner for just a second. The bulk insert query also helps a lot there.

From Maybe Usable to Usable

Before adding this feature I wondered how usable the app truly was. Now, there's no question about that. Although it wasn't super complex, it's a feature you would expect to see in this type of application so I found it a requirement to implement. I think it makes it a little more serious of a project. Aside from that, I've never done anything with .csv files which made this super fun to work on. Papa Parse integrated so well with all the tools I was already using which made it super easy. I definitely recommend using it.

If you made it this far, cheers to you for reading this 🥂...
and cheers to software that doesn't suck 🥂

p.s I'm still wondering if my project sucks 😂
If you want to check it out here's the link again.

Til next time!