Forem: Technophile

How I make my site searchable in 2 minutes

Technophile — Sun, 08 Jun 2025 19:45:14 +0000

Your site will not magically show up on Google unless you help search engines to find it.

So, let’s fix that.

Basic SEO

First things first, in your HTML, add these lines of code in the <head> tag:

<title>My Awesome Site</title>
<meta name="description" content="This summarizes serves as an example. Use this wisely.">
<meta name="keywords" content="coding, youtube">
<meta name="author" content="Your Name">

This helps Google understand your content better, plus that's what it shows in Google search page when you look it up.

Next, if someone shares your site on Discord, Twitter, or LinkedIn — these control how it looks.

Add these lines as well.

<meta property="og:title" content="My Awesome Site" />
<meta property="og:description" content="Check out this cool project I built!" />
<meta property="og:image" content="https://yourdomain.com/preview.png" />
<meta property="og:url" content="https://yourdomain.com" />
<meta property="og:type" content="website" />

While, they're not mandatory, who doesn't like extra SEO boost, right?

Now, add a basic favicon so your site looks legit in tabs:

<link rel="icon" href="/favicon.ico" />

Also, without one, sites often don't look authentic.

And, lastly, add this line to ensure your site doesn't break on phones, because without it Google will dock points for it.

<meta name="viewport" content="width=device-width, initial-scale=1.0">

Advanced SEO

That's pretty much it, but if you want go an extra mile, we can generate a sitemap and add it to Google Search console.

If you're using Vite, install this plugin first in the terminal:

npm i vite-plugin-sitemap

Then in your vite.config.js, add these lines:

import Sitemap from 'vite-plugin-sitemap';
plugins: [Sitemap()]

Which, should give you a sitemap.xml at the root. That’s what Google looks for.

Next, go to Google Search console and link your domain. Here, you need to confirm that you actually own your domain. If you're using Namecheap & Netlify to host your website, all you have to do is copy the TXT value provided by Google search console and add it to the Netlify as a new DNS record.

It takes some time for it to take effect, but then your site should be easily searchable with this max level SEO setup.

Video format

5 Killer Project Ideas for Developers in 2025

Technophile — Sun, 02 Mar 2025 06:11:48 +0000

TL;DR

Automated Roadmap Generator
Leaderboard for Open Source Projects
Live Coding Interview Platform
Real-Time Multiplayer Quiz Game
Personalized Code Snippet Organizer

Automated Roadmap Generator

No intro. Let's start with an easy one: an automated roadmap generator. Think of it as a tool that helps new developers create personalized learning roadmaps based on their interests. Users can choose non-coder-friendly topics like designing websites or automating tasks, and the platform generates a clear, step-by-step guide tailored to them.

You can even collaborate with learning platforms to mention or promote their courses, which is a win-win for both parties. For the future plan, one option could be integrate AI to analyze user preferences instead of relying on just multiple-choice questions. It feels more engaging and personalized.

Here's one pro tip: DON'T over-research similar projects. A bit of inspiration from UI designs or core features is fine, but too much digging will leave you feeling like better versions already exist and it can be demotivating. So, get a few inspirations and start building!

Leaderboard for Open Source Projects

Now, it's time for open-source. Contributing is rewarding, but often not in a visible way. Why not change that? Imagine a leaderboard where developers earn points and badges for their contributions. Whether it’s fixing a bug, adding documentation, or implementing a feature, contributors get rewarded, motivating more developers to get involved.

This kind of project especially drives a lot of new developers as well, to engage more with open source. One potential direction could be instead of making it global, you could allow your project to be integrated to other projects, which makes every open unique with their own leaderboards. In terms of handling the scoring, a good starting point could be pulling data from the GitHub API to track contributions. I’m just here to plant the seed, and it’s up to you to make it grow!

Live Coding Interview Platform

Now, let’s improve coding interviews! While platforms like LeetCode are great for practicing questions, they lack a key feature: live interviews. Your project could let developers act as either interviewers or interviewees—improving skills on both sides. Points and badges are always a good option to keep users engaged.

For the project itself, you will have to set clear rules and standards to maintain collaborative and safe community for your platform and to avoid turning your project into something chaotic.

Real-Time Multiplayer Quiz Game

Next up: a real-time multiplayer quiz game. Platforms like Developer Quiz Site are fun, but solo quizzing can get boring. Why not make it more exciting with real-time competition? Players could race to answer coding-related questions and rack up points. Think of it like Menti but for developers. You can use the similar structure of Developer Quiz Site, where users contribute quiz questions. Plus, it could attract a lot of new contributors as well!

For the future plans, you could even create topic-specific rooms, leaderboards, and achievements to, at the end of the day, make learning fun and addictive.

Personalized Code Snippet Organizer

Finally, let’s talk about organizing code. Developers love their code snippets, because it saves a lot of time. But organizing them can be a challenge. You can create a platform to let users organize their snippets by their language, categories or tags, and find them quickly with a search.

Wait... I'm already working on this one! Check out this video or visit the GitHub repo for more. So, this one’s off the table. You’ll have to take one of other four ideas. xD

Good luck with your coding journey! As always, thanks for reading, and I’ll see you in the next one.

We made QuickSnip even better (v1)

Technophile — Tue, 25 Feb 2025 22:01:31 +0000

QuickSnip is an open-source project that categorizes handy code snippets across various programming languages.

Excitement

When I published the first video, the project was still draft. Yet, developers loved the idea of storing code snippets and kept suggesting new features and updates.

My notifications were exploding with likes and views from YouTube as well as issues and PRs from GitHub. And, even VidIQ couldn't keep up with congratulating me on new subscribers count.

While others were celebrating the New Year, we were reviewing issues and merging pull requests. And honestly, it was one of the best New Year’s I’ve ever had.

Changes

Okay, let's get back to QuickSnip.

First things first, we reached our 50 likes target on YouTube in just under 24 hours and as promised, I immediately bought a custom domain for the project. By the way, I collected every single suggestion from both YouTube and GitHub community up until now. And, yes, I wrote them all one by one.

Now, onto the changes:

First big update: we added a light theme and migrated to a new storage system. As our snippet collection grew, managing them in JSON became a difficult task. So, we switched to Markdown for better readability.

Another major request was adding support for frameworks and libraries. With the new system, adding support became much easier.

Next big change was adding basic search functionality. This feature was quite a long discussion with our maintainers. Yet, finally, we pulled it off. Oh, and you can now share the snippets too!

Other improvements include cleaner code, bug fixes, hundreds of new snippets, accessibility improvements, cool animations and plenty of quality-of-life updates.

