DEV Community: Eren

is CSS the New Sass? Here’s What You Need to Know in 2025

Eren — Fri, 14 Feb 2025 22:04:05 +0000

At the start of 2024, I wrote about how Native CSS had evolved significantly, reducing the need for Sass dependency and showing how class naming conventions — used meaningfully and reusable — could maximize our CSS efficiency.

I’ve been a longtime Sass user, but in 2024 I decided to stop using Sass entirely, and none of my projects that year included Sass.

So, do I regret it?

Before answering, let’s take a look at what changed in the CSS world by 2025.

Variables (CSS Custom Properties)

Sass variables are resolved at compile-time, while CSS custom properties can be updated at runtime in the browser. That makes them far more flexible for scenarios like theming or dark mode, where you need values to change dynamically.

2024 : %95+ browser support
2025: %99+ browser support

// ------------ SCSS ----------- //
$primary-color: #3888ff;
.button {
  background-color: $primary-color;
}

/* ------------ CSS ------------ */
:root {
  --primary-color: #3888ff;
}
.button {
  background-color: var(--primary-color);
}

Nesting

One of Sass’s most famous advantages — nesting — is now almost fully supported in CSS as well, which significantly reduces the need for Sass. That said, Firefox may require a few phased updates, so we might only see near-complete support by the latter half of 2025.

2024 : %88+ browser support
2025: %92+ browser support

// ------------ SCSS ----------- //
nav {
  ul {
    list-style: none;

    li {
      display: inline-block;
    }
  }
}

/* ------------ CSS ------------ */
nav {
  & ul {
    list-style: none;

    & li {
      display: inline-block;
    }
  }
}

Partials — Modules

In SCSS, you can create separate .scss files for specific areas (e.g., _input.scss for form elements) and import them into a main file, such as _form.scss. This modular approach helps you manage styles in one place.

On the CSS side, it’s also possible to split a project into multiple files. We used to rely on @import, though that’s not recommended anymore because it triggers extra HTTP requests. Modern bundlers (Webpack, Vite, etc.) typically combine all CSS into one final output. So effectively, “splitting files and reassembling them” is just as feasible with CSS.

2024 : %97+ browser support
2025: %99+ browser support (basic @import usage)

// ------------ SCSS ----------- //
// _buttons.scss
.button {
  padding: 1rem;
  border-radius: 4px;
}
// main.scss
@import 'buttons';

/* ------------ CSS ------------ */
/* main.css */
@import url('buttons.css');

/* buttons.css */
.button {
  padding: 1rem;
  border-radius: 4px;
}

Operators (Calculation Functions)

In SCSS, you can perform basic arithmetic operations. Native CSS offers a variety of calculation functions, such as calc(), var(), clamp(), min(), and max(). For layout, we even have fit-content() and repeat().

2024 : %96+ tarayıcı desteği
2025: %98+ tarayıcı desteği

/* ------------ CSS ------------ */
.container {
  width: calc((100% - 20px) / 2);
}

New Native CSS Features

Container queries
Also called “CSS Container,” container queries let you style elements based on the dimensions of their parent container, which is a huge step forward for modular, reusable components.

2025: %94+ browser support

/* ------------ CSS ------------ */
.container {
  container-type: inline-size;
  container-name: card;
}

@container card (max-width: 400px) {
  .text {
    font-size: 1rem;
  }
}

@scope (CSS Scope)
@scope is aimed at ensuring that your styles only affect specific elements or a subsection of the DOM. It’s still quite new; even by 2025, full support hasn’t been reached. In the near future, though, @scope will make component-level styling a breeze.

2025: %88+ browser support

/* ------------ CSS ------------ */
@scope (.card) {
  .title {
    color: blue;
  }
}

:is() , :where() , :has()

We already covered this in a previous video. :is() and :where() were widely supported even back in 2023. :has() gained traction after Safari’s early adoption and other browsers followed by the end of 2024. By 2025, it’s comfortable to use in nearly all modern browsers.

2025: %98+ browser support

/* ------------ CSS ------------ */
.card:has(img) {
  border: 2px solid green;
}

