Text Color Gradient

Alberto Forni — Mon, 18 Dec 2023 10:05:29 +0000

This is the simplest way I found to create a beautiful text gradient effect like the one you can find on Apple Products

<div class="title gradient">
    <h1>Text Gradient</h1>
    <h2>width CSS</h2>
</div>

.gradient {
    /* add the colour effect as background */
    background-image: linear-gradient( 90deg, #1e3791 0%, #2948b1 40%, #3153c6 55%, #385fda 60% );

    /* clip the background so only the text is visible */
    background-clip: text;
    -webkit-background-clip: text;

    /* set the text color to transparent so the background colour is visible */
    color: transparent;
}

and here is the result

simple right?!

happy coding.

CSS-in-JS vs CSS in CSS

Alberto Forni — Fri, 03 Nov 2023 11:14:21 +0000

Why the question?
🛠️ Comparison between CSS Modules and CSS-in-JS 🛠️
🚀 CSS-in-JS: The Trending Path with Vue, Svelte, and Astro 🚀
🔧 Ok, I’m Convinced About CSS-in-JS. Which Library Should I Pick? 🔧
Content Security Policy (CSP)
Have you come across Tailwind CSS?
Conclusion
Resources

Why the question?

Picture this: You've got a classic bicycle. It's beautiful, sturdy, and perfect for leisurely rides through the park. But one day, you decide to enter the Giro di Italia. 🚴‍♂️💨 That trusty bike, as lovely as it is, just isn't cut out for the intense, mountainous terrains of the race. Similarly, when the World Wide Web was born, HTML was our trusty bicycle. Designed for simple document structuring, it was perfect for its time. And then came CSS, the stylish accessories to make our HTML bicycle dazzle. But here's the twist: the web evolved! Now, we're not just riding through parks; we're racing in the big leagues.

As the web landscape shifted towards more interactive and dynamic content, the traditional ways of styling started to show their limits.

Relying on manual naming, like BEM, while beneficial, can become cumbersome. Imagine having to remember or reference naming conventions for every component you create:

/* BEM Style */
.button {}
.button__icon {}
.button--disabled {}

The margin for error increases and consistency can waver.

With the introduction of component-based frameworks, each component acted as a self-contained unit, housing both its logic and style.

/* app.svelte */
<script>
    let count = $state(0);

    function increment() {
        count += 1;
    }
</script>

<style>
    button {
        color: red;
    }
</style>

<button on:click={increment}>
    clicks: {count}
</button>

Lastly, as applications grow, the need for shared styles and variables becomes paramount. Consider the scenario where a primary colour needs to be referenced in multiple components. Instead of hardcoding this in each component, we need to use a scalable solution that can reference code written in other components or parts of the application.

In conclusion, "Why the question?" It's because the web isn't static. As we strive for more efficient, maintainable, and scalable solutions, we must evaluate and adapt our tools accordingly.

🛠️ Comparison between CSS Modules and CSS-in-JS 🛠️

As we pedal further into our web development journey, the landscape of styling demands a closer look. If we're all in agreement about the need to modularise styles, let's dive deep into comparing two of the most popular techniques: CSS Modules and CSS-in-JS.

Using CSS Modules:

Pros:

Separation of Concerns: With CSS Modules, styling resides in its own dedicated file. It's like having a separate gear for uphill climbs on our bike journey – dedicated and efficient.

/* styles.module.css */
.button {
    background-color: blue;
}

Simplicity: No extra baggage! There's no need for additional plugins.
Hot-Reload: A smooth ride with easy and instant updates as you make changes.
Developer Tools: Interacting with dev tools is straightforward since the syntax is the genuine CSS we all know and love.

Cons:

File Juggling: The separation means you're constantly switching between your component and style files. It's like having to switch bikes mid-race.
Unused Styles: Identifying and removing styles that are no longer in use can be challenging.
Variable Usages: Spotting typos and leveraging autocomplete becomes trickier.
Navigation: You miss out on the convenience of jumping directly from your component to the associated style.

Using CSS-in-JS:

Pros:

Close Proximity to View: Styles are right next to where they're used. It's like having your water bottle attached to your bike – easily accessible when you need it.

import { css } from 'solid-styled';

function Title() {
  css`
    h1 {
      color: red;
    }
  `;

  return <h1>Hello World</h1>;
}

Full Power of TypeScript/JavaScript: Imagine being able to adjust your bike's settings on-the-go. That's the flexibility you get here.
Type Checking: With TypeScript, you get an extra pair of eyes ensuring you're using the right properties and values.
Navigation: The "go to definition" feature works seamlessly, especially if the style isn’t directly attached to the HTML element.

Cons:

Bulky View Files: Since everything is in one place, your component file can get crowded, making it harder to parse at a glance.
Additional Tooling: Your editor might need some extra setup to understand and highlight styles within JavaScript properly.
Performance Overheads: To ensure your app runs smoothly, you might need to incorporate specific libraries.
Bundle Size: Due to vendor prefixes not always adhering to .browserlistrc, your bundle might end up heavier, and your developer experience could suffer with unnecessary styles in the CSS panel.

But What About Inline `style` Attributes?

While it might be tempting to style directly using the style attribute of HTML elements, there are some pitfalls:

Lack of Global Styles: You miss out on overarching design consistency.
Limited Styling Options: Pseudo-classes, keyframes, and states like hover or media queries are off the table.
Performance: Class names are simply faster than inline styles. It's the difference between a road bike and a mountain bike – each has its purpose!

Conclusion:

Both CSS Modules and CSS-in-JS come with their set of advantages and challenges. Your choice will largely depend on the nature of your project, your team's familiarity with the tools, and personal preference. While I won't outright advocate for one over the other, I lean slightly towards CSS-in-JS for TypeScript-heavy projects due to the added benefits of type checking and direct navigation. But remember, the best tool is the one that gets the job done and feels right for your journey!

🚀 CSS-in-JS: The Trending Path with Vue, Svelte, and Astro 🚀

The ever-changing terrain of web development constantly introduces us to newer tools and techniques. A trend that's hard to miss is the surge in the popularity of CSS-in-JS, especially evident in modern frameworks like Vue, Svelte, and Astro. But what's fuelling this trend?

Why the Shift to CSS-in-Component?

Component-Based Architecture: The modular, reusable, and efficient nature of component-based web development naturally complements the CSS-in-JS approach, where styles are directly tied to their respective components.

**Dynamic Styling: **Traditional CSS can feel static. CSS-in-JS breaks that mould, allowing styles to adapt based on props, state, or live data.
Scoped Styles: Global CSS can sometimes lead to style conflicts. With CSS-in-JS, styles are strictly scoped to the component, preventing unintended overrides.
Enhanced Developer Experience: Features like hot-reloading, immediate feedback, and leveraging JavaScript's capabilities elevate the development process.

Spotlight on Vue, Svelte, and Astro:

Vue: Vue's single-file components are a developer's delight, integrating template, script, and style in one place:

/* app.vue */
<template>
  <button class="btn">Click Me</button>
</template>

<script>
export default {
  name: 'MyButton'
};
</script>

<style scoped>
.btn {
  background-color: blue;
  color: white;
}
</style>

The scoped attribute ensures this component's styles won't interfere with others.

Svelte: Svelte offers a clean and intuitive way to structure components:

/* app.svelte */
<script>
  let color = 'blue';
</script>

<button class="btn">Click Me</button>

<style>
  .btn {
    background-color: {color};
    color: white;
  }
</style>

Here, we're using a variable directly within our styles, showcasing the dynamic capabilities.

Astro: Astro, a newcomer to the scene, emphasises delivering the least amount of JavaScript possible. Here's a glimpse of styling in Astro:

/* app.astro */
<button className="btn">Click Me</button>

<style lang="scss">
.btn {
  background-color: blue;
  color: white;
}
</style>

Conclusion:

The adoption of CSS-in-JS in frameworks like Vue, Svelte, and Astro is indicative of the web development community's desire for more integrated, efficient, and dynamic styling methods. These frameworks, by melding styles with components, offer an approach that's both intuitive and powerful, ensuring web experiences are not only functional but also aesthetically pleasing.

🔧 Ok, I’m Convinced About CSS-in-JS. Which Library Should I Pick? 🔧

Diving into the world of CSS-in-JS, it's evident that many contemporary frameworks come with styling solutions out of the box. But, if you're like me, with a React project in hand, you might be thinking, "Alright, I'm convinced. Hand me the right library!" But wait, it's not that straightforward.

Just as the web development landscape is vast and varied, so are the choices for CSS-in-JS libraries. It's reminiscent of the myriad state management libraries available – each with its unique features and quirks. But fear not! Let's break down the essential features to consider, helping you navigate this space with clarity:

1. (Tagged Templates)
Using ES Tagged Templates, styles are defined as strings:

📝 Syntax: Adheres to the familiar kebab-case, akin to plain CSS.
🔄 Migration: Transitioning from plain CSS to CSS-in-JS becomes smoother, saving you from a total rewrite.
🔧 Tooling: To beautify your code with syntax highlighting and code completion, you'll need extra plugins. Without them, it's just plain strings.
🔄 Parsing: An additional step is needed to morph the string into JS.

2. { } (Object Styles)
Employing plain JavaScript objects, styles are defined as... well, objects!

**📝 Syntax: **Leverages camelCase for property names, echoing React Native conventions.
🔄 Migration: Brace yourself for a full rewrite if you're moving existing CSS.
for instance, backgroundColor: "transparent", in JS becomes background-color: transparent; in CSS and Developer Tools. Note the
camelCase → kebab case,
, instead of ;,
"" go away.

- 🔧 Tooling: The beauty of JS objects means you get out-of-the-box syntax highlighting, sans any extra tooling.

3. .css (Static CSS Extraction)
Your styles get a new life as static .css files:

⚖️ Bundle Size: Say goodbye to additional runtime libraries, trimming your bundle/page size.
🚀 Performance: With an empty cache, this might be a tad slower for your users (affecting FCP/FMP metrics). But with a full cache? Lightning-fast page loads.
🎨 Dynamic Styling: The generated file could bulk up since all style combos need pre-generation at build time.
🖥️ Use Case: Ideal for scenarios like e-commerce sites or blogs where cached styles play a pivotal role.

4. <style> tag
Your styles find their home inside <style> tags within the document's <head>:

🎨 Dynamic Styling: Tailor-making styles on-the-fly becomes a breeze.
⚖️ Payload: A tad bulkier, given that a runtime library is required for dynamic style handling.
🔄 SSR Considerations: Styles necessary for the initial render are shipped twice: during SSR and hydration.
🖥️ Use Case: Perfect for SPAs that are dynamic and interactive.

Content Security Policy (CSP)

A common problem that libraries that create a <style> tag at runtime could face is the Content Security Policy. Styles might be blocked if the HTML page contains Content-Security-Policy: style-src. For that, you can use a nonce that is dynamically produced from the server for every HTTP request and injected into your style tag. This is how Emotion does it.

Have you come across Tailwind CSS?

It's a notable player that has popularised the Atomic CSS approach. While it simplifies styling by allowing users to directly add CSS classes to HTML elements and offering sensible defaults, it does introduce a new "language" to learn. It could be a good option if you start from scratch, but it might not be the most practical choice for existing projects that have extensively utilised traditional CSS or CSS-in-JS.

Conclusion

As you set out to pick your ideal CSS-in-JS library, keep in mind the specific needs and nuances of your project. While there's no one-size-fits-all solution, understanding the features and trade-offs of each approach will ensure you make an informed choice.

Resources

Make Your Code Self-Documenting with Descriptive Event Handler Names

Alberto Forni — Mon, 09 Jan 2023 15:52:49 +0000

In software development, one of the key principles is to make code that is easy to read and understand. This is especially important in declarative systems like React, Vue or Svelte where the code describes what the system is supposed to do rather than the specific steps to do it. When you give your event handlers meaningful names, it becomes much easier for other developers (and yourself, when you come back to the code later) to understand the purpose of the handler just by reading the name.

For example, consider the following two event handlers:

// meaningful event handlers
<Touch
  onTouchStart={saveOffsetForMoveAndFocus}
  onTouchMove={moveWindow}>
...
</Touch>

// generic event handlers
<Touch
  onTouchStart={handleTouchStart}
  onTouchMove={handleTouchMove}>
...
</Touch>

Which of these handlers is more meaningful? The first example clearly communicates what is supposed to happen, whereas the second one does not so, you need to browse the rest of the code to understand its purpose.

Using descriptive names for your event handlers makes your code more self-documenting, which can save time and reduce the need for detailed documentation. It can also make it easier to find and fix bugs in your code, as the names can provide clues about the purpose of the event handler and where it is being used.

Wait, this way my function names are gonna be too long!!!

When it comes to the length of method names, Uncle Bob suggests that it is generally better to err on the side of longer and more descriptive names, rather than shorter and more vague names. In "Clean Code" he writes:

"Don’t be afraid to make a name long. A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment. Use a naming convention that allows multiple words to be easily read in the function names, and then make use of those multiple words to give the function a name that says what it does."

To add to that, I recently came across a concept: the "Principle of Least Astonishment" or POLA, which states that code should be written in a way that minimises the surprise of the reader. I think that by giving your event handlers descriptive names, you can make it clear what they do and reduce the potential for a surprise when reading the code.

Forem: Alberto Forni

Text Color Gradient

CSS-in-JS vs CSS in CSS

Why the question?

🛠️ Comparison between CSS Modules and CSS-in-JS 🛠️

Using CSS Modules:

Using CSS-in-JS:

But What About Inline style Attributes?

Conclusion:

🚀 CSS-in-JS: The Trending Path with Vue, Svelte, and Astro 🚀

Why the Shift to CSS-in-Component?

Spotlight on Vue, Svelte, and Astro:

Conclusion:

🔧 Ok, I’m Convinced About CSS-in-JS. Which Library Should I Pick? 🔧

Content Security Policy (CSP)

Have you come across Tailwind CSS?

Conclusion

Resources

Make Your Code Self-Documenting with Descriptive Event Handler Names

Wait, this way my function names are gonna be too long!!!

But What About Inline `style` Attributes?