Also, one of my viewers created a Raycast extension for QuickSnip. Definitely worth checking it out.

I learned more about managing an open-source project in just two weeks than I probably would have in an entire year. I even made a full 9-minute video breaking down what I've learned. Check it out and save yourself some time in the future.

Future plans

Just like we did with the previous video, let's talk about future plans.

We created a VISION.md file on GitHub which outlines our potential long-term goals for QuickSnip. For QuickSnip v2.0, the biggest update we're working towards will be the possibility of having private code snippets with personal accounts.

Stay tuned for future updates.

As always, thanks for watching and I'll see you in the next one!

I Built a Game for My 1000 Subscribers

Technophile — Fri, 17 Jan 2025 04:25:17 +0000

We hit 1000 subscribers on 9th of January. To celebrate it with my audience, I wanted to make something special. Then the idea clicked: 1000 subscribers equal 1000 cells. One cell would hide a confetti. And, you, the viewer, would have to find it within a time limit to unlock special perks. And since we're already working with confetti, why not add some confetti animation to make it even more fun?

👉 Play the game here: https://technophile-1000-subs.netlify.app

Design

As always, I started with building the sketch in Figma, because I wanted to play around with different layouts and colors. And, finally, I settled on a complementary cyan and orange palette on a sleek dark theme.

Coding

Now, design is ready, let's get to coding. Why use a framework for a project when you can use Vanilla JavaScript? So, I first built the grid with 1000 cells and hid a confetti in one of them. By the way, when building games like this, I usually prefer Object-Oriented approach, because it makes the code clean and organized.

Layout was done, but, plain cells were not exciting, So, I added a cool hover effect where previously hovered cells slowly fade back to their original color. I used GSAP for this animation.

Now, finding the confetti itself is kinda boring, so, I added a timer for extra challenge. You have 3 minutes to find the confetti. Once you find the hidden confetti, the game reveals how long it took you. Share your best time from your first 3 tries in the comments.

And, I added a twist. If you find the confetti fast enough, you unlock special perks. For example, if you manage to beat the game under 1 minute, you will get access to our Discord server, where you can ask any questions from me.

And, if you find it under 30 seconds, you will get a random secret message which you have to type in this video comment. And, I will make a special mention of hardcore players in my next videos. Secret message might look just like a normal comment. So, no cheating or copying from other comments :)

Finally, if you manage to beat it under 10 seconds, well, I won't spoil this one. You'll have to see it for yourself. And, I promise it's NOT a Rickroll xD

For the finishing touch, I added various confetti animations for each perk. I used the Canvas Confetti library for the animations. And, the project is finished.

So, try this game out yourself! Let me know your best time. Good luck!

As always, thanks for reading and I'll see in the next one.

What I learned managing my first open source

Technophile — Mon, 13 Jan 2025 00:16:29 +0000

On December 27, 2024, I announced my open-source project, QuickSnip, on YouTube. First day was very quiet. And then suddenly, views started to increase. More and more people were watching, commenting and subscribing.

5 days in, and we're looking at 15k views with 1000 likes on YouTube and an incredible 200+ stars on GitHub.

So, I decided to share my journey about managing an open-source project with 50+ contributors and over 100 issues and pull requests in these 2 weeks.

That's a lot of things xD

README.md and CONTRIBUTING.md
License
Prettier
Collaborators
CODEOWNERS
FUNDING
Discord Server
Issue Template
Pull Request Template
GitHub Actions
Code of Conduct
VISION
Deployment

README.md and CONTRIBUTING.md

When working on an open-source project, README.md and CONTRIBUTING.md files are often overlooked. But, they're the only way contributors can understand what your project is about and how they can contribute.

These file explain your expectations for the community. Once you establish solid README.md and CONTRIBUTING.md files from the start, it will save you hours when dealing with pull requests. Trust me, this is from experience :)

License

Now, let's talk about legal side of open source. You might have already seen a LICENSE file in pretty much every open-source project, the most common being MIT License. Basically, if a project doesn't have a license, copyright laws kick in automatically. That means others can't use or modify your code, which defeats the whole spirit of encouraging people to use and contribute. That's why always add a license to keep things simple and legal for everyone.

Prettier

Everyone has their own coding style. But, in open-source projects, everyone should be on the same page. And, formatting tools like Prettier set a standard for code style.

As soon as pull requests started rolling in, an immediate issue was code formatting. We immediately created an issue for it and resolved it as quickly as possible.

Collaborators

One major lesson I learned is trust. As the project grew, managing it solo became overwhelming. When people were adding snippets to our database, I noticed a few people consistently reviewing others code and giving great feedback. So, I made them collaborators.

Now, our collaborators help merge pull requests, review issues, and keep things running. I just show them the path and let them lead. If you’re serious about scaling, learn to trust your community.

And, for personal public repo, like ours, only way to allow your trusted contributors to merge or reject pull requests is through giving them a collaborator role.

However, you are not able to assign roles or manage access for collaborators, which I learnt, is possible in organization repo - something we may consider to switch to at some point as we grow.

CODEOWNERS

When there's a pull request, it was difficult to know what was it about unless one of our collaborators reviewed it themselves. And, managing hundreds of them can be overwhelming.

After some research, I found that CODEOWNERS was a thing. Basically, it will let you assign specific contributors to different parts of your project. For example, we have 3 types of maintainers:

Global maintainers, who are responsible for the full scope of the project.
Code maintainers, who take care of bugs and new features.
And, last but not least, snippet maintainers, who review snippet-related pull requests, and see whether it fits the scope of QuickSnip.

Now, with CODEOWNERS set up, it will automatically notifies the right maintainers when there's a pull request with a change on their assigned folders.

But, remember: maintainers need to have write access, so you need to make them collaborators first.

FUNDING

I was wondering how some repos had a sponsor button. After digging the settings for a while, I found that you need to create FUNDING.yml file under .github folder, in which you can add your any of your sponsor links. I added my Ko-fi link, and now you can support QuickSnip as well. It's not necessary, but always appreciated. :)

Discord server

As more and more people were suggesting new ideas and feature requests, we needed a better way of communication to discuss those ideas with our maintainers. One of our maintainers suggested Discord. Now, we have a QuickSnip Community server, where we discuss ideas and plans.

There's also GitHub Discussions we were experimenting with. But, more people were liking and joining Discord server. So, sorry GitHub Discussions.

Issue template

In open-source projects, it's easy to get lost in issues when you have to differentiate what is a bug, feature request or something unrelated.