nav :is(ul, ol) {
  list-style: none;
}

@layer (Layered CSS)
This feature allows you to define layers in your style sheets, specifying which rules should load first and which later. It helps maintain order in large codebases by giving you more controlled overrides. By 2025, most modern browsers support it.

2025: %96+ browser support

/* ------------ CSS ------------ */
@layer base {
  h1 {
    font-family: sans-serif;
  }
}
@layer theme {
  h1 {
    color: red;
  }
}

Features Sass Has That CSS Doesn’t (Yet)

Sass’s most popular features — Mixins, Extends/Inheritance, Loops, and Conditional Logic — don’t have direct equivalents in Native CSS. However, reusable class naming and modern CSS properties can remove much of that need. Plus, we can handle more complex scenarios with certain emerging tools or approaches.

:root {
  --primary-color: #3888ff;
  --gradient: linear-gradient(
    color-mix(in srgb, var(--primary-color) 20%, white)
  );
}

Conclusion

As I mentioned in the piece I wrote at the beginning of 2024, Sass is no longer the indispensable tool it once was. With new CSS features, you rarely need a separate preprocessor. By 2025, the CSS ecosystem has basically caught up to (and partially surpassed) Sass’s core benefits, thanks to direct browser support.

Still, Sass won’t disappear overnight. Legacy codebases, advanced plugins, and community habits mean Sass will remain around for quite a while.

Do I regret dropping Sass? Absolutely not.

By moving away from Sass, I avoided the extra setup and compile overhead. This reduced both the performance and management load on my projects. I also saw solid PageSpeed scores and W3C validator results.

Bonus — AI-Assisted Development (2025)

By 2025, AI has become an integral part of our daily routines. In web development, tools like ChatGPT, Claude 3.5, Copilot, and Cursor can automate many routine tasks in CSS and Sass projects, from code conversion and cleanup to optimization and documentation. That said, as of the date of this article, fully handing over a project to AI might not be the healthiest approach. The best strategy is to collaborate with these tools in a controlled way!

I also share content about general web technologies and the wider web ecosystem on my YouTube channel — hope to see you there!

X — Linkedin — Youtube

Sources

Basic Building Blocks of Programming

Eren — Sun, 14 Apr 2024 15:27:28 +0000

There are basic building blocks of programming. Learning and understanding these building blocks and their relationships are of great importance in the process of learning and making software.

In all programming languages, these basic elements are the same or very similar to each other. Their basic logic of operation is common. For this reason, if you learn a programming language by understanding its foundation, you will not have difficulty in learning other languages.

In this article, we will examine the basic building blocks of programming through JavaScript. When we understand through JavaScript, we will also have understood in every language.

What are the basic elements of programming languages?

Variables,
Data types,
Operators,
Expressions,
Control structures,
Functions,
Data structures,
Classes and objects.

Now let's break down what these elements mean:

Variables

Variables are named memory locations used to store data. Each variable has a data type and its value can be changed within the program.

In JavaScript, variables can be declared in the following ways:

If we examine each element here:

var, let, const are predefined keywords. Each has predefined functions. They have different use cases, but their main function is to declare a variable. So we can call them Declaration keywords.

a, b, c are the names we give to what we declare. We are making a declaration and we need to give a name to these declarations. We call them name or reference.

= is an operator. The function of this operator is to perform an operation. The operation it performs is to assign a value to the variable we defined. Therefore, = is an assignment operator.

29, "text", "surname" are the values that these variables take. They consist of data. They can take many data types. We call them Data types / Value.

The symbol indicating the end of the line is ; Terminator.

What have we done here?

We defined a value named a using a predefined keyword and assigned the value 29 to this variable using the = operator, thus performing an operation.

As I mentioned at the beginning of the article, every language has its own way of writing. In JavaScript/TypeScript languages, we perform operations using these operators and data types.

Let's briefly look at the other basic elements of programming below:

Data Types

Programming languages typically support different data types such as numbers, strings (text), and boolean values (true/false)

Operators

Operators are used to perform operations on variables and values. For example, mathematical operators (+, -, *, /), comparison operators (==, !=, <, >), and logical operators (&&, ||) can be used.