So, I visited other open-source projects to get an idea on how they are managing their issues. And, I came across Developer Quiz Site from FreeCodeCamp. When I tried to create an issue and I saw this: 4 options to choose from:

Bug report
Documentation
Feature request
And, general

It was very clean and organized. After taking some inspirations, I implemented them in our own project.

Pull Request template

Now, PRs were next.

In our project, some pull requests didn't follow style guide or sometimes had no descriptions. It made it difficult for our maintainers to review the PRs.

And, to my luck, there were pull request templates as well. Thank you, GitHub. First, I gathered feedback from our maintainers what they would like to add in pull request template so it can save their time. Then, I created one. It contains the type of change, an important checklist, related issues and additional info.

Now, every PR is clear and consistent.

GitHub Actions

GitHub Actions feels like magic, but in reality, it's a really cool feature. QuickSnip now stores snippets as markdown files, but the frontend uses JSON to show them in the website. Manually converting markdown to JSON? No thanks.

We wrote a script in GitHub Actions and automated it. Now, whenever someone adds a new snippet, it converts the files automatically. I’ll talk more about this in my next video. Stay tuned!

Code of Conduct

Code of Conduct is often misunderstood on what it actually means. I’ll admit — I thought Code of Conduct was about style guides at first. Turns out, it’s a set of rules people should follow to create a welcoming environment.

Our community has been fantastic so far, and as we grow, a Code of Conduct will ensure we're always friendly and kind to each other.

VISION

As the project started to gain traction (which is awesome), a lot of ideas and feature requests began pouring in (which is even more awesome). But, the problem was it was easy to lose focus. We realized it was important to set the boundaries and understand the scope and future of QuickSnip.

Inspired from this article on contributing.md website, we created a file, called VISION.md, which outlines the goals, roadmap and the future of QuickSnip. While it outlines the current vision for QuickSnip, our proposed future plans may evolve based on community feedback and contributions. So, stay tuned for future updates! ;)

The main purpose of VISION.md file is stay focused on your goals. As the article puts it perfectly:

"As a new maintainer, one person narrates how he regrets steering away from his vision in the early stages of his project when he got his first feature request. He appreciates that a clear vision has kept him focused and helped him prioritize important requests."

Deployment

QuickSnip is hosted on Netlify, and here’s a surprise I didn’t see coming: build minutes.

Since the project is on Free plan, there's limit on build minutes, which is 300. Basically, it's about how many minutes it takes from loading your dependencies (all the code stuff) to deploying them to the site.

And, according to Netlify, each build takes around 2 minutes.

I didn't know about build minutes until I got an email notification from Netlify saying I had reached over 50% of build minutes. That is when I started to take action. I assume, what was happening was that Netlify was also counting build minutes for every PR request since it had to show deploy previews before PR is merged. So, I had to disable deploy previews.

Luckily, thanks to Netlify, build minutes are reset every month. I was so excited to find out about this. In our project, build minutes will reset on January 17, just one day after my birthday.

Outro

These past two weeks taught me more than an entire year. So, here's a small tip from my side:

Open-source is challenging, rewarding, and full of surprises. If you haven’t started an open-source project yet—do it now. You’ll grow, learn, and connect with amazing people.

As always, thanks for reading and I will see you in the next one.

I built a library of code snippets for developers

Technophile — Fri, 27 Dec 2024 14:04:36 +0000

This article is more like a coding journey/journal, where I explain the "behind the scenes" and explain my thought process. If you prefer visual version, I've also made a video of it:

Idea

I've been writing code for over three years now, and one thing that takes up most of my time is repetitive code. As programmers, we don't like repetitive work, especially, writing the same code over and over again. So, I thought why not store all these repetitive pieces of code in one place? Somewhere I could just copy and paste from whenever I needed.

This idea was brewing in my head for a while. I also remembered sharing JavaScript utility functions on DEV Community a while ago. And, people loved them and were making suggestions to improve them as well.

And, I thought what if these code snippets were stored in one organized, easy-to-access place, and what if it was driven by the community itself?

And, the idea for QuickSnip was born...

Design

Before jumping into the project, I wanted to make sure I had a clear vision. So, I sat down with ChatGPT to brainstorm ideas for the project name, logo, and architecture. After gathering all the details, I hopped onto Figma to sketch out the wireframe.

By the way, I took some inspirations from Stack Sorted. So, shout-out to them.

After a few days, design was ready, and it was time to move on to the fun part: coding.

Coding

I decided to go with React, TypeScript, and Vite. Frontend took around a week to get everything in place.

Then came the backend. I wanted to use a routing system inspired by Stack Sorted.. Since it was a single-page application, I ran into several issues with routing. But after a lot of trial and error, I managed to get it working.

However, after a week-long break and revisiting the code, I knew that the code was impossible to understand, not to mention maintaining it in the future. So, just like a normal programmer, instead of refactoring, I decided to scrap it all and start over.

This time, I simplified the architecture and used Context API for state management. It’s not the cleanest code ever, but hey, if it works, it works!

For syntax highlighting, I chose React Syntax Highlighter powered by Prism.JS because it was super simple and easy to integrate.

Now, for storing the code snippets, I took inspiration from other open-source projects and decided to use a local database, so others can add their own snippets easily. The snippets are stored in JSON files under the /public/data folder. Each programming language has its own file, and within each file, snippets are grouped into categories.

Here’s an example of how it’s structured:

{
  "title": "Name of the snippet",
  "description": "A short explanation of what the snippet does",
  "code": [
    "your code goes here",
    "  this is a newline with a space"
  ],
  "tags": ["tag1", "tag2", "tag3"],
  "author": "your_github_username"
}

For code part, initially, I used single-line string to store the snippet code. It was compact but at a cost of readability.

After some back-and-forth with ChatGPT, I realized I could use arrays instead. That made the code so much easier to inspect and understand.

// before
{
  "code": "def reverse_string(s):\n   return s[::-1]"
}

// after
{
  "code": [
    "def reverse_string(s):",
    "    return s[::-1]"
  ]
}

After many more UI adjustments and hours spent cleaning up the code, QuickSnip was finally coming together.

Documentation

But, there was something missing. For every open source project, there should be a clear documentation to help contributors understand what your project is about and how they can contribute.

I wasn’t very experienced with managing open-source project, but by some chance, if you type contributing.md into your browser, it will take you directly to an awesome guide to help you get started with open-source projects.

After some research, I managed to create beginner-friendly guides in both README.md and CONTRIBUTING.md files.

QuickSnip is now live on Netlify! You can check it out at quicksnip.netlify.app. Why not .com? Because, well, I’m broke right now. But hey, if this video gets 50 likes, I’ll buy a custom domain!

I also launched QuickSnip on Product Hunt. It’s my first time launching a project there. So, now, you can leave a review there as well.

How to contribute

Speaking of contribution, you can either help by:

Adding new snippets or
Improving the code.

I have written easy-to-understand explanation in CONTRIBUTING.md on how to contribute to this project, along with adding snippets, categories and languages.

Remember: whether you're fixing a tiny typo, found a bug or have a feature request, every bit means a lot. Thank you! :)

Future plans

After weeks of coding and debugging, I can now proudly check off this mark.

Wait... there are still more.

Ok. Let's talk about future plans.

For now, the search functionality isn’t working yet. I’ve been looking into Algolia as a solution and I am planning to implement it soon. So, stay tuned!

I will keep adding more features based on your feedback and suggestions to hopefully make our coding journey easier and more enjoyable.

Final Thoughts

To wrap it up. here's a question: Do you have a favorite code snippet that you use all the time? One that you think every developer could benefit from? If so, now’s your chance to share it with the world.

As always, thanks for reading and I'll see you in the next one.

I built a Sass template. You can just copy me!

Technophile — Thu, 19 Dec 2024 18:59:20 +0000

The last Sass template I made was over 2 years ago. I decided to share it with the internet and it ended up getting 35k views.

A lot has changed since then. So, I decided to rework it and share it with more people.

This is currently my latest Sass folder structure that I use for pretty much every project, except for minor variations in files.

How to download and use it

To use this template in your project, you can either click on Use this template on GitHub. Or you can just download the sass folder and include it in your current project and start using it.

Architecture

Ok, let's get back to the folders. There are 6 folders and 1 main style.scss file.

`abstracts` folder

Starting with the 1st folder: abstracts. This folder is only used for Sass-related things. And, nothing from this folder gets compiled into CSS.

This is a place where you write all your variables, mixins, functions, placeholders, maps and etc.

`base` folder

Next up, base folder. This folder contains base or generic styles for your project.

This is where I put my reset styles, custom properties and global styles that are not specific to any element.

Also, I don't change any files in both abstracts and base folder since the architecture is usually the same in most of my projects.

`components` folder

components folder. As the name suggests, this folder holds all the styles for specific components used in the project. This can include buttons, cards, drop down, input fields and so on.

This folder usually gets big if you have many reusable components in your website.

`layouts` folder

And, unlike components folder, layouts folder contains 1 level higher styles that are used define the structure of your website. This can be things like header, footer or sidebar of your website.

`pages` folder

Moving on, pages folder contains page-specific styles that don’t apply globally.

For example, we can't put header in pages folder, since it's used in every page, but we CAN put the "Teams" section styles in our _about.scss file. Also, we can put the article related styles in our _blog.scss file. Because they're only used or at least make sense in those pages.

`utilities` folder

Similar to components folder, utilities folder holds specific styles for our project. But, what's the difference?

Let's take a text example. Let's say, there's a class name, called .text-highlight. When used in a project, its only purpose is to highlight the text, and not interfere with other text styles. But, you may say, so does the components folder. In components folder, styles are often encapsulated or a separate unit, like a button, cards or input fields. But, in utilities folder, it's not a separate unit, it's changing the existing element. As we saw with .text-highlight, it's not a separate thing on its own, like button, but rather changing the existing text to a different style.

Another good example would be .container class. I can use the .container class anywhere in HTML, and it wraps that element and sets a width to it. In other words, It does one thing and does it well.

Also, we have a file, called _shame.scss. This is a concept I learned from "Sass Guidelines". Basically, if you feel like, the style you wrote doesn't belong any file or folder, you should put them in _shame.scss. We put this file at the very end of our stylesheet, which we can use it for debugging purposes as well.

Also, this is an only file where you can freely use !important or an id selector, and go wild with them. But, make sure to sort and filter them out once you have found a good solution to your problem.

`_index.scss` file

You have might already noticed that each folder has a file, called _index.scss. This is because of @use and @forward.

In old Sass, we used to import files with @import, but, now we have a modern solution: @use which is created to replace the old @import.

Also, it comes with some other cool features, which you can read here.

If we look at the _index.scss files, we can see that there are only @forwards which we will use to export the files within the folder. By doing this, I can import the whole folder at once, instead of importing each file individually.

And, in our main style.scss, we import the files with @use method.

If you want use a variable or mixin from your abstracts folder into your _button.scss file, you can import it by writing

@use "../abstracts" as *;

Often times, you will only need to import your abstracts folder. That means, this line never changes, so whenever you need to use anything from your abstracts folder, just copy and paste this line and you're good to go.

Fun fact: I've also used @use and @forward in my first sass template 2 years ago.

`style.scss` file

Last, but not least, our main style.scss file, where everything gets merged into one place. And, the order they are merged is also important since it defines which style should override the other.

I made this diagram to show how files should be ordered. Feel free to inspect it on GitHub.

Outro

And, that's it. This folder structure was and is heavily inspired by the 7-1 pattern in Sass Guidelines as well as Kevin Powell's video on Sass. So, shoutout to them.

This was the start of "I built something" series where I share my interesting & cool projects, and explain my thought process behind it.

As always, thanks for reading. And, I will see you in the next one. :)

5 Good CSS Habits - Explained with a Real Project

Technophile — Tue, 03 Dec 2024 13:56:12 +0000

We will cover topics ranging from naming selectors, organizing your code to specificity and which units to pick. I divided this guide into 5 habits that are important for every developer learning or improving their CSS.

Habit #1: Consistent naming
Habit #2: Use CSS variables
Habit #3: Comment and organize
Habit #4: Always use classes
Habit #5: Use appropriate unit

Habit #1: Consistent naming

Can you look at the following selectors in CSS, and answer these 3 questions:

WHAT do they do?
WHERE can they be used?
and are they RELATED to each other?

We know that .title class is used to style the title, but, it doesn't tell us whether it's the main title of the website or the title of some article. And, we don't know if it's related to .card element at all.

And, it's same issue with the other classes, too. Without looking at the HTML code, we can't answer those 3 questions.

Just like other programming languages, CSS has adopted its own naming rules that developers should follow.

These include the following:

Names should be written in lowercase
Separate the words with hyphens (-)
Don't use camelCase, under_score or other naming conventions.
And, here's my personal take: don't use abbreviations unless they're commonly used among developers. like bg for background.

And, still, these are not enough to answer those 3 questions, especially when your project starts to grow.

Then, what is that secret sauce?

It's BEM, the most popular naming convention in CSS among developers.