The combination of multiple operators is also called an expression. In this example, the line (a + b - 5) * 5 is an expression.

Control Structures

Control structures are used to control the flow of a program. These structures include if-else statements, loops (for, while), switch-case statements, and functions.

By reading line by line from top to bottom in a code block, we can determine the direction of the code's execution by controlling the flow using these control structures.

Functions

Functions are reusable code blocks that perform a specific task. There are many ways to define functions.

Arrays and Lists

Diziler ve listeler, birden çok değeri saklamak için kullanılan veri yapılarıdır.

Objects and Classes

In object-oriented programming languages, objects and classes are fundamental elements. Objects are instances with properties and behaviors. Classes define the templates of objects.

We've only delved into the basics using the JavaScript language. Remember, there are different types of these definitions in every language. The important thing is to understand the logic.

When we know and understand all of this, we can program. Because almost everything else is made up of these structures.

For example, when we examine the frequently used console.log() statement, we can see that it consists of the Basic Building Blocks we defined above.

console.log() function can be understood by breaking it down into simple components:

( console ): The console object in JavaScript allows us to perform operations on the console. This object can be used in the browser or in the Node.js environment.

( . ) : The dot operator is used to access a property or method of an object. It is used to access the log method of the console object.

( log ) : log is a method of the console object, and this method allows us to write a message to the console. The log method is used to print the given values to the console.

Therefore, the console.log() function prints a message to the console by calling the log method of the console object.
For example, the code console.log("World of the Web") prints "World of the Web" to the console by passing it to the log method of the console object.

These basic components make up the logic of the console.log() function, and through this function, we can get information about the state of our code and debug it.

After understanding these structures, our software learning process will be easier.

I hope I have explained it.

I warmly invite you all to my YouTube channel, where I not only share insightful content on web development but also explore the fascinating dynamics and technologies of the ever-evolving web world.

Twitter - Linkedin - Youtube

The sources referenced in our article are:

Tuncay Baylan

Worldoftheweb

Thank you.

How should class naming be in HTML? — Clean Code.

Eren — Sat, 23 Mar 2024 14:34:26 +0000

Many developers can spend a significant amount of time on naming during the development phase. In fact, for some, it can become a situation where more time is spent on naming than on the coding itself. This is because when naming elements such as classes, ids, functions, variables, and files, it is crucial to use descriptive, meaningful, concise, and consistent names that accurately reflect their purpose within the project.

But why should we name things this way?

The written code becomes more readable and understandable. Our team members or developers from other teams can easily comprehend code blocks, improving collaboration and maintenance processes.
Proper naming ensures consistency in our projects, making naming processes easier as the project grows.
Our CSS files become more organized. Managing and finding a meaningfully named class is always more comfortable.
It prevents naming conflicts when using external libraries.
It benefits SEO (search engine optimization) and accessibility.
It adheres to the DRY (don’t repeat yourself) principle, preventing code repetition.
In large projects, new areas, features, and design revisions are constantly added. Proper naming facilitates better adaptation to these changes, ensuring smooth progress in code updates.

In software development, there is a crucial concept known as Clean Code, emphasizing code readability, understandability, sustainability, and organization. Proper naming is a significant part of Clean Code, and adherence to Clean Code principles begins with accurate naming.

So, how should we name classes in HTML that allow us to build the framework of our websites?

Class names should be written in lowercase letters and separated by either a hyphen (-) or an underscore (_).

<div class=”header-block”></div>
<div class="header_block"></div>

<!-- In cases where they are not separated by a hyphen (-), 
they are defined as two separate class names.-->

<div class="header block"></div>

<!-- These three divs are entirely distinct from each other. -->

Apart from English, other languages should not be used, and camelCase naming conventions should be avoided. CamelCase is a naming convention where the first letter of a word is lowercase, and the initial letters of subsequent words are uppercase.

<div class=”başlık-alanı”></div>
<div class="headerBlock"></div> 
<div class="başlıkAlanı"></div>

<!-- Absolutely should not be used like these examples. -->

<!-- The correct usage is as follows: -->

<div class="header-block"></div>