Let's look at our previous example and see how we apply this approach.

Looking at the HTML first, we can see that they're pricing cards. Each card has a class name, called .card. Inside, there’s a title, price and a list of features.

Let's use the BEM approach and change the .title to .card__title. Now, we know that it belongs to the .card element.

Let's apply the same logic for the other ones, too. Change them from .price to .card__price, and from .features to .card__features.

.card {
  ...
}

.bg-primary {
  ...
}

.card__title {
  ...
}

.big-text {
  ...
}

.card__price {
  ...
}

.card__features {
  ...
}

Output:

But, what if one of the cards is a popular option and has a different background color. In that case, we add a new class name next to the .card, called .card--popular. And, then we can add the different background color to that new class name.

Also, the font size of the price in the popular card is bigger than other ones, so let’s add a new class name to it, called .card__price--big.

HTML code:

As you can see, BEM makes the code so much easier to read. And, most importantly, it answers the 3 fundamental questions:

WHAT does it do?
WHERE could it be used?
and is it RELATED to other elements?

Next time when you are naming selectors, try to cover all these questions.

Also, if you want to dive deeper into BEM, you read this awesome article.

Okay, let's continue.

Habit #2: Use CSS variables

Here’s a question for you. Do you know what color is this?

.class__name {
  background-color: #191970;
}

Well, it’s dark blue. Now, here’s the next question: Is it a primary color, an accent color, or just a random one-off color used in the project?

That’s the problem. Without additional context, like looking at the design file or visiting the website, it’s difficult to know.

Solution?

CSS custom properties (AKA variables)

You might probably have heard the term, DRY (Don't Repeat Yourself) principle. If you find yourself repeating the same values or copy-pasting them across your CSS, you should store them as variables.

Let’s take our color example, and refactor it using variables. A good starting point is naming the variable by the color itself. In our case, it could be:

:root {
  --darkblue: #191970;
}

.class__name {
  background-color: var(--darkblue);
}

Now that we used this variable, there's a potential problem here. What happens if the color itself changes to red or green? Suddenly, the name --darkblue doesn’t make sense anymore.

To solve this, avoid naming variables based on their literal value. Instead, name them according to their purpose. For example, if this color is the primary color of our project, we can name the variable --primary-color:

:root {
  --primary-color: #191970;
}

.card--popular {
  background-color: var(--primary-color);
  ....
}

button {
  background-color: var(--primary-color);
  ....
}

Now, even if the color changes to green or any other color, variable name still makes sense.

Bonus tip: You can also use variables to store some random or complicated value. It will give a better context on what it is.

/* bad */
.element {
  transition: all 0.3s cubic-bezier(0.25, 0.1, 0.25, 1);
}

/* good */
:root {
  --ease-out: cubic-bezier(0.25, 0.1, 0.25, 1);
}

.element {
  transition: all 0.3s var(--ease-out);
}

Habit #3: Comment and organize

Writing comments... Either you like it or hate it.

But, comments in CSS are not just for giving explanations, they can also be used to organize and structure your code.

But, before that let’s first start with the intended use case: adding explanations.

Take a look the following code. Without the comments, can you tell me what it does?

.auto-grid {
  display: grid;
  gap: 1rem;
  grid-template-columns: repeat(auto-fit, minmax(min(22rem, 100%), 1fr));
}

How about now?

/* this is for auto-grid, lol */
.auto-grid {
  display: grid;
  gap: 1rem;
  grid-template-columns: repeat(auto-fit, minmax(min(22rem, 100%), 1fr));
}

Just kidding, but seriously, how about now?

/** 
 * Responsive gird that adjusts columns automatically
 * Each item has a minimum width of 22rem and a maximum of 100%
 **/
.auto-grid {
  display: grid;
  gap: 1rem;
  grid-template-columns: repeat(auto-fit, minmax(min(22rem, 100%), 1fr));
}

I know that we all hate writing comments in our code. But, if it's the only thing you can understand, try to give at least some explanations. Trust me, otherwise, you will forget it eventually.

You can ask ChatGPT to give a short and clean comment on how your code works.

Now let’s move to the second use case: organizing and grouping your code with comments.

If you're working with a single CSS file, you might already know that it gets messy real quick. And, it becomes a nightmare especially when you're trying to find that one selector. So, grouping similar or related blocks makes your file and life much easier.

Let's take our previous example, and apply this approach.

In our case, we can separate the global styles and group them in one place, ideally at the top of our file. (I will explain later why) Next, we can separate some of the components that we used in our project and group them together. Now, finally, our main cards. Since, we organized them by their name, we can now easily group them into one place and make it easy to separate from the rest of the code.

If you're not sure about how to actually structure your CSS, you can use the 7-1 approach (https://sass-guidelin.es/#the-7-1-pattern) to understand where each piece of your code belongs to. Although it's designed for Sass folders, you can apply the architecture itself into your single CSS file.

/*------------------------------------*\
  #GLOBAL
\*------------------------------------*/
*,
*::before,
*::after {
  ....
}

body {
  ....
}

h1,
h2,
h3,
p,
ul,
li {
  ....
}

/*------------------------------------*\
  #COMPONENTS
\*------------------------------------*/
button {
  ....
}

button:active {
  ....
}

/*------------------------------------*\
  #CARDS
\*------------------------------------*/
.cards {
  ....
}

.card {
  ....
}

.card--popular {
  ....
}

.card__title {
  ....
}

.card__price {
  ....
}

.card__price--big {
  ....
}

.card__features {
  ....
}

.card__features li::before {
  ....
}

Also, when you're separating the blocks, make it easy for your eyes to spot them. I use this commenting approach by Harry Roberts in his CSS Guidelines. And, they look clean, too.

/*------------------------------------*\
  #FOO
\*------------------------------------*/

Habit #4: Always use classes

Don’t use HTML elements as selectors, like h1, p, and button. You're only allowed to use them when you are applying global styles. But, if it’s something specific, always use classes. Even if it feels like extra step, you will thank yourself in the future.

/* bad */
button { .... }

button:active { .... }


/* good */
.button { .... }

.button:active { .... }

And, speaking of HTML elements, don’t use ID selectors. You might have already heard the term “specificity”. If you haven’t, basically, every selector has its own specificity or “importance” score. You can view it in VS Code by hovering over the selector. The higher the score, the more “important” it is, which means it becomes much difficult to override its style with other lower scored selectors.

You might think it’s a good thing. But, it’s not often the case. If you look at habit #3, we put the general styles at the top of the file. And, components, utilities and other specific styles are placed at the bottom. It’s because general styles are later overridden by specific styles.

/* lose */
.card {
  background-color: red;
}

/* win */
.card {
  background-color: blue;
}

In CSS, whichever style is applied last will be used. And, in our case, if we use an ID selector somewhere in CSS, and later down the page, try to override its style with a class name, it doesn’t work, because the “specificity” of an id selector is higher than of a class selector.

/* win */
#card {
  background-color: red;
}

/* many lines later... */

/* lose */
.card {
  background-color: blue;
}

Also, !important falls in the same category. Don’t use it unless absolutely necessary, such as for debugging why your style is not being applied to your element.

.card {
  border: 1px solid red !important; /* only for testing */ 
}

On a similar note, don’t nest or chain selectors. It also increases the specificity score and makes it harder to maintain. Instead give it a separate class name. If you are unsure about what to name it, refer to habit #1.

/* bad */
.card__features li::before {
  ....
}


/* good */
.card__feature::before {
  ....
}

Habit #5: Use appropriate unit

If you’re only using pixels (px) in your CSS, either you’re a beginner or living under the rock. Because you are missing out on so many cool features that other units can offer. And, it’s important to understand where to use them effectively.

Here’s my general approach on using units in CSS for different cases:

For font sizes

Use rem. Because it's proven to work better than other units, including px. You can read it here, here and here.

For width and height

It's quite tricky.

If it is really specific number, use rem.
But, if it is not the case, you can use %, because they work really well most of the time.
vw and vh can be also good depending on the use case. But, I often face overflow issue with them. So, be careful.
But, if you're controlling the width of a paragraph or text, ch is often a good option. It stands for characters, which means you can specify how many characters you want per line.

For paddings, margins and gaps

If you want consistent output that doesn't change and fail, use rem.
If you want them to change based on font size, em works really well. em unit depends on the font size of the nearby content. You can leverage it to create responsive spacing with fluid font sizes as well.

For other cases

If you are dealing with very small sizes, like 4px or 8px where the difference is not that noticeable, you can use px. Because 0.125rem or 0.375rem might be difficult to understand at first sight compared to 2px or 6px.

All these units can be overwhelming especially if you want consistent approach in your CSS. But, learning to adopt to different solutions can be a game changer when you understand where to use them.

Outro

And, that's pretty much it. Hope you find this article helpful. If you ever struggle with how to write CSS, you can always come back to this article.

And, of course, there are so many ways of writing CSS, and only limit is your imagination.

Thanks to all developers and their awesome articles. I just gathered them all from years of learning into one hopefully useful article for you.

And, as always, thanks for reading and I’ll see you in the next one.

I Found The CLEANEST Loading Animation EVER!

Technophile — Wed, 20 Nov 2024 20:55:02 +0000

I recently noticed that Netlify has the most minimalist loading animation I have ever seen. So, I decided to build it myself and share it with you.

Looking at the loading animation in Netlify website, we can see that it uses 4 characters (|, /, -, and \) to create the illusion of spinning effect.

That means, we can store the characters in array and repeatedly cycle through each one of them. We also need to find the perfect sweet point for our animation timing and speed create that cool spinning effect.

Ok, let's get started.

First, let's setup the loader in HTML. It's just a div with an id of "loader":

<div id="loader"></div>

Now, with CSS, let's center it in the screen and increase the size:

body {
  display: grid;
  min-height: 100vh;
  place-items: center;
  margin: 0;
  font-size: 5rem;
}

Done. Now onto JavaScript.

First, let's get the loader element from HTML and store it in a variable. We also need to create an array to store the 4 characters for our animation. I'm using letters here to see the animation difference better.

const loader = document.getElementById("loader");
const characters = ["a", "b", "c", "d"];

Now, whenever you need to animate something in JavaScript, you can use this thing called requestAnimationFrame(). Basically, it tells the browser that we want to perform an animation. I will explain how.

Let's create a function, called animate(). Inside, we run the requestAnimationFrame() and pass animate itself as an argument. And, finally, let's call the animate() function itself at the end. Because requestAnimationFrame() runs only once, with this technique we create an infinite loop.

const animate = () => {
  requestAnimationFrame(animate);
};

animate();

Right now, nothing seems to be happening. But, animate() function is continuously running in the background.

Now, to see it, let's create a variable, called frame, set it to 0, and increment it every time animate() function runs.

If we console.log it, we can see the number incrementing. It's quite fast!

let frame = 0;

const animate = () => {
  console.log(frame);

  frame++;
  requestAnimationFrame(animate);
};

animate();

Now, let's update our loader to show each character as animate() function runs.

const loader = document.getElementById("loader");
const characters = ["a", "b", "c", "d"];
let frame = 0;

const animate = () => {
  loader.innerHTML = characters[frame % 3];

  frame++;
  requestAnimationFrame(animate);
};

Here, I'm using % sign (also known as modulo operator) to cycle through the array elements. I'm using 3, since the last index of the array is 3. That way, we always stay within the array.

Looking at the output, it's working but a little too fast.

Do you remember, when we console.loged the frame variable, it was incrementing so fast? Basically, what is happening is that we're changing the loader character every frame. If, let's say, we manage to update it every 10 frame or 20 frame, it would slow down the animation speed.

const loader = document.getElementById("loader");
const characters = ["a", "b", "c", "d"];
let frame = 0;

const animate = () => {
  if (frame % 10 === 0) {
    loader.innerHTML = characters[frame % 3];
  }

  frame++;
  requestAnimationFrame(animate);
};

animate();

Now, there'e an issue with our code. Because we're updating every 10 frames (10, 20, 30 and etc), characters[frame % 3] no longer cycles the array correctly.

So, I found a easier and better approach to solve this.

Let's create a separate variable, called index that track which character we're showing. And, if the index gets bigger than our array length, we reset it to 0.

const loader = document.getElementById("loader");
const characters = ["a", "b", "c", "d"];
let frame = 0;
let index = 0;

const animate = () => {
  if (frame % 10 === 0) {
    if (index >= characters.length) index = 0;
    loader.innerHTML = characters[index];
    index++;
  }

  frame++;
  requestAnimationFrame(animate);
};

animate();

Now, we can freely chose when to update the content, and not worry about characters not showing up correctly.

Try different frame intervals to control the speed - higher values slow down the animation and lower values speed it up.

Now, if we change the letters back to characters, we get the same result as we saw with Netlify example.

const loader = document.getElementById("loader");
const characters = ["|", "/", "-", "\\"];
let frame = 0;
let index = 0;