CamelCase naming conventions are used when assigning IDs to HTML elements that require them.

<div id=”sendButton”></div>

It should be specific and descriptive, clearly defining the purpose of the area to which it is applied.

<article class=”article-content”></article>
<nav class="menu-block"></nav>
<div class="post-date"></div>

It should be kept short and concise, avoiding excessively long naming conventions.

<div class=”authentication-block-container-area”></div>
<div class="frequently-asked-questions-area"></div>

<!-- It is more appropriate to use as follows:  -->

<div class="authentication-block"></div>
<div class="auth-block"></div>
<div class="faq-area"></div>

Avoid naming conventions that are so short that developers outside of your context would find it challenging to understand.

<div class=”lg-cn”></div>
<div class="ar-co"></div>

<!-- Can be used in the following forms: -->

<div class="login-content"></div>
<div class="article-content"></div>

Generic names that could be used in many places should not be used on their own.

<div class=”blue”></div>
<div class="right"></div>
<div class="back"></div>

<!-- It is more appropriate to use in the following manner:-->

<div class="blue-btn"></div>
<div class="content-right"></div>
<div class="back-item"></div>

So, what is the foundation of these recommendations? Why should we name our elements in this way?

In some browsers or platforms, there may be differences in case sensitivity. Therefore, consistently using lowercase letters for class names will prevent potential, unforeseen issues.
We do not use Turkish names in naming because the language of software is universal and is English. Using a language other than English can create problems related to character differences based on language and case sensitivity, similar to the issues mentioned before.
CamelCase is a widely accepted naming convention, preferred not only in class names but also in IDs, variables, and function names.
Long naming conventions, especially when used with CSS in large projects, will increase file size, negatively impacting performance. Additionally, long names make the code less understandable and slow down the development process.
Very short names can cause confusion and have limited usability due to their low character count, leading to inconsistent use in the development process.
Naming conventions like “.left .red” are insufficient when used alone, as they lack clarity in meaning. Moreover, they can be used in different contexts, making the CSS code complex.

All the situations mentioned above are rules established according to the habits of the web development community, specific library expectations, and in compliance with HTML and CSS standards. General usage aligns with these conventions, but they are not mandatory.

Naming standards are established to enhance code readability, maintain consistency in the project, provide organization, reduce the likelihood of errors, and facilitate effective collaboration within the team.

You can access the W3C document related to HTML, which defines the standards of the web world, here.

After explaining all of these, let’s conclude our article with a brief example code block.

<header class="header-container">
    <div class="logo-block">
        <h1>World of the Web</h1>
    </div>
    <nav class="menu-block">
        <ul>
            <li><a href="/">Subscribe</a></li>
            <li><a href="/">My</a></li>
            <li><a href="youtube.com/@worldoftheweb">Youtube</a></li>
            <li><a href="/">Channel</a></li>
        </ul>
    </nav>
    <div class="login-btn">
        <span>Subscribe</span>
    </div>
</header>

I warmly invite you all to my YouTube channel, where I not only share insightful content on web development but also explore the fascinating dynamics and technologies of the ever-evolving web world.

Twitter — Linkedin — Youtube

The sources referenced in our article are:

Originally published at medium on Jan 18, 2024.

SASS is dead? CSS vs SASS 2024

Eren — Sat, 23 Mar 2024 14:23:18 +0000

Originally published at medium on Jan 17, 2024.

SASS is a CSS preprocessor that emerged years ago to simplify the process of writing CSS. To use SASS, we need to install it on our device, and since browsers cannot read SASS but can read CSS, we need to compile our SASS files to CSS.

Thanks to SASS, we can write more organized and effective CSS with features not present in standard CSS.

Now, let’s ascertain whether this situation persists into 2024.

As of today, Native CSS has become much more powerful, and with the support of browsers, we can comfortably utilize the features that strengthen CSS. Let’s together explore the commonly used powerful features of SCSS and their counterparts in Native CSS:

Variables

Defining variables, a key feature of SCSS, was not present in CSS. Variable declaration allows us to manage many properties from a single source. However, now we can also define variables in CSS in a similar manner. Browser support is over 97%.