const animate = () => {
  if (frame % 10 === 0) {
    if (index >= characters.length) index = 0;
    loader.innerHTML = characters[index];
    index++;
  }

  frame++;
  requestAnimationFrame(animate);
};

animate();

And, that's it. Hope you learned something new.

As always, thanks for reading and I'll see you in the next one.

3 Tricks to Make Your Fonts Responsive

Technophile — Fri, 08 Nov 2024 00:30:03 +0000

Responsive fonts…

As text plays a big role in websites, you want to make sure that it looks great for everyone no matter what device they use. And, it gets tricky as there are so many screen sizes to worry about.

Let’s first take a look at some examples of UN-responsive fonts to understand why it matters. Some developers use desktop-first approach when building websites, while others use mobile-first.

But, sometimes, when working with desktop-first approach, the text size is often ignored, because they look normal on computers. But, when you open it on your phone, it looks like this...

I will show you 3 methods of solving this issue. I divided them into 3 levels:

Easy
Medium
Hardcore

1. Easy - change fonts based on viewport

Let’s start with easy one.

It’s not actually easy and can get tricky if you’re new to media queries. Basically, we first declare our variables in CSS, because we can use them later in our code. Next, let’s name our variables and set values.

:root {
  --font-sm: 0.875rem;
  --font-md: 1rem;
  --font-lg: 1.25rem;
  --font-xl: 1.75rem;
  --font-2xl: 2.5rem;
  --font-3xl: 4rem;
}

And, yes, rem is better than px. You can read it here.

Okay, we finished with our base font sizes. Let’s see how it looks. Let me set it up real quick…

body {
  font-size: var(--font-md);
}

h1 {
  font-size: var(--font-3xl);
}

h2 {
  font-size: var(--font-2xl);
}

h3 {
  font-size: var(--font-xl);
}

h4 {
  font-size: var(--font-lg);
}

It’s not responsive yet. I want the text size to change when it reaches a certain viewport. Let’s say 600px. Past the value, text looks too big on phones. Thus, we use media query to change the values of our variables we set up earlier.

@media (width < 600px) {
  :root {
    --font-sm: 0.875rem;
    --font-md: 1rem;
    --font-lg: 1.25rem;
    --font-xl: 1.5rem;
    --font-2xl: 2rem;
    --font-3xl: 3rem;
  }
}

For this time, we want the values to be smaller than original because we are working on mobile device.

As you can see, it rather snaps to the different value, doesn’t flow smoothly, because we set it up that way.

You can use it as a foundation for your projects, so they don’t end up looking huge overflowing text.

2. Medium - use type scale calculators

Easy, but difficult to comprehend one. You can use type calculators, like Utopia.fyi to generate the best responsive font sizes for you.

We first set the minimum and maximum font size for our base font, like paragraph. And, we have to set the type scale ratio. The calculator generates the font sizes based on these values.

/* @link https://utopia.fyi/type/calculator?c=320,16,1.2,1240,18,1.25,5,2,&s=0.75|0.5|0.25,1.5|2|3|4|6,s-l&g=s,l,xl,12 */

:root {
  --step--2: clamp(0.6944rem, 0.6856rem + 0.0444vw, 0.72rem);
  --step--1: clamp(0.8333rem, 0.8101rem + 0.1159vw, 0.9rem);
  --step-0: clamp(1rem, 0.9565rem + 0.2174vw, 1.125rem);
  --step-1: clamp(1.2rem, 1.1283rem + 0.3587vw, 1.4063rem);
  --step-2: clamp(1.44rem, 1.3295rem + 0.5527vw, 1.7578rem);
  --step-3: clamp(1.728rem, 1.5648rem + 0.8161vw, 2.1973rem);
  --step-4: clamp(2.0736rem, 1.8395rem + 1.1704vw, 2.7466rem);
  --step-5: clamp(2.4883rem, 2.1597rem + 1.6433vw, 3.4332rem);
}

As you can see, it uses clamp() to generate responsive font sizes. Just copy the values, and paste them into your CSS. Change the names of variables. And, you are good to go.

3. Hardcore - write your own type scale calculator

If you really want to have full control of your responsive fonts, you can build your own type scale calculator. Although I usually use Utopia.fyi for most of my projects, here’s how I would implement it without these tools.

@use "sass:math";

$font-scale: 1.25;
$font-min: 0.875rem;
$font-base: 1rem;
$font-max: 1.125rem;

$font-sizes: (
  "xs": -2,
  "sm": -1,
  "md": 0,
  "lg": 1,
  "xl": 2,
  "2xl": 3,
  "3xl": 4
);

:root {
  @each $label, $value in $font-sizes {
    $min-size: $font-min * math.pow($font-scale, $value);
    $base-size: $font-base * math.pow($font-scale, $value);
    $max-size: $font-max * math.pow($font-scale, $value);

    --font-#{$label}: clamp(
      #{$min-size},
      calc((#{$base-size} * 0.5) + 2vw),
      #{$max-size}
    );
  }
}

I used Sass here to automate the process. Here's the link to Codepen if you want to view it. It’s not the cleanest code in the world. If you have your own approach, please let me know in the comment.

And, there you have it! Hope you learned something new. Let me know which approach you’re going with. As always, thanks for reading, and I’ll see you in the next one! 👋

Fetch Local Files Easily with THIS Technique

Technophile — Wed, 30 Oct 2024 03:02:20 +0000

Hey everyone! Welcome back. In today’s post, I’m going to show you how to fetch a JSON file with JavaScript in two ways: using promises and using async/await. We'll compare both methods and discuss which one might be better for your code.

You can also watch the YouTube video I made:

First, let’s look at the JSON file we want to fetch. It contains simple data about users:

[
  {
    "name": "John",
    "age": 24,
    "city": "New York"
  },
  {
    "name": "Dan",
    "age": 26,
    "city": "London"
  },
  {
    "name": "Mark",
    "age": 25,
    "city": "Berlin"
  }
]

Now, let’s see how we can fetch this data and use it in our javascript file using both approaches. Btw, make sure that files are located in the same folder.

Step 1: Fetching JSON with Promises

Ok, let’s start with promises. We can use the built-in JavaScript fetch() method to retrieve our data:

fetch("./data.json")
  .then((res) => res.json())
  .then((data) => console.log(data))
  .catch((error) => console.error('Error:', error));

In this code:

The fetch() method retrieves the data from provided location, in our case, it is data.json file.
The first .then() method converts the response back to JSON format with res.json() function.
In the next .then() method we handle the JSON data and log it to the console.
Finally, .catch() method handles any errors that occur with fetching the data, such as wrong file location.

Step 2: Fetching JSON with Async/Await

Now let’s see how to do the same thing using async/await.

async function fetchData() {
  try {
    const res = await fetch("./data.json");
    const data = await res.json();
    console.log(data);
  } catch (error) {
    console.error('Error:', error);
  }
}

fetchData();

In this version:

We define an async function called fetchData().
We are using try and catch block to handle any errors, just like catch() method in our previous example.
Inside, we use the await keyword to wait for the fetch request to complete and then converts the response to JSON format, and finally, we receive the data.

Step 3: Which One is Better?

Ok, we now know how to fetch the data. So, what’s the difference between these two approaches?

Promises offers a simple way to work with callbacks, but the syntax can become messy and harder to follow when dealing with multiple asynchronous operations.
While Async/Await reads more like synchronous code, making it easier to debug and maintain, especially in more complex applications.

In general, async/await is the cleaner and more readable approach, and it’s recommended when you’re working with multiple asynchronous actions or want to avoid the callback hell.

Step 4: Solving Cross-Origin Issues

One quick thing to note: If you try to open the HTML file directly into your browser or run nodejs to see the output of your data, you might encounter a Cross-Origin Request Blocked error.

The reason is that they don’t have access to reading your internal files. To fix this, you can either:

Install the Live Server extension in VS Code, so that it runs your project on a local server. (and, it’s much easier when testing locally)

The result:

Or deploy your project to a platform like GitHub Pages or Netlify, which we’ll quickly cover now.

Step 5: Deploying the Project to GitHub Pages

Once your project is working locally, you can now deploy it using GitHub Pages.

Push your project to GitHub.
In your repository, go to Settings > Pages.
Select the branch and folder to publish your site.

Once your site is live, you should be good to go.

And there you have it! You now know how to fetch JSON using both promises and async/await.

5 Websites You NEED As a Frontend Developer

Technophile — Wed, 23 Oct 2024 05:40:20 +0000

Hello everyone! Today, I’ve got 5 websites that every frontend developer, and even other programmers, should know about. These are the sites I personally use everyday, and I think you’ll love them too. So, let’s dive in!

By the way, if you're a visual reader, you can also watch the YouTube video I made.

1. MDN Web Docs

🔗 Link: https://developer.mozilla.org/en-US/

Let’s start with MDN Web Docs. I think for frontend developers, MDN Web Docs is one of the best resources out there in terms of documentation.

MDN covers basically pretty much everything in web technologies, including HTML, CSS, and JavaScript.

💡 Fun Fact: Even VS Code uses MDN as a reference for code suggestions.

Oh, btw, Do you know what does MDN stand for? It’s the Mozilla Developer Network. Yep, the same company that created the Firefox browser. 🦊

2. Carbon

🔗 Link: https://carbon.now.sh/

Now, we’ve covered the documentation, let’s talk about writing beautiful code. Ever wanted to share a piece of code you’re proud of on a social media or your blog, but it looks ugly? Don’t worry! Because Carbon is here to fix it. 🎨

Carbon lets generate beautiful images of your code. In this website, you can tweak pretty much everything - the theme, background, font, spacing and etc.

It’s a great tool to make your code look shiny on social media.

3. CanIUse.com

🔗 Link: https://caniuse.com/

Ever come across a new CSS feature, only to find out that it works on your computer, but not your phone or vice verse. This is where caniuse.com can be very useful. Basically, it helps you check what browsers support this new feature. 🔍

I remember waiting for ages for the full support for Flexbox’s gap property and now it’s supported in almost 95% of browsers.

Next time, you see a new feature, always make sure to check it in this website before using it in your projects.

4. Realtime Colors

🔗 Link: https://www.realtimecolors.com/

Now, let’s talk about design. Before starting a new project, it’s important to choose colors carefully. Otherwise, it can ruin the user experience. With Realtime Colors, you can visualize color palettes in real-time and see how they’d look on a website. 🎨

You can either choose a color palette you have in mind or just keep pressing the Spacebar until you find the one you like. Once done, you can copy the colors or download it into your computer. Definitely a great tool!

5. Favicon.io

🔗 Link: https://favicon.io/

Last but not least, let’s not forget about little details—like your site’s favicon! You know, that tiny logo that appears in the browser tab. With Favicon.io, you can generate those tiny logos from simple text, an image, or even an emoji. It’s quick, easy, and a great way to personalize your website. 👨🏻‍💻

And there you have it. If you have other websites you use on a daily basis, feel free to write them in the comments. Who knows, I might make a video/post about them in the future! 💬

Forem: Technophile

How I make my site searchable in 2 minutes

Basic SEO

Advanced SEO

Video format

5 Killer Project Ideas for Developers in 2025

TL;DR

Automated Roadmap Generator

Leaderboard for Open Source Projects

Live Coding Interview Platform

Real-Time Multiplayer Quiz Game

Personalized Code Snippet Organizer

We made QuickSnip even better (v1)

Excitement

Changes

Future plans

I Built a Game for My 1000 Subscribers

Design

Coding

What I learned managing my first open source

Table of Contents

README.md and CONTRIBUTING.md

License

Prettier

Collaborators

CODEOWNERS

FUNDING

Discord server

Issue template

Pull Request template

GitHub Actions

Code of Conduct

VISION

Deployment

Outro

I built a library of code snippets for developers

Idea

Design

Coding

Documentation

How to contribute

Future plans

Final Thoughts

I built a Sass template. You can just copy me!

How to download and use it

Architecture

abstracts folder

base folder

components folder

layouts folder

pages folder

utilities folder

_index.scss file

style.scss file

Outro

5 Good CSS Habits - Explained with a Real Project

Table of Contents

Habit #1: Consistent naming

Habit #2: Use CSS variables

Habit #3: Comment and organize

Habit #4: Always use classes

Habit #5: Use appropriate unit

For font sizes

For width and height

For paddings, margins and gaps

For other cases

Outro

I Found The CLEANEST Loading Animation EVER!

3 Tricks to Make Your Fonts Responsive

1. Easy - change fonts based on viewport

2. Medium - use type scale calculators

3. Hardcore - write your own type scale calculator

Fetch Local Files Easily with THIS Technique

Step 1: Fetching JSON with Promises

Step 2: Fetching JSON with Async/Await

Step 3: Which One is Better?

Step 4: Solving Cross-Origin Issues

Step 5: Deploying the Project to GitHub Pages

5 Websites You NEED As a Frontend Developer

1. MDN Web Docs

`abstracts` folder

`base` folder

`components` folder

`layouts` folder

`pages` folder

`utilities` folder

`_index.scss` file

`style.scss` file