:root{
    --black:#000;
    --fsize:20px;
    --bshadow:  0 5px 10px var(--black);
}
.content{
    box-shadow: var(--bshadow);
}
h1{
    color: var(--white);
    font-size: var(--fsize);
}

Nesting

Nested writing in CSS is a syntax used to target a specific area. Thanks to SCSS, we can intervene with elements inside the main class by using it only once without repeatedly writing the main class.

Now, in CSS as well, we can nest by using the main class only once. Let’s take a look at an example:

.container {
    padding: 32px;
    .content {
      margin: 16px;
        .btn {
            padding: 12px 32px;
            border-radius: 16px;
            & span {
                font-size: 18px;
            }

        }

    }
}

The above example used to be accomplished in CSS as follows:

.container {padding: 32px;}
.container .content {margin: 16px;}
.container .content .btn {padding: 12px 32px; border-radius: 16px;}
.container .content .btn span {font-size: 18px;}

The CSS nesting feature works in all major up-to-date browsers. However, browser support is still below 90%. In its statement, SASS mentioned that it would continue to use the nesting feature until the browser support reaches 98%.

Partials — Modules

In SCSS, separate SCSS files can be created and used for specific areas. For example, we can create a _input.scss file for form elements and control these elements from a single location. Alternatively, we can import the _input.scss file into another SCSS file, such as _form.scss, and use it in the respective file.

In CSS, we can call and use another CSS file in the desired CSS file as follows. By calling mobile.css in our CSS file, all the properties, including the variables defined in mobile.css, become functional. The browser support for @import is above 97%.

@import “mobile.css”;

Mixins

In SCSS, mixins are an important feature that helps create reusable blocks that can take parameters. Let’s promptly examine an example:

@mixin rtl($property, $ltr-value, $rtl-value) {
  #{$property}: $ltr-value;

  [dir=rtl] & {
    #{$property}: $rtl-value;
  }
}

.sidebar {
  @include rtl(float, left, right);
}

This SCSS file produces the following output in CSS.

.sidebar {
  float: left;
}
[dir=rtl] .sidebar {
  float: right;
}

check for more detail here.

In CSS, something similar to mixins can be achieved with variable declarations, but there is no direct equivalent to mixins in CSS. By using reusable CSS naming conventions as described in this article, you can eliminate the need for mixins.

Extends/Inheritance

In SCSS, the @extend feature allows us to call properties defined in one selector within another selector. It helps us avoid repeating the same properties multiple times. Let's see an example right away:

.error {
  border: 1px #f00;
  background-color: #fdd;

  &--serious {
    @extend .error;
    border-width: 3px;
  }
}

The CSS output of this code is as follows:

.error, .error--serious {
  border: 1px #f00;
  background-color: #fdd;
}
.error--serious {
  border-width: 3px;
}

This feature doesn’t have an equivalent in CSS, but it is not necessary when following the naming conventions as described in this article.

Operators

In SCSS, calculations can be performed using basic arithmetic operations. However, in CSS, mathematical functions like min(), max(), calc(), and clamp() can be used. Browser support for these functions is over 96%.

.block{width: calc(100vh - 100px);}
.content{width: clamp(200px, 50%, 500px);}

If you want to explore many other features of SASS, you can take a look here.

As someone who has been using SASS for years, I believe that as of 2024, the benefits of SASS, including the hassles of installation, usage, and compilation, no longer justify its use. Particularly as projects grow, the compilation times become significantly burdensome.

With CSS gaining strength day by day, especially in 2024, as the use of older technologies/browsers decreases, the prevalence of modern browsers increases, and CSS continues to improve, it will become even more powerful.

In addition, by meaningfully reusing class naming conventions, we can maintain CSS efficiency at the highest level.

Goodbye SASS! Thanks for everything…

I warmly invite you all to my YouTube channel, where I not only share insightful content on web development but also explore the fascinating dynamics and technologies of the ever-evolving web world.

Twitter — Linkedin — Youtube

The sources referenced in our article are:

SASS

Worldoftheweb

Caniuse

Originally published at medium on Jan 17, 2024.