DEV Community: Matteo Frana

CMS vs AI: The Content Battle Begins

Matteo Frana — Tue, 16 Dec 2025 14:58:09 +0000

Introduction

Lee Robinson recently announced that the Cursor team no longer uses a CMS for the Cursor website, opting instead to rely on AI to generate the site directly in code. As he put it:

“I migrated cursor.com from a CMS to raw code and Markdown. I had estimated it would take a few weeks, but was able to finish the migration in three days with $260 in tokens and hundreds of agents.”

At first glance, this feels like a natural evolution, as AI is increasingly good at writing both code and content.

At the same time, CMS vendors have been quick to respond, publishing articles that reaffirm the value of structured content, editorial workflows, and long-established CMS capabilities.

So who is right?

The AI-first camp?
The CMS-first camp?
Both?
Or perhaps… neither?

Is it possible to combine structured content, a headless architecture, and full-page, context-aware AI content generation?

Spoiler: yes. (See the video below.)

Common Ground

In March 2025, I published an article titled “Common Ground: A Framework for Human–AI Collaboration”, where I defined Common Ground as a shared format, medium, or interface that enables effective cooperation between humans, and between humans and AI.

Classic examples of strong common ground include:

Code in software development
Text in copywriting

In my August talk at Decoupled Days in New York, I refined this idea further by identifying three characteristics that a good common ground must have to support creative collaboration.

A good common ground must have a structure that is:

Visible — every actor in the system can see it
Understandable — every actor can understand it
Editable — every actor can modify it directly, without increasing information entropy at each review cycle

Text and code are excellent examples: the structure is the content. Both humans and AI can read it, understand it, and edit it directly.

Now consider Content Management Systems. CMSs sit at the intersection of code (the platform and frontend rendering logic) and content—two areas where AI is already highly effective. This overlap raises the question: is AI about to replace CMSs, or expose their current limitations?

To answer this question, we'll now dive into content management and AI, in search of common ground.

Content Management

The Good Ol’ Days

In the early days of the web, websites were written directly in HTML. In 1997, when a client wanted to change their website, they called me and I edited the code.

Later came tools like Microsoft FrontPage, which allowed non-technical users to generate HTML through a visual, word-processor-like interface. Unfortunately, these tools produced unmaintainable code (think deeply nested tables for layout), while giving users unrestricted design freedom: I still have memories of Comic Sans title in neon green on a purple background!

The Headless Days

Fast forward to today’s headless CMS landscape.

Content editors work with server-side, form-based interfaces to enter structured data into a database. Frontend applications retrieve this data via REST or GraphQL APIs and render HTML using modern frameworks and component-based “template languages” such as React, typically within Next.js or Astro.

This model clearly separates responsibilities:

Developers build the frontend, define components, and control how content is rendered
Content editors create content by filling abstract fields in the CMS forms

Both roles can use AI, but in very different ways, and with very different results:

Developers use AI inside their IDE to generate or refactor frontend code
Editors use AI tools (standalone or CMS-integrated) to generate copy, but only for individual text fields

The Decoupling Problem

By definition, a headless CMS is decoupled from the frontend. As a result, it does not know:

How content will actually be presented in the frontend UI
Which pieces of content end up on which pages

Because of this, AI operating inside a traditional headless CMS can generate individual text fragments, but it cannot:

Generate full pages
Understand page-level context
Choose which components to use on a page
Adapt the copy tone to the semantic role of each section

The CMS has no awareness of the page composition, and no knowledge of the design system. Consequently, AI is limited to generating isolated text values rather than coherent, contextual page content.

The Visual Headless Paradigm

Let’s take a step back and look at the decoupling problem from a different angle. Even before AI entered the picture, content editors already faced similar challenges. They were asked to edit abstract entities in a CMS interface (sometimes with an async preview), while mentally mapping those entities to sections of real pages.

Since late 2019, a new paradigm has emerged: Visual Headless CMS, introduced by React Bricks.

In a visual headless CMS:

Developers build a design system with composable React components ("Lego bricks" for content)
Editors compose pages visually using those bricks, editing text and images inline, directly on the page

This approach solves both the major problems of a decoupled architecture:

Editors work directly on the final page, not abstract forms
The mapping between content and presentation becomes explicit and intuitive, like a word processor

For developers, the benefits are equally strong:

The frontend is a modern, typed React application (Next.js, Astro, etc.)
The design system is fully enforced: editors can only change what developers explicitly allow
Content remains decoupled and is stored as pure JSON, delivered via APIs

Each page is represented as a structured list of blocks, each mapped to a React component and its properties (text, images, visual options). Both the CMS interface and the frontend render the same components, passing in the properties from the APIs.

The result:

Developers are productive (it's just React!)
Designers' brand guidelines and design systems are protected
Editors work visually and confidently

Now—AI enters the scene.

AI-Powered Visual Headless CMS

In May 2025, during the European CMS Idol competition in Frankfurt, I presented a preview of an AI-powered full-page generation feature of React Bricks—an approach that helped secure first place in the contest.

From an AI perspective, a visual headless CMS provides exactly the missing context.

AI now has access to:

UI awareness — the AI can understand the React-based design system, enriched with semantic metadata (what are hero sections, CTAs, FAQs, etc.)
Page context — the page is a first-class entity, with its current structure and content fully known

This enables a powerful, multi-pass generation pipeline:

Plan the page structure by selecting appropriate bricks
Generate text for each block with the correct tone and intent
Choose images from the DAM or copyright-safe external sources
Select icons from the design system's approved collections
Set allowed visual properties (layout, background, spacing)

The result is high-quality, on-brand, contextual content that fully respects the design system.

The output remains structured content, which editors can refine visually at any time.

In Search of Common Ground

Let’s revisit the three qualities of a good common ground.

The bricks (the visually editable React components) are:

Visible: editors see the brick's visual interface; AI sees the component schema and properties
Understandable: both humans and AI understand the semantics of components and properties (either inline editable texts and images or values set via sidebar controls)
Editable: both can edit the content (visually or via structured JSON) without increasing the information entropy

What began as a very good common ground between developers and editors, naturally extends to AI.

If you layer MCPs, SEO automation, keyword-driven content generation on top of this foundation, entirely new workflows become possible.

AI vs CMS: Who Wins?

Using AI to directly code a complex enterprise website is no smarter than letting customers edit HTML with FrontPage—or even a modern visual site builder.

Corporate websites require far more than raw content generation:

Brand and design system safeguards
Roles and permissions
Editorial workflows and approvals
Scheduling and version history
Backups and audit trails
Internationalization
Integrations with external systems
Enterprise-grade security

AI cannot replace a CMS.

AI should operate inside a CMS.

And for AI to generate full pages—not just fragments—it needs a CMS that understands pages, components, and design systems.

That CMS is a Visual Headless CMS, lightly coupled to the frontend through a shared design system: Lego bricks for content.

A true common ground for developers, designers, editors—and AI.

The AI-Only Sweet Spot

It’s important to acknowledge that there are scenarios where AI-only content generation is a good solution.

For a small startup with a team of two or three developers, no dedicated marketing team, and a simple website, using AI to generate and maintain the website directly in code can be an excellent choice. In this case, speed matters more than governance and long-term content scalability.

It is the same class of use cases where visual site builders like Webflow or Framer work well: few abstractions, fast iteration, minimal overhead.

The key point is not that AI-only is wrong—it’s that it is optimal for a very specific organizational shape. As soon as content becomes a shared responsibility across marketers, designers, and developers, and as soon as brand consistency, approval workflows, and scale start to matter, the limitations of the AI-only approach quickly surface.

Conclusion

CMSs are not going away.

Modern websites require:

AI
CMS
Modern frontend frameworks

But more than that, they require alignment.

Alignment between humans and AI. Between structure and flexibility. Between speed and control.

The real question is not “CMS vs AI?” but “Where is the common ground where AI can safely and effectively operate?”

If your CMS cannot understand pages, components, and design intent, AI will always be constrained to generating fragments. If it can, AI becomes a true collaborator.

The future of content is not raw prompts writing raw code.

It is structured creativity, powered by AI, grounded in design systems, and expressed through Lego bricks for content.

If you’re building for teams—not just for demos—that’s the battle worth winning.

Common Ground: A Framework for Human-AI Collaboration

Matteo Frana — Tue, 04 Mar 2025 19:54:27 +0000

Introduction

Recently I've been thinking about how AI, developers, and end users can efficiently collaborate in content management.

At the same time, Matt Biilmann, CEO of Netlify, who introduced the term AX (Agent Experience), wrote about AX, Creativity and the Human Web. I frequently find myself aligned with Matt's vision. In this case too, I strongly agree with his perspective that we must find a balance between automation and human creativity, ensuring AI can enhance—rather than constrain—human expression.

I believe that true creativity can only emerge from genuine collaboration between humans and AI. Creativity is an iterative process grounded in a medium: think of a painter sketching on canvas or a composer playing notes on a piano and transcribing them to a music score. This is why I believe humans should not only provide abstract feedback to AI, but also be able to directly modify the creative work in progress.

To address this need, this article introduces the concept of "common ground."

Common Ground

Common Ground is a shared medium, such as a file, text, canvas, or interactive interface, where multiple parties can collaborate as peers on intellectual work. It serves as a shared format or interface enabling effective cooperation between humans, and between humans and AI.

Good Common Ground Examples

When considering effective human-AI collaboration, two examples spring to my mind: software development and copywriting.

In software development, code serves as an excellent common ground, as both developers and AI can understand and iteratively modify it.

In copywriting, the text itself acts as the common ground, allowing both content editors and AI to read and directly refine the work.

Bad Common Ground Examples

When AI produces output in formats that humans cannot easily modify, the collaboration becomes less effective and ultimately constrains human creativity.

Imagine if AI always produced low-level assembly code, or highly optimized but unreadable code without comments. The collaboration would become a one-way process: after AI creates the code, only AI could modify it. Developers would be limited to providing prompts and crossing their fingers. No common ground → no true collaboration.

Consider AI-generated music (as a "composer myself, I'll set aside my reservations about AI-generated music): while AI can create perfectly mixed instrumental and vocal tracks, humans cannot directly modify them.

The same applies to images and video: humans can only provide feedback and eventually settle for the results, even when the outcome differs from their original vision. This happens simply because they cannot make further improvements through prompts, and the absence of common ground prevents them from directly "sketching" their ideas.

Characteristics of Effective Common Ground

Finding a good common ground is straightforward in some cases, but challenging in others. When multiple approaches exist, we should aim for the one that offers the most effective common ground. A big LLM can work easily with unstructured output and refine it, but human brain’s neural network needs to work on structured schemas.

For AI-generated music, a musical score would serve as a better common ground than audio tracks. This would enable humans to directly edit harmony, melody, and lyrics and quickly test their changes, with fully mixed tracks generated only as a final step (and even for this step, it would be better to have the raw tracks as well so that compression or effects could be tweaked by a human).

Another example: now that AI can generate entire full-stack applications, I propose that an AI-driven data-intensive app generator should establish common ground through an augmented database structure. This structure would include metadata for each field, indicating whether it should appear in list or detail views, what type of editing control works best, relevant permission rules, and so on. This approach would enable developers to easily modify properties without wading through AI-generated code or relying trial-and-error prompting for simple changes.

These examples demonstrate that an effective common ground between AI and humans is typically a well-structured format—such as a JSON file, programming code, or a musical score.

A structured common ground has two advantages:

It makes complex problems more manageable for humans
It provides a set of good constraints for AI, so that the output stays predictable and manageable

As a former jazz player, I'd like to make a parallel to improvisation: when you play a jazz standard, you have a well-defined structure—the sequence of chords and their harmonic function. When you improvise over this chord structure, you follow certain rules and use specific scales for each chord. This doesn't limit your freedom; quite the opposite, it provides helpful rails and a framework to express creativity. Moreover, the shared chord structure provides all band members with a solid common ground for creating music together. Within this framework, they can listen to each other and collaboratively create something new.

This is true for art in general: good rules provide guidance, and artists need to know them even when they intend to break them. Good constraints don't limit creativity—they help it flourish. Try this simple test: invent a line of poetry. Difficult, isn't it? Now, invent a line of poetry with the word "key". Your brain immediately starts working, right?

By providing a framework within which both humans and AI can work, we create space for innovation while maintaining coherence and consistency.

Conclusion

The concept of Common Ground offers a valuable framework for understanding and improving human-AI collaboration. As AI becomes increasingly integrated into creative work, establishing effective shared mediums will be essential for a truly collaborative process.

The most effective collaborations occur when both parties work within a well-structured format that balances flexibility with constraints.

Structured formats like a component’s interface, a well-defined JSON object, or musical notation provide:

Clear syntax and rules that both humans and AI can understand
The right level of flexibility for creative expression
A schema that make complex problems manageable
Good constraints leading to predictable output that supports iterative refinement

As we design tools and workflows for human-AI collaboration, we should prioritize creating robust, structured common grounds that amplify human creativity rather than constrain it.

In a forthcoming article, I'll explore how these Common Ground principles apply specifically to content management systems, examining which approaches provide the most effective collaboration environment for developers, content editors, and AI.

The Mystery of Tailwind Colors (v4)

Matteo Frana — Thu, 20 Feb 2025 19:07:56 +0000

Overview

This article explores how Tailwind CSS v4 has adopted OKLCH color notation and why this change is significant for web developers and designers. You'll discover the fundamentals of color spaces, learn why OKLCH offers better color manipulation than HSL, and understand how to replicate Tailwind's color system for your own custom colors.

Introduction

Tailwind CSS recently released v4 with several new features. A key change is that colors are now defined using OKLCH notation, such as oklch(0.685 0.169 237.323). I had never encountered this color notation before and I saw that it enabled more vivid colors. My nerd curiosity kicked in, leading me to explore high-gamut color spaces and discover why OKLCH notation is better than HSL.

During this time, I also needed to create custom colors for a Tailwind CSS project. This presented the perfect opportunity for learning and some late-night hacking sessions. The result was uihue.com. In this article, I'll share what I learned and explain the algorithm I developed to generate color hues.

A bit of Color Theory

The CSS color module level 4 specification introduces new syntax for expressing colors in the standard sRGB color space with rgb(…) or hsl(…). The modern syntax separates color components with spaces instead of commas, uses a slash for the optional alpha value, and allows mixing percentages with numbers. For example, rgba(255, 0, 0, 0.5) becomes rgba(100% 0% 0% / 50%).

More significantly, this specification introduces new ways to define colors using different color spaces. But what exactly is a color space?

Understanding Color Spaces: how we see and define colors

Let's start with what a color is. A color is our visual perception of matter based on its electromagnetic spectrum (the amount of light at each visible frequency that travels from an object to our eyes). For objects that don't emit light, color depends on the spectrum of the light hitting them and how they absorb and reflect it. For objects that do emit light, we must also consider their emission spectrum—how much light they emit at each visible frequency.

The CSS specification defines color as "a definition (numeric or textual) of the human visual perception of a light or a physical object illuminated with light." For the specification's purposes, what matters is how a color can be expressed as a string or number.

In this regard, the specification defines a color space as "an organization of colors with respect to an underlying colorimetric model, such that there is a clear, objectively measurable meaning for any color in that color space." A single color can be expressed in different color spaces, though some colors may only be represented in certain color spaces.

Color Gamut: from sRGB to Modern Display Standards

No display can reproduce all the colors that the human eye can perceive. The range of colors a display can produce is called a "gamut." Most modern displays show colors in the "sRGB" color space's gamut, which covers about 35% of all human-visible colors. These colors can be expressed using the rgb(…) or hex notation (e.g. #f65a8e).

Modern devices, particularly Apple computers and phones, can display a broader range of colors—usually more saturated ones. This capability requires new color spaces and notation forms to express these wider gamuts.

Color spaces, arranged from smallest to largest gamut, are: sRGB ⇒ Display P3 ⇒ Adobe RGB 98 ⇒ REC.2020 ⇒ ProPhoto RGB. Current Apple devices can usually display colors up to the REC.2020 color space gamut.

Color Space Components and Notation

Colors in a CSS color space notation are represented as a list of color components (also called "channels") that represent components along the axes in the color space. Each channel has a minimum and maximum value, and any color with values outside these ranges is considered invalid.

Note about Alpha

We won't discuss the additional alpha component, which controls transparency, as it can be considered a post-processing operation that blends a color with whatever is beneath it.

Examples of color notations:

rgb() defines colors in the sRGB color space using red, green, and blue channels
hsl() defines colors in the sRGB color space using hue, saturation, and lightness in the HSL cylindrical coordinate model

CSS level 4 introduces additional color notations: hwb for sRGB, lab and lch for CIELAB, and oklab and oklch for Oklab, along with a general color function for various color spaces.

In this article, we'll focus on oklch—the most relevant option and the one Tailwind v4 uses for its predefined colors. We won't delve into technical topics like the differences between CIE Lab and Oklab color spaces or cartesian versus cylindrical coordinates.

OKLCH: A Better Way to Express Color

The OKLCH color notation is based on the Oklab color space, designed to enhance perceptual uniformity, hue and lightness prediction, and color blending. It was introduced by Björn Ottosson in December 2020. OKLCH represents colors using cylindrical coordinates in the Oklab color space.

Here are the three key aspects of the OKLCH notation:

It allows colors to be expressed in the P3 or REC.2020 gamut—colors beyond what rgb(), hsl(), or hex formats can represent. This future-proof notation can even define colors that current devices cannot yet display.
Its coordinates are:
1. L (Perceived Lightness): ranges from 0 to 1, or 0% to 100%
2. C (Chroma, or saturation): ranges from 0 to infinity (but it always stays below 0.37 in the P3 color space)
3. H (Hue): ranges from 0 to 360 degrees
It uses perception-based lightness and saturation, solving major perceptual issues found in HSL notation and enabling easier color manipulation (see next section)

HSL's Perceptual Limitations

Let's explore the two major perceptual limitations of HSL and the sRGB color space.

Variable Maximum Saturation

In HSL, the maximum saturation remains constant across all hues. However, in reality, maximum saturation varies depending on both hue and lightness—this applies to both displays and the human eye.

I recommend checking out the excellent OKLCH color picker at oklch.com. Be sure to enable the "Show 3D" switch (because who doesn't love going full nerd?) to view the 3D model of the color space. At the "base" of these "color mountains" you'll find a Hue/Lightness diagram with zero Chroma (showing only grays), while the mountains' heights represent the maximum Chroma available across different hues and lightness levels.

You can see from these two images of the 3D OKLCH color space (from oklch.com) how greens have a higher maximum chroma compared to yellows and how blue reaches its highest chroma at low lightness levels.

Non-Uniform Lightness in HSL

A critical issue with HSL is that its lightness values don't align with human visual perception across different hues. Two colors can have the same HSL lightness value yet appear completely different in brightness to our eyes.

The Oklch notation in the Oklab color space solves this problem by ensuring that identical lightness values create the same perceived brightness.

The example below illustrates this difference: colors with the same HSL lightness can look dramatically different in brightness. However, when we change only the hue in Oklch while keeping the lightness constant, all colors appear equally bright.

OKLCH in Practice: Three Game-Changing Benefits

Better Color Manipulation

As we saw, OKLCH ensures that Lightness and Chroma values are perceptually consistent across all hues. This enables better mathematical color manipulation. When you need a specific lightness level to ensure sufficient contrast with white text, OKLCH provides reliable results, unlike HSL. This makes color adjustment functions like darken/lighten more reliable.

Better Color Gradients

While HSL gradients tend to create unwanted gray areas when colors mix, OKLCH's perceptually uniform model produces smooth, visually balanced gradient transitions.

Wider Gamut

OKLCH lets us express and use colors with a higher gamut, producing more vibrant, eye-catching designs that modern devices can display. While the image on the left appears more saturated, it has been converted to sRGB due to Dev.to's image processing, but it still illustrates the concept.

Browser Compatibility and Fallback Strategy

With all these advantages of OKLCH in mind, you might wonder about browser support. The good news is that as of early 2025, OKLCH enjoys full support across all major modern browsers. And when colors fall outside a display's gamut, browsers automatically handle the conversion to a supported gamut.

Decoding Tailwind's Color Architecture

Do you know how many color types (different hues) Tailwind includes? You might guess 10 or 12? Maybe 15?

Actually, there are 22! They are: Red, Orange, Amber, Yellow, Lime, Green, Emerald, Teal, Cyan, Sky, Blue, Indigo, Violet, Purple, Fuchsia, Pink, Rose, Slate, Gray, Zinc, Neutral, and Stone—plus black and white, making it 24 in total.

Each of these color types has a palette of 11 different shades (50, 100, 200, 300, 400, 500, 600, 700, 800, 900, 950). The 50 shade represents the lightest color, while 950 represents the darkest.

Before Tailwind v4, these colors were defined in the sRGB color space using HSL or HEX format. With Tailwind v4, colors are now defined using the OKLCH format in the Oklab color space. This change allowed Tailwind expert designers to choose colors outside the sRGB gamut—in fact, you will find some more saturated colors that exist only in the P3 gamut.

Anatomy of a Tailwind Color Palette

You might expect the hue and saturation to remain constant across the whole palette, and the lightness to decrease linearly from 50 to 950—especially since the Oklab model is perceptually uniform, right?

I am sorry to disappoint you: all these assumptions are wrong. You can see the charts for all the new Tailwind colors, showing how lightness, chroma, and hue change across different shades, here: https://www.uihue.com/tailwind-colors-charts

Here are three examples:

As you can see, none of these diagrams follows a linear pattern. I stumbled upon this surprising discovery while trying to replicate Tailwind's palette-building approach for custom color palettes.

Don't worry though—let's try to break down the underlying patterns.

Lightness

The Lightness follows a non-linear curve that remains fairly consistent across color palettes, though grays show a steeper decrease in the darker shades.

Chroma

The chroma (saturation) follows a Gaussian curve pattern, peaking between the "400" and "600" shades, with a sharper decrease in the lighter shades (toward the left side).

Hue

In the charts, hue values have been normalized by subtracting the minimum hue value. Without this normalization, hues near 0° (like reds) would show larger min-max differences than higher hues (like violet). This normalization allows you to better compare hue variations across the entire spectrum.

Looking at all the charts, you'll notice that hue remains fairly consistent across different shades, with two notable exceptions: yellows shift toward orange in darker shades, and blues shift toward violet in darker shades.

From Analysis to Algorithm: Recreating Tailwind's Colors

My mathematical mind's first instinct was to derive three average curves—for lightness, chroma, and hue—across all colors (maybe with separate rules for colors and grays). I planned to use a Fourier transform to approximate these curves and create a clean rule for generating new colors.

However, this approach wouldn't work. I wanted to achieve the highest possible fidelity in replicating Tailwind colors, but averaging would have flattened the subtle hue differences that make each palette special. I would have lost crucial nuances, like how yellows become more orange when darker, or how azure shifts toward blue-violet. Then a much simpler idea struck me.

I could simply identify the nearest Tailwind color for any given input color and apply the same rules that Tailwind uses for that nearest color. So, the first step was to find the nearest Tailwind color to the user's chosen color.

Finding the Nearest Color

Given a collection of colors and a target color, how do we determine which color in the collection is closest to our target? Simple: we test each color, measure the distance, and choose the one with the minimum distance. But this raises another question: how do we define the distance between two colors?

The simplest approach uses Euclidean distance across the N axes of the color representation (essentially applying the Pythagorean theorem in N dimensions). In the sRGB color space, for example, we could calculate the Euclidean distance using the R, G, and B axes:

\sqrt{(R_2-R_1)^2 + (G_2-G_1)^2 + (B_2-B_1)^2}

Unfortunately, this distance calculation isn't very effective. Consider the example in the following image: blue and violet have a greater Euclidean distance than yellow and orange, even though they appear much more similar to our eyes.

If we switch to a perceptually uniform color space, such as Lab, the Euclidean distance becomes much more reliable.

I then learned about a family of algorithms called "DeltaE" (DeltaE) (ΔE), specifically designed to calculate the difference between two colors. The first version, the CIE 1976 formula, simply used the Euclidean distance of colors in the Lab color space. However, when Lab proved less perceptually uniform than initially thought, the algorithm went through several revisions in 1984, 1994, and finally 2000—resulting in the most accurate, though most complex, Lab-based DeltaE algorithm to date.

I used the DeltaE 2000 algorithm implementation from the Colorjs.io library to iterate through the Tailwind CSS colors and find the nearest match. I'm also interested in testing a simpler Euclidean distance calculation in a more advanced color space like JzCzhz.

Generating Color Palettes: The Algorithm

Now that we have the nearest Tailwind color (let's say it's "sky-700"), we can proceed with generating a complete palette.

The user's selected color becomes the "700" shade in the palette—our "base shade." From there, we need to generate both lighter and darker shades.

A simple approach would be to take the hue of the user's selected color and apply the same lightness and chroma values from the nearest Tailwind color for each shade.

However, this would cause us to lose the unique characteristics of the user's color, for example lower saturation or slightly lower lightness compared to the Tailwind color.

Simply applying Tailwind's lightness and chroma deltas from the base shade seemed promising, but this approach could produce completely desaturated colors at the extreme ends of the palette.

Instead, I applied these deltas with a smoothing effect as we approach the extreme light and dark hues. This preserves the color's distinctive features where they matter most—in the middle shades—while ensuring balanced results for the lightest and darkest shades.

Name that Color!

As developers, we know naming things is one of the hardest tasks. When I needed to give each user's color pick in uihue a beautiful name, I faced quite a challenge.

Initially, I considered using the standard HTML 4.01 named colors like "red," "lime," "aliceblue," or "papayawhip." But with only 148 named colors available, this wouldn't provide enough unique names for the vast spectrum of possible colors.

I then found a massive list containing over 30k colors. However, calculating 30k color distances for each color pick would be unnecessarily resource-intensive. Instead, I settled on using NTC colors—a collection of 1,566 names that provides enough variety to find beautiful color names without excessive CPU usage.

User-Friendly OKLCH Color Selection

As far as I know, there's just one dedicated color picker for the OKLCH color space: the excellent tool at oklch.com. While it's really great and features the neat 3D representation of the color space, this kind of interface might intimidate users who aren't familiar with how OKLCH works.

Instead, I decided to implement a standard HSL color picker in the sRGB color space, convert the color to OKLCH, and then let users increase the chroma with a simple slider. The interface clearly shows when colors enter higher gamuts like P3 or REC2020.

I'm very satisfied with the result: users find it both user-friendly and fun to use.

Implementing Accessible Color Contrast

In the uihue.com app, I display color shade numbers over the colored squares of the generated palette, using either light or dark text.

How do I determine which text color provides better contrast against each shade's background? Simple—I measure the contrast ratio for both options and choose the higher one.

As you might expect, there's science behind this. Several algorithms exist for calculating contrast between text and background colors, including: Weber contrast, Michelson contrast, Advanced Perceptual Contrast Algorithm (APCA), Lightness difference in the CIE Lightness L* space, Delta Phi Star (ΔΦ*), and WCAG 2.1.

I chose to implement the APCA algorithm (through the Colorjs.io library), as it offers the best performance and is being considered for inclusion in version 3 of the W3C Web Content Accessibility Guidelines (WCAG).

Conclusion

In this journey through color spaces and Tailwind's color system, we've explored the advantages of OKLCH over traditional color notations, particularly in web development. The transition to OKLCH in Tailwind v4 represents a significant step forward in how we handle colors in modern web design, offering better perceptual uniformity, wider gamut support, and more reliable color manipulations.

As display capabilities improve, the OKLCH color space will become increasingly important. It enables us to create more vibrant, accessible, and visually appealing designs while maintaining precise control over color relationships and contrast ratios.

Through the development of uihue.com, we've seen how understanding color spaces and implementing smart color-matching algorithms can bridge the gap between technical color theory and practical web development needs. The complexity behind Tailwind's carefully crafted color palettes reveals that even seemingly simple color choices involve intricate patterns and thoughtful design decisions.

References

The WordPress, WP Engine and ACF Drama

Matteo Frana — Mon, 14 Oct 2024 21:46:02 +0000

In this article, I aim to provide a clear explanation of the ongoing situation involving WordPress, WP Engine, and more recently, the ACF plugin. I want to emphasize that I'm not affiliated with any of the parties involved. Text enclosed in double quotation marks or block quotes is directly quoted from the original source.

As a web developer since 1996, I've witnessed WordPress's early days and used it for some time. Now, I find myself saddened and disappointed by the recent events. That's why I've chosen to present a comprehensive account of the facts to date, followed by a brief personal reflection at the end.

The Actors involved

1. WordPress

You're likely familiar with WordPress, as it is one of the most popular platforms for building websites, powering more than 40% of sites on the Internet.

WordPress began as an open-source PHP project launched in 2003 by Matt Mullenweg and Mike Little. Initially a blogging platform, it evolved into a more versatile Content Management System (CMS) with a powerful themes and plugins system. By 2011, it had become the most popular CMS worldwide.

As an open-source PHP project, WordPress can be self-hosted on any server with PHP and MySQL available. The official website for the open-source project is WordPress.org.

2. WP Engine

Hosting companies can offer plans with WordPress pre-installed. One of these companies is Automattic, owned by Matt Mullenweg (one of WordPress's original founders), which provides hosted WordPress services through WordPress.com (note the difference from the WordPress.org domain of the open-source platform).

WP Engine is another company providing WordPress hosting services. They claim to be the #1 platform for WordPress. Indeed, they're a significant player in the industry, with an annual revenue of around half a billion dollars. In 2018, WP Engine secured a $250 million investment from Silver Lake, a global private equity firm specializing in technology investments.

3. ACF

Advanced Custom Fields (ACF) is a very popular WordPress plugin. Created by Elliot Condon and later acquired by Delicious Brains in June 2021, ACF simplifies the management of structured data on WordPress pages. It allows developers to create custom field sets through an intuitive interface and retrieve their values in PHP code. Content editors can then populate these fields using the familiar WordPress admin interface.

ACF comes in two versions: a free version and a premium "Pro" version. The Pro version unlocks additional features, including the Repeater field, the Flexible Content field, and the Gallery field.

In June 2022, WP Engine acquired Advanced Custom Fields (ACF) along with the other WordPress plugins from Delicious Brains.

The Battle Unfolds: A Three-Act Drama

Act 1: The WordCamp Showdown

On September 20th, during WordCamp US 2024 in Portland, Oregon, Matt Mullenweg spoke about Silverlake, the company behind WP Engine.

He claimed that Silverlake contributes to WordPress for 47 hours per week (decreasing to 40), while Automattic contributes 3,786 hours weekly. Mullenweg asserted that Silverlake "doesn't give a dang about your open source ideals, it just wants return on capital."

He then posed a provocative question to the audience: "Who are you giving your money to: someone who is going to nourish the ecosystem or someone who is going to frack every bit of value out of it until it withers?".

The talk was followed, on September 21st, by a post by Matt Mullenweg titled "WP Engine is not WordPress" where he claims that:

WP Engine is causing confusion with the "WordPress" trademark;
WP Engine generates half a billion dollars in revenue from WordPress hosting, yet only contributes back just 40 hours per week to the community;
WP Engine disables content revisions by default to reduce storage costs. Mullenweg writes: “They are strip-mining the WordPress ecosystem, giving our users a crappier experience so they can make more money”. And after, “they are a cancer to WordPress, and it’s important to remember that unchecked, cancer will spread”.

Act 2: WP Engine's Response

In response, on September 23, 2024, WP Engine sent a "Cease and Desist" letter to Automattic.

The litigation counsel for WP Engine made startling claims in this document.

They alleged that:

In the days leading up to Mr. Mullenweg's September 20th keynote address at the WordCamp US Convention, Automattic suddenly began demanding that WP Engine pay Automattic large sums of money, and if it didn't, Automattic would wage a war against WP Engine.

Furthermore, they asserted that during the conference, Mullenweg sent text messages to WP Engine's CEO and board members, "threatening that if WP Engine did not agree to pay up prior to the start of Mr. Mullenweg's livestreamed keynote address at 3:45pm on September 20, he would go 'nuclear' on WP Engine."

All these alleged messages can be found on pages 3 and 4 of the document.

Act 3: Automattic's Countermove

The day after, on September 24, 2024, Automattic sent their own ”Cease and Desist” letter indicating that WP Engine’s hosting services “improperly use our Client’s WORDPRESS and WOOCOMMERCE trademarks in their marketing”.

In this context, the "Client" refers collectively to Automattic, Inc. and WooCommerce, Inc.
While the "WordPress" trademark registration is owned by The WordPress Foundation (a charitable organization), Automattic holds the exclusive commercial rights to use, enforce, and sublicense it.

In the Cease and Desist letter, Automattic's lawyers demand that WP Engine stops all allegedly unauthorized use of the WordPress trademark and pay compensation for "unauthorized use of their intellectual property and unfair competition". The letter states that the specific amount will be determined once WP Engine provides an accounting as requested. It then adds, "even a mere 8% royalty on WP Engine's $400+ million in annual revenue equates to more than $32 million in annual lost licensing revenue for our Client".

The WordPress Foundation also revised its Trademark Policy page, specifically changing the section about "WP" and addressing "WP Engine" directly:

The abbreviation “WP” is not covered by the WordPress trademarks, but please don’t use it in a way that confuses people. For example, many people think WP Engine is “WordPress Engine” and officially associated with WordPress, which it’s not. They have never once even donated to the WordPress Foundation, despite making billions of revenue on top of WordPress.

Just a few days before, the same page contained a more permissive statement regarding the use of the abbreviation "WP":

The abbreviation “WP” is not covered by the WordPress trademarks and you are free to use it in any way you see fit.

For those interested in the legal aspects, you can also read the official lawsuit filed by WP Engine on October 2, 2024.

The Escalation: A Dramatic Three-Act Sequel

Until this point, the conflict had been limited to words, spoken or written, and many WordPress developers were still unaware of the situation, but events were about to take a dramatic turn.

Act 1 - The Great Block

On September 25, Matt Mullenweg escalated the issue by publishing a new post on WordPress.org titled "WP Engine is banned from WordPress.org".

The opening sentence was: "Any WP Engine customers having trouble with their sites should contact WP Engine support and ask them to fix it". This would be quite hilarious if it weren't so alarming: how could WP Engine possibly fix a block that WordPress.org intentionally implemented to restrict WP Engine's customers?

The post continued:

WP Engine wants to control your WordPress experience, they need to run their own user login system, update servers, plugin directory, theme directory, […]. Their servers can no longer access our servers for free.

Following this announcement, WordPress.org took action by blocking WP Engine's customers from accessing its resources, particularly the marketplace that enables updating and installing plugins and themes.

This ban effectively prevented WP Engine customers from accessing security updates, too, leaving their websites vulnerable to potential threats.

Of course, the community didn’t appreciate this. Consider also that even public administration websites could potentially be left vulnerable, unable to update their plugins or access important security updates. This marked the moment when I, along with many other developers, became aware of the unfolding "WordPress drama".

Act 2 - The On-Again, Off-Again Ban

The ban was lifted on September 27.

On September 30, WP Engine updated its website footer to explicitly state its lack of affiliation with the WordPress Foundation. The revised footer now clarifies that their use of the WordPress, Woo, and WooCommerce names is solely for identification purposes and does not imply endorsement by either the WordPress Foundation or WooCommerce, Inc.

On October 1, WP Engine announced they had implemented their own solution to enable plugin and theme updates and installations.

The same day, the ban was reinstated. As of this writing, it remains in effect.

Act 3 - The Checkbox

On October 8, David Heinemeier Hansson (aka "DHH", creator of Ruby on Rails and co-founder of 37signals) wrote an article titled "Automattic is doing open source dirty". In it, he argues that "Automattic demanding 8% of WP Engine's revenues because they're not 'giving back enough' to WordPress is a wanton violation of general open source ideals and the specifics of the GPL license".

The same day, WordPress.org added a new checkbox to their contributors' login page, requiring people to declare they have no association with WP Engine.

When I first saw a screenshot of this, I thought it was a joke. It wasn't.

Image credits: WordPress.org

Last-minute update (October 14): Just as I was about to hit publish, Matt Mullenweg responded to DHH's post. I'll refrain from summarizing or commenting on it: Read it yourself 😳

Update: Matt has since removed the post. To provide a glimpse of its content, I'll share a couple of key sentences:

DHH claims to be an expert on open source, but his toxic personality and inability to scale teams means that although he has invented about half a trillion dollars worth of good ideas, most of the value has been captured by others

David, perhaps it would be good to explore with a therapist or coach why you keep having these great ideas but cannot scale them beyond a handful of niche customers. I will give full credit and respect. 37signals inspired tons of what Automattic does! We’re now half a billion in revenue. Why are you still so small?

Things get worse with ACF

On October 12, WordPress.org took over the Advanced Custom Fields (ACF) plugin. What does this mean? WordPress forked ACF—one of the most popular WordPress plugins—renamed it "Secure Custom Fields," and published it under ACF's original slug.

Image credits: WordPress.org

You can verify this yourself at https://wordpress.org/plugins/advanced-custom-fields/

The page appears identical, but now it displays "Secure Custom Fields by WordPress.org" instead of "Advanced Custom Fields". This means they've inherited ACF's 2M+ download count and high ratings. More critically, users with ACF installed will automatically update to the "new" Secure Custom Fields plugin.

The Advanced Custom Fields team stated on X "A plugin under active development has never been unilaterally and forcibly taken away from its creator without consent in the 21-year history of WordPress."

To draw a hypothetical parallel, imagine if Microsoft were to fork an npm package and publish their fork under the same name, effectively wresting control from the original publisher, with no clear justification. Wouldn’t it be scary?

Personal Reflections

We've moved on from WordPress and are no longer a digital agency—as you'll read in the next section. So you might think I'd feel "safe" from all this WordPress drama. Instead, I'm deeply concerned about these unfolding events as they are creating ripples of uncertainty across the entire development ecosystem.

As a hosting company, I'd be concerned about offering WordPress hosting services. I might face challenges in advertising them—especially considering the WordPress Foundation's trademark applications for "managed WordPress" and "hosted WordPress"—or feel compelled to remain small to avoid drawing Automattic's attention. See the Managed WordPress trademark application and Hosted WordPress trademark application.

As a plugin development company, I'd be concerned that if my plugin becomes successful, WordPress might take control of it, eliminating the possibility of a viable freemium model.

As a WordPress developer, I'd worry that my chosen hosting platform could inadvertently infringe on trademarks, preventing me from providing timely updates to my clients.

As a corporation with a WordPress website, I'd be anxious about potential inability to access security updates or having plugins whose development slows down or stops entirely.

For the open source community at large, I feel a widespread unease about the WordPress ecosystem's current state. Open source is wonderful, but there's often a company behind these projects that might make decisions contrary to the community's wishes. While open source licenses like MIT or GPL have stood the test of time, murky areas around trademarks or contribution requirements could be discouraging. Typically, a contract with a company offers more explicit guidelines about what's allowed and what's not.

Although I'm not directly involved as a hosting company, WordPress or plugin developer, or a corporation using WordPress, these recent events have left me feeling somewhat uneasy about the broader implications for the tech ecosystem.

My Journey with WordPress

I began developing websites in 1996 at the age of 17, using my Pentium 120 with Windows 95. In 2004, while still in university, I launched my own company—I was a happy "webmaster"!

As a digital agency, we primarily created complex web applications and custom e-commerce systems (initially in ASP.NET, then Node.js and React). But occasionally, clients requested websites too, and WordPress became our go-to choice, because of its ready-made content administration. Advanced Custom Fields became our ally. It helped us overcome the challenges of a blank canvas—where clients might unleash the horrors of green text on red backgrounds in Comic Sans—by providing a more structured and clean WordPress experience.

By leveraging ACF and the ability to fetch data from REST APIs, we could create a self-hosted headless CMS. We paired this with modern React frontend frameworks like Next.js or Gatsby, offering a solid solution.

However, we eventually realized that the gray forms of ACF or a pure headless CMS weren't delivering the optimal user experience for our clients. This realization led us to develop React Bricks, a visual headless CMS based on React, transforming us from a service-based agency into a product company. But that's a tale for another time :)

What is a Universal CMS?

Matteo Frana — Thu, 10 Oct 2024 13:33:23 +0000

1. Definition

A "universal CMS" is a headless CMS that sacrifices a small degree of "purity" (in terms of complete backend-frontend decoupling) to provide a much better content editing experience. This improvement is primarily achieved through inline visual editing.

The term "Universal CMS" first appeared in Preston So's March 2024 article, "Universal CMS: The death of pure headless CMS." However, this concept mirrors the vision of a new CMS type I proposed in my article "The shape of the CMS to come", published on Dev.to in January 2020. As the CEO of React Bricks, I introduced this idea alongside our initial MVP release. We subsequently launched the platform's first official version in March 2020, which can be considered as the first universal CMS ever released.

2. Types of CMS

Before delving into the need for Universal CMSs, let's explore the main types of content management systems available today.

2.1 Monolithic CMS

A monolithic CMS integrates content storage, management interface, and presentation layer into a single software package. Consider a traditional WordPress website as an example. It uses PHP files within the same project for both the content administration interface (which writes to the database) and the template files (which generate HTML from the database content).

2.2 Headless CMS

A headless CMS, in contrast, manages only the backend—content storage and management and exposes content through HTTP APIs (typically REST or GraphQL).

A decoupled frontend web application, which can be built using any modern frontend framework, can consume these APIs. Headless CMSs also allow easy serving of multiple channels, all consuming the same JSON content.

2.3 Hybrid CMS

Hybrid CMSs are monolithic CMSs' response to the multichannel capabilities of headless CMSs. Essentially, monolithic CMSs added HTTP APIs to allow external web or mobile applications to access their content, while maintaining the web frontend coupled within the CMS.

2.4 Website Builders

Website builders, such as Wix or Webflow, are typically hosted SaaS services that allow content editors to visually edit content. While they may have a decoupled internal structure, end users experience them as a unified solution where content is edited, stored, and served. These platforms often provide APIs as well, making them similar to hybrid CMSs—they offer a tightly coupled web content management solution with APIs for third-party use.

2.5 Universal CMS

A Universal CMS offers:

A decoupled backend service for content storage, accessible through APIs
A library or SDK for frontend code, enabling visual editing of content

We'll explore how Universal CMSs work in more detail later in this article.

3. The need for a Universal CMS

3.1 The problem

3.1.1 Monolithic CMS

Monolithic CMSs are falling out of favor today for several reasons:

They don't support modern frontend frameworks, making them unappealing to web developers.
They lack multi-channel content distribution capabilities.
They require self-hosting, burdening developers. Moreover, their coupled infrastructure prevents independent scaling of backend and frontend.
They often rely heavily on third-party plugins, raising concerns about stability and security.
Their user interface is limited—often appearing outdated and lacking customization options.

3.1.2 Hybrid CMS

Adding APIs to a monolith—which leads to a hybrid CMS, doesn’t solve the problems highlighted above, but for the multichannel capability.

3.1.3 Headless CMS

This is why in the past decade we witnessed the rise of headless CMSs. Headless CMSs are an excellent solution for developers. However, since they're decoupled from the frontend, their editing interface consists of aseptic gray forms, losing the visual editing capabilities that monolithic CMSs offered. In this transition, content editors were left behind, as their editing experience significantly deteriorated. Some headless CMSs offer a "preview" feature, allowing users to see a page almost immediately after editing content. However, the editing process still takes place in gray forms, making the content editor's experience far from truly visual.

3.1.4 A bit of history

Throughout the history of content management, we've repeatedly encountered a dichotomy between visual editing layers (great for content editors but not developers) and structured data (great for developers but not content editors).

We saw this with early visual tools like Microsoft FrontPage, which gave content editors too much power, leading to a return to structured content with CGI.

We witnessed it again with full-fledged monolithic CMSs like WordPress, where editors could either have a blank canvas—potentially resulting in Comic Sans green text on a red background—or be restricted by the austerity of ACF gray forms.

3.1.5 Visual Site Builders

This pattern persists today.

Visual website builders like Wix or Webflow are very easy to use, but they lack the flexibility developers need to create pixel-perfect corporate designs. At the same time, paradoxically, they give content editors too much freedom, allowing them to make design choices that may compromise brand consistency—a deal-breaker for corporate clients.

On the other hand, headless CMSs, as mentioned earlier, present content editors with austere, user-unfriendly gray forms, prioritizing developer experience at the expense of user experience.

3.2 Requirements for a new solution

This is why we need to finally find a good solution for every actor involved that:

Allows developers to use a decoupled architecture with a modern frontend framework
Gives content editors an easy-to-use inline visual editing interface, as simple as a word processor
Enables developers to set appropriate constraints on what content editors can do, ensuring the corporate identity and design system remain intact

A Universal CMS is the answer to these requirements.

4. How does a Universal CMS work?

In this section, I'll explore how a Universal CMS works, based on the architecture and functioning of React Bricks—the Universal CMS built by my team and me. As of October 2024, React Bricks is the only Universal CMS available on the market.

4.1 “Lego bricks” of content

Close your eyes and travel back in time to your childhood. Imagine yourself playing with Lego bricks. You had a limited set of unmodifiable, atomic bricks, yet you could create anything! We’ve borrowed this concept, adding a touch of Lego magic to our CMS. Developers can create custom "content bricks" within their preferred modern framework (React-based, in the case of React Bricks), deciding how much freedom to grant content editors. Content Editors then use these bricks to visually compose pages.

This approach addresses all three requirements mentioned earlier:

Developers can leverage modern frameworks like Next.js, Remix or Astro
Content editors enjoy the best possible inline visual editing experience
Developers set appropriate constraints in the bricks' code, ensuring the corporate identity remains intact

4.2 Architecture

Developers create their own custom set of "content bricks" in their repository, using components from the universal CMS's library to enable visual editing (for example Text, Image, Repeater, etc.). Each brick has a unique name within the design system.

The backend APIs are unaware of how content bricks are created in code or how they look. They simply store a JSON representation of the content for every page or entity. You can think of the content for each page as an array of blocks, each containing the name of the corresponding brick in code and all the properties edited by content editors.

The library matches the content in the database with the bricks in the code repository, rendering the correct brick and passing it the necessary properties to display the content. This happens both in the Admin (content management interface) and in the Page Viewer (used in the frontend pages).

4.3 Content Management Interface

As illustrated in the architecture diagram, in a Universal CMS like React Bricks the content management interface resides within the frontend project, sharing the same repository as the bricks and frontend pages. This allows customers to host the website and the content management interface on their preferred hosting platform. This approach differs from the typical headless CMSs, which usually provide a hosted content management interface.

5. React Bricks

React Bricks is the pioneer of Universal CMS, currently leading the market. As of October 2024, it serves over 10,000 users worldwide, powering websites for major corporations like The Weather Channel and Deel. Its client base includes major banks in Italy and France, as well as large e-commerce platforms and corporate websites globally.

In React Bricks, "content bricks" are implemented as React components. Developers can quickly scaffold a complete project using a single CLI command, choosing from popular frameworks like Next.js, Remix, Gatsby, and—in the near future—Astro.

Within the React component’s JSX, the developer can use the visual editing components of React Bricks, like Text, RichText, Image, Repeater, etc. choosing what can be edited visually, the rich text styles allowed for each text, and providing render functions for each style.

Moreover, a brick’s component has a schema property which defines, among other things, the brick's unique name, default properties and the sidebar controls. These controls allow content editors to change component properties as needed.

React Bricks, currently in version 4, offers enterprise-grade features. These include localization, complete Digital Asset Management (DAM), scheduled publishing, advanced SEO capabilities, approval workflows and Single Sign-On (SSO). The platform also provides granular permissions, seamless integration with external data sources, real-time collaboration tools, content versioning, page templates, and automatic backup of content and assets to the customer's S3 storage.

6. Conclusion

In the coming years, I anticipate a significant evolution in the CMS landscape. The emergence of Universal CMSs is expected to gain momentum, marking the beginning of a gradual but steady transition from the headless paradigm towards the more user-friendly “universal” paradigm. As developers and content creators alike recognize the benefits of this new approach, we can expect to see increasing adoption across various industries and sectors.

If you're eager to stay at the forefront of this technological shift and provide your customers with cutting-edge content management solutions, I invite you to explore React Bricks. As a pioneer in the Universal CMS space, React Bricks offers a unique blend of developer flexibility and content editor ease-of-use.

To learn more about how React Bricks can revolutionize your content management workflow, visit our website at ReactBricks.com. Create a free account to experience the power of true visual editing combined with the flexibility of a headless architecture.

And, of course, let me know your thoughts about universal CMSs!

Where do React Server Components fit in the history of web development?

Matteo Frana — Fri, 26 Jan 2024 23:07:39 +0000

Intro

In this article, I explain why React Server Components were introduced, in the light of the history of web applications development. Understanding where we come from is key to understand the challenges we currently face and the specific issues that Server Components aim to address.

ASP, PHP, what?

When I began developing websites in 1996, I created static HTML websites. These were just HTML files saved on a web server. When a browser sent a GET request, the web server would return the file, and the browser would parse it and display the page on the screen.

Then customers started requesting product catalogs or e-commerce systems. To accomplish this, you need a database and the capability to:

Read from the database and generate HTML pages based on the database content.
Write data from HTML forms into the database (for example, to update a product or place an order).

In the beginning, I used a technology called CGI to develop server applications written in Perl. This technology was later replaced by Microsoft’s ASP (Active Server Pages) and then PHP. PHP, which you may already know, is still powering over 77% of all the websites as of the time of writing (ever heard of WordPress?).

Interactivity happened essentially server-side: sending a request to the server and receiving a response. JavaScript was used for small interactions or animations, such as form validation, image change on hover, image carousels, etc.

The early days of SPA

With the increase of interactivity on websites and complex web applications, developers began to directly interact with the server from JavaScript using Ajax calls (the golden era of jQuery ;). For example, let's consider a form submitted by JavaScript. In this case, the server should no longer return an HTML page, but rather structured data intended to be read by the JavaScript script (such as just "ok" or "error").

As these techniques were used more often, a significant shift in paradigm emerged. This shift had a fundamental impact on both the client and server technologies, changing forever the way web applications were built.

Client-side, new frameworks emerged, to simplify the way HTML (the DOM) is updated in response to interactions or data from the server. The imperative approach of jQuery was not suitable for large client applications, so declarative frameworks were introduced to facilitate one-way or two-way data binding between data and DOM elements. I used Knockout.js for some time, then switched to Angular.js, and eventually settled on React.
Server-side, we witnessed the emergence of APIs, which no longer returned HTML pages but structured data. Initially data was XML sent over the SOAP protocol, and later JSON directly over HTTP, taking advantage of the REST architecture.

Applications created in this way are referred to as Single Page Applications, or SPAs.

This is because all paths are served by a single HTML page (e.g. index.html), where a JavaScript client-side router reads the browser location and renders the appropriate page.

Initially, Single Page Applications (SPAs) were primarily used for data-intensive web applications that required a login interface, such as the admin interface of an e-commerce or production management system. However, the architecture quickly became appealing for creating websites, as well, for several reasons:

It allows for a clear separation of concerns between backend and frontend roles.
From a security point of view, the attack surface of APIs is reduced and well-defined.
When using a Node.js server, the JavaScript language can be used across the entire stack.

Problems of SPAs

Single Page Applications have 2 problems, especially for public websites.

1. SEO

As we saw, the web server returns just a skeleton or empty page, and the actual content is loaded by the JavaScript application. If a search engine's web crawler doesn’t execute JavaScript, it will just see an empty page without any content. This is not ideal for achieving a high ranking in search results, right?

2. Perceived performance

Before the user can see the page content, the following steps take place:

The HTML page is fetched.
The JavaScript file of the single-page application is fetched, parsed and executed.
The SPA requests data from a server and waits for the response.
The SPA renders the HTML based on the received data.

Meanwhile, the user is presented with a blank page or a spinner.

This can be problematic, especially in cases where the application is large, resulting in a longer loading time for the JavaScript file, or if the API server is slow to respond.

Server-Side Rendering to the Rescue

As we saw, Single Page Applications have two issues due to the fact that the page is generated on the client-side using JavaScript executed by the browser, without any content in the HTML sent by the server.

Server-side rendering is a solution to this problem.

If you have a server running Node.js, you can execute JavaScript code on the server. In particular, the server can fetch data, run the React code and render the HTML page. This allows users to immediately see the page as soon as it is fetched from the web server and enables search engines to correctly index the content.

How does it work? Instead of fetching data on the client, each React view (the top component of a route) can declare a static property called, for example, "getData", which is a function that retrieves the necessary data from APIs.

This function is called on the server side and the result is made available to the top component of the view. In this way the entire tree of components for the route can be rendered on the server using ReactDOMServer.renderToString().

I have used this approach before Next.js was created, for an e-commerce system that is still used by over 300 pharmacies in Italy. In Next.js, the equivalent function for “getData” is "getServerSideProps" (or "getStaticProps" for SSG, which will be discussed later).

You see the situation is very similar to what happens with a PHP page, but we are missing a piece: hydration.

Hydration

What we receive from the server is not just a static HTML page with no JavaScript and no interactivity. After the user receives the server-generated page, it continues to work as a Single Page Application, with client interactivity, client-based routing, and so on. How does this work?

Well, the script tag that points to the JavaScript bundle of our app is still present in the HTML code. As a result, it gets downloaded and executed by the browser. However, this time, React takes a different approach. After running the entire app and building the virtual DOM for a specific route, instead of directly writing it to the "root" div, React compares it with the server-generated DOM to ensure they are identical (have you ever seen hydration errors?). Then, React attaches the event handlers that enable interactivity to the DOM. This process is known as "hydration," as if the water of interactivity was being poured into the static HTML page.

If you have a global state manager like Redux (as I did in my e-commerce application) and need to initialize it with the server's status after rendering, from the server code you can inject a script into the HTML page. This script sets a global variable in the window object, where you can store the initial status, serialized as a string. When the app is loaded, it can read this status from the global variable and initialize the client's status (in my example, the Redux store).

A note about Static Site Generation (SSG)

Static Site Generation (SSG) is similar to server-side rendering (SSR), but instead of happening on the public web server that serves your website, it can occur on any machine running Node.js before publishing each new version of the website.

Think of it as having a person visit all the pages of your website on your development machine, saving the generated HTML pages, and then sending them via FTP to the actual web server. This web server can now be a “stupid” server or a content delivery network (CDN) that serves static files without the need of running Node.js.

Typically, the static generation process occurs on a cloud service (such as Netlify or Vercel) connected to your Git repository. Whenever there are code changes in the repository, the cloud service triggers a rebuild and serves the resulting build through a CDN.

Regardless of whether a page is pre-generated by SSG or generated on the fly by SSR, the client-side hydration process remains the same. From now on, when I mention SSR, I am referring to both SSR and SSG.

If you want to learn more about SSR vs SSG (and another concept called ISR), please read my article SSR vs SSG vs ISR. It was written in 2020, but the concepts are still valid.

Problems of Server-Side Rendering

1. Hydration

Reading the paragraph above about hydration, it is clear that the hydration process can be quite burdensome. It consumes time and resources, increasing the "Time-to-interactive" of your website, which negatively impacts page speed metrics. This is the main issue with Server-Side rendering.

Furthermore, when considering that the primary use case for SSR is not interactive web applications, but rather websites, it becomes apparent that the entire hydration process is largely unnecessary, since most components are non-interactive.

After the initial rendering, does a hero unit component really require interactivity or the execution of React code? Not at all, it could simply be plain static HTML!

Server components were designed to address this problem and eliminate the need for hydration when it is not required.

2. Useless bundle size on the client

Since many components are not interactive and should never re-render, sending to the browser the JavaScript code for these components is completely useless.

3. Fetching at component level

Another issue with SSR is that the root component of each route must declare its "getData" function and then make the data accessible to all components in the component tree. This limitation prevents us from fetching data in any component lower down in the tree, as it can only be done at the top level. While we can fetch data using an effect, this would only happen on the client-side, resulting in a loss of the SEO performance advantage provided by SSR.

React Server components

Server components are designed to prevent hydration when it is not necessary.

So, when is hydration necessary? Whenever we have interactions or the need to re-render. For an image carousel, for example, client-side React is required for the animation and user interaction, so the hydration is necessary.

Server Components are rendered just once, on the server, and they don’t have any JavaScript code that can be executed on the client. Therefore, we cannot use hooks like useState or useEffect in server components.

This is why, when adopting Server Components, it is important to determine which components can truly be Server Components and which ones should remain as “Client Components” (our old standard React components) with the client hydration.

By default, when using a RSC-compatible version of React (currently only available in canary releases), all components are treated as server components. However, if we require client interactivity, we can declare a component as a client component by including the use client directive at the top of the file.

Server components will only render on the server, while client components will render on both the server and the client, during the hydration process. The code for server components is not included in the JavaScript bundle, as they will never be hydrated, re-rendered, or have any client interactivity.

So, we have two advantages that address the first two problems:

No client hydration work is required for server components.
The JavaScript bundle size is significantly reduced.

What’s more, we can directly fetch data from APIs in server components. This fetch occurs before the components are rendered server-side. In this way we also solve the third issue we encountered with Server-Side Rendering.

As of the time I am writing this, the recommended way to use Server Components is through the Next.js framework with the App Router.

If you are searching for a headless CMS solution that supports React Server Components, consider exploring React Bricks, co-founded by me, which recently released v4.2, fully supporting server components. It also provides two Next.js starter projects: one is a blank project, while the other one comes with Tailwind CSS, pre-made content blocks, and a blog.

Conclusion

In this post we discussed the problems that React Server Components are addressing in modern web development. We also took a time-machine trip way back in the web development history, to better understand where we come from. I believe that sometimes it’s important to view things from a broader perspective (or maybe it’s because I am getting older? ;).

Now we understand the benefits of React Server Components:

They eliminate the need for client hydration for non-interactive components that don't require re-rendering.
They reduce the JavaScript bundle size, as the JavaScript for Server components is not sent to the browser.
They enable data fetching on the server directly from a single component, rather than just at the route level.

We did not go into the details of how server components are used, the composition rules for server and client components, or the server-only components that use the use server directive to trigger Server Actions. But that’s material for another article 😊.

React, where are you going?

Matteo Frana — Tue, 16 Jan 2024 19:05:29 +0000

I'm writing these random notes as an open letter to the people I deeply trust in the React (and more generally, the open-source) community. People like Tanner Linsley, Laurie Voss, Cassidy Williams, Michael Jackson, Mark Erikson, Kyle Mathews, Sophie Alpert and many others.

In the past few months I’ve been feeling conflicted about React. It started with the days when server components were essentially announced at a framework conference, and the React documentation began suggesting the use of an external framework for React development. After reading Cassidy's post last night and sharing her vision, I felt the urge to express my concerns as well.

I fell in love with React in 2016 when Angular announced Angular 2 and we were worried about the breaking changes. I immediately fell in love with the React community, even though I never actively participated.

I remember the tweets between Sophie Alpert and Dan Abramov. I also remember the first talk at ReactJsDay (Italy) by Michele Bertoli in 2016, which made my eyes sparkle. And I can't forget the 2018 edition of ReactJsDay when Michael Jackson recreated much of React Router live coding in front of us - those were great days!

React has been a winning choice for us, both as a web development agency and now as a product company. I still get emotional when I think about the day (I believe it was January 2nd, 2020) when I showed the first MVP of React Bricks to Guillermo Rauch, who was the first to believe in the project and gave me the confidence to go on.

However, today I see two problems that make me enjoy React a little less and make me worry that new developers might be intimidated by it: ownership and complexity.

Ownership

As for ownership, I don’t particularly like that:

React suggests using a framework to start a project, suggesting to use one of the three main open source frameworks, instead of just React.
During a framework's conference, new React features such as React Server components are introduced to a large part of the community for the first time, as if it was just a framework achievement.
The most popular framework, which has hired some people from the React core team (which is not a bad thing, but certainly provides them with privileged insight into development) uses canary releases, while the last release of React (18.2) is of June 2022. In this way canary features enter the codebase of many new React projects, becoming the “de facto” stable release, but just for the users of a framework that can feel safe leveraging canary features.

Furthermore, features like Server actions, which trigger metered serverless function calls when hosted on cloud platforms, may potentially increase hosting costs for frontend applications in the future. While this is not currently a problem since there is no monopoly and we have the freedom to choose, I would like a way for the community to be guaranteed that tomorrow there will still be multiple choices available. Please understand that I don't see anyone as being "evil" in this regard. Great things can come from the collaboration between a private company and the community. It's simply a matter of separating concerns and responsibilities.

Complexity

I started creating websites in 1996, when I was 17 years old. At that time, you created HTML files and uploaded them to an FTP server to a folder served by a web server. I managed my own physical server (a Pentium 120), housing it at a local Internet Provider. It ran on Windows NT4 IIS as webserver, BIND for DNS, and IPSwitch IMail server for email. Everything was simple and clear.

Nowadays, web development has become more powerful, but also much more complex. We have lost touch with what's happening under the hood, with the introduction of transpilers, bundlers, and frameworks. However, React stands out with its clean one-way data flow. Things got a bit more complicated with hooks (which have some behind-the-scenes black magic :), but it was manageable and, in the end, a good choice.

With Server components, everything is much more complex to grasp. And, the fact that they are the default choice in the most widely used React framework, somewhat forces newcomers to also learn this new paradigm. I understand the advantages of RSC, but now we have two different ways of building things even within the same React framework.

We have recently completed the task of making the React Bricks library compatible with RSC. This required a month of work and thousands of lines of code. However, as a result, the final API for developers is not as clean as before. I am uncertain whether sacrificing simplicity for a slight performance boost will truly benefit our customers. Nevertheless, since it is both the "default" and the shiny new thing, we have to have it.

Meanwhile, there are many interesting things happening outside of the React world, with the new frameworks. I wouldn't like to be a new programmer trying to choose their first framework right now, as the decision is really tough. React is the most popular, Vue is easier to use, Svelte is a cool idea, Astro is really great, and then there are signals and SolidJS by the very smart and humble Ryan Carniato. Qwik is also very smart, I love the approach (it was created by competitors of React Bricks… but I hold them in high esteem :). So… the choice of a base framework is already so complicated!

A dream?

In this complex scenario, it would be beneficial to have a "default, official" React framework that covers the basic needs of building a SEO-friendly website, with routing, SSG, SSR, ISR (and all the permutations of these letters ;). I know the Remix team would not agree on the need for SSG, but I think it has valid use cases. And I would like it to always be self-hostable on a Linux box.

I envision this default framework being developed by the React community, with a steering committee consisting of recognized contributors from the React ecosystem (through a voting process?). I know that usually open source doesn't work in this way, but... I dream of this "probi viri Fellowship of the Ring" making decisions.

This default framework should not aim to include all the shiny new things out there, found in other frameworks like Remix or Next.js, which I use and love. I believe it should serve as a solid starting point created by the community. And I think we have already some great stuff available today to start with (Tanner?).

As for RSC, I think the concept of avoiding hydration is great, but we need a new kind of server-client integration to make them easy to use. If they remain complex, with the current constraints, trading simplicity for performance would not be beneficial for most websites. And probably RSC is losing in terms of performance compared to something like Qwik, anyway, because they are performing the same work twice, processing chunks from serialized JSON on the client. However, this is material for a separate discussion.

Open Questions

So, after this long stream of consciousness, I would like to pose some questions to the community:

What are your thoughts on the future of React?
Do you believe it is feasible to have a community-driven framework without a sponsoring company, but with a sort of elected steering committee? How could this independent steering committee be financially supported by the community or corporate users, in order to maintain its independence?

Matteo Frana
Jan 16, 2023

Visual editing !== No code

Matteo Frana — Mon, 29 Nov 2021 15:03:53 +0000

Belief #1: I believe that a corporate website should be created with code.

Belief #2: I believe that a CMS should offer the best experience to its everyday users: content creators. And the best user experience is visual editing.

Are these beliefs in contrast? Not at all! Follow me.

The problem

If you are a web developer...

...you know it: every corporate website is unique.

You need total control for pixel-perfect corporate image
You must be sure nobody will break the design
You may have ad-hoc interactive features which require a JavaScript framework

If you are a content creator...

... you know it: creating content filling gray forms is boring.

You want to edit visually, like you do in Word or Pages
You want the freedom to compose your page as you need
You want to be sure you won't break things

Solutions

1. No-code tools 🙁

Tools like Wix or Webflow have a great user experience, but they have pitfalls that make them unusable for corporate websites. They are either:

Not flexible: the tools that are easier to use, usually force you to choose one of the proposed graphic templates. Great for a freelancer project, no-go for a corporate website.
Complex: more advanced tools, like WebFlow, are very flexible, but they are more complex to use.
Too flexible: what's more, it's not the content creator business to create the design and tweak CSS parameters. For a corporate website, the design system is created by designers and developers: content creators should not have the ability to alter the the design system. We don't want green text on red background, right?

2. Headless CMSs 😐

Headless CMS ⇒ gray forms ⇒ not great for content creators.

3. React Bricks 😍

React Bricks has the advantages of both Headless CMSs and a No-code tools, without the problems that Content creators have with headless CMSs and that Developers have with No-code tools.

For Developers

Developers create content blocks with code (they are just React components) using the React Bricks library. React Bricks adds the visual editing magic. And it's really fun.
React Bricks provides also the documentation for your design system.

For Content creators

Content creators have a best-in-class visual interface:

They can edit text and images directly as you do in Word or Pages
They can change properties like background color etc. using sidebar controls. They can change only the properties that the developers chose to be editable and with the values that are allowed.

They have all the freedom they want and no more than they need.

Conclusion

Code and Visual editing can go hand-in-hand: to create a corporate website that's easy and fun to edit in a visual way, you need code.
And a bit of magic. React Bricks brings the magic.

Learn more on the React Bricks website

Code, No-code and Low-code for Content Management Systems

Matteo Frana — Sat, 04 Sep 2021 09:21:02 +0000

Introduction

Low-code vs No-code: many articles explain the differences, benefits and drawbacks of the two approaches. In this article I'd like to narrow down the topic to that of content management systems (CMS). I will broaden the use of the term "CMS" to include visual site builders, which are starting to blend in with more traditional tools.

I will focus on how different types of CMS lead to code, no-code or low-code approaches in the front-end development of a website.

We'll start with monolithic CMSs, travel through developer-centric solutions like headless CMSs, look at no-code tools and eventually get a glimpse of the future in a recent new approach.

Monolithic CMSs 🗿

A monolithic CMS such as Drupal or WordPress usually leads to a "low code" experience on the front-end, but, depending on how it is used, it can also be a completely "no-code" or full "code" experience.

I will now use "WordPress" as a synonym for monolithic CMS, as it is easier to say. Keep in mind that WordPress is a great product and nowadays it can be used also as a headless CMS exposing REST or GraphQL APIs.

For very simple projects, where you can just set up a website with a pre-made template and you are good to go, WordPress is a no-code tool.

As soon as you want to change something, WordPress can become a low-code tool, because you can just change some HTML code in the PHP templates and change the CSS files.

If you create templates from scratch, it is a full "code" solution, because you have to write all of your template files in PHP, using the WordPress framework (the "loop"!).

Monolithic CMSs are flexible, as you can choose how much code to write, based on your needs and your skills.

Usually a developer would like to write code to limit what the content creators could do, to avoid having customers breaking the website, for example placing a table that breaks the responsive layout or creating red text over a green background (the designer says thank you).

To do so developers create fixed fields that can be used on a page (for example using Advanced Custom Fields), so that content creators end up filling gray forms instead of writing content in a free way.

Don't get me wrong, content creators don't want to have total freedom and to break the design. They just need to get the job done. And the best way to get the job done is to write content as you do in Pages or Word, which unfortunately is not appropriate for designers, unless you can guarantee that the corporate image remains safe.

And the fact is that many front-end developers would laugh today reading what I said about developers that want to write code in WordPress. Modern front-end developers don't want to see PHP code at all: they want to leverage a modern stack solution, using a JavaScript framework like React, Vue or Angular.

Monolithic CMSs are still by far the most used kind of CMSs and offer a certain amount of flexibility, but, as we saw, they tend to be always a suboptimal solution for at least one of the involved actors (developers, content creators, designers), based on how they are used.

Luckily today there are tools that are more suitable for web agencies working with modern front-end stacks: read on!

Headless CMSs 🤯

With headless CMSs you have the separation of concerns between the back-end (database, APIs, image processing) and the front-end (the website consuming the APIs and rendering the content).

The backend is usually of no concern because it is provided as a service, so the front-end developers can focus on creating the website using a modern stack, for example using a React framework like Gatsby or Next.js.

Headless CMSs require coding: a developer needs to write the code for the front-end website in order to fetch content from the APIs and present it, usually using a JavaScript framework.

Headless CMSs are great for developers, because they have total freedom in choosing the framework they prefer without the hassle of creating the APIs and the Admin interface for content editing. And they offer better performance, scalability and security out of the box.

The problem with headless CMSs is that a core actor in the adoption of the CMS, the Content creator, is not happy with this solution. Why? Because the content creator loses the visual editing experience that he could have with a blank WordPress page (the infamous blank page that horrifies designers and frightens developers).

Visual site builders 🏗️

Visual site builders like Wix or Webflow exhibit a simple point and click interface in order to deliver a user experience that is very similar to that of a word processing software like Word or Pages.

Visual site builders are no-code tools and they are great for Content creators with no particular corporate image needs or no developers available.

In particular, tools like Wix address pure Content creators who don't need to change the graphics and are ok with the provided templates, while more advanced tools like Webflow allow the user to change every aspect of the page content. In one case you cannot express your exact corporate image, in the other one the content creator has too much power, like in the blank WordPress page case.

Either way, content creators may be happy, while designers are not. And developers? They are not really involved in this case (so they are skeptical, I tell you by experience 😉).

The missing pieces 📡

Developers usually prefer a "code" solution like a headless CMS while content creators usually prefer a "no-code" solution like Wix. But... the funny thing is the reason for the like/dislike is not the quantity of code, but something else.

Developers prefer a headless CMS over a monolithic CMS not because they can write more code, but because they can write code in a better way, using better tools, with a better architecture.

Content creators prefer a visual site builder not because they don't have to code: at a corporate level they have developers that can code on their behalf. They prefer a visual site builder because they can have a visual editing experience.

And designers? Well, they need to be able to express the exact corporate image (so no Wix, sorry) and be sure that nobody will break the corporate image (so no "unleashed" WordPress or WebFlow, sorry, sorry).

We need something new. Will it be a no-code tool? A full code solution? Read on!

A new approach ✨

From what we saw, it seems that full code means the ability to reproduce the exact design system and create constraints so that the editors cannot break the design, using a modern development stack.

Is this in contrast with visual editing, the great UX that content creators are looking for?

Well, in a way yes, because for a single developer or a small team, it is impossible to re-create a complex system like Wix for a corporate website.

So what we really need is a development framework that allows developers to create something great like Wix, but with our own corporate design system and constraints, in order to be sure that nobody will be able to (accidentally!) break it.

And this framework should be great for modern front-end developers, keeping the advantages of headless CMSs. It should be a front-end library created with a JavaScript framework like React, Vue or Angular, with a decoupled API as a service.

And what about the "design system" thing? What is it? Let's simplify: it is a set of content blocks with a designer-designed design that can be used in your content. Ok, so we need a way to create content blocks with React (or Vue, or Angular) with visual editing that save content on headless APIs as a service.

Is it code? No-code? Low-code? Well, at the moment it could be a solution where you have to write code using this library, but the library takes care of many things for you, like calling APIs, wiring the visual editing to your content blocks, rendering on any framework like Next.js or Gatsby, etc. So we can say such a solution is a low-code one. You just write the components, the library does the magic. And clearly the experience for the content creators is completely no-code, a no-code tailor-made for them: no useless power, but comfortable constraints.

Is it the future or... now? 🛸

Well, it is just now. I know two CMSs that follow this philosophy, Tina and React Bricks, both working with React. Tina works with Next.js, React Bricks works with Next.js and Gatsby. They have a similar idea behind them, but different approaches.

Tina has an experimental feature for visual editing ("inline editing") while React Bricks has been created from day one around the core concept of visual editing. React Bricks is born to be a one stop shop where content is persisted on APIs as a service and image processing is done by the same APIs, while Tina started as a Git-based CMS and it leverages an external service (Cloudinary) for image processing.

And... I created React Bricks, with the help of my team.

Ok ok, so I am biased. I am biased because I believe so strongly in what I say here that I founded a start-up based on this concept. I turned a profitable software house working for customers into a product-centric bootstrapped startup.

I believe this is the way we can create great user experiences for everybody: content creators, developers and designers. I believe this is the way people will edit websites very soon. And they will have fun. Again.

BTW, if you want to have a look at React Bricks... 😉

https://reactbricks.com

React CMS: The missing link

Matteo Frana — Tue, 29 Jun 2021 15:39:18 +0000

You are a developer. You love your headless CMS.
Having an API with no hassles and a modern front-end feels great.

Do you think your users are happy too? Think again.

What content creators want

Content creators want to have a solution that is easy and inspiring to use, possibly with no instruction to read.
Wix is such a tool, with its point and click interface.
An headless CMS, with its gray forms and complex interface, is neither easy nor inspiring.

What about designers?

Designers want to be able to express the corporate design system and be sure that nobody will ever break it.
This is why they don't like visual editing, as it often implies too much freedom. Designers want flexibility (for themselves) and constraints (for content creators).

Are you really happy?

Do you like going back and forth between your headless CMS to define fields and your code to fetch these fields and use them in your React app?
Wouldn't it be great if you could save time, stay in your editor and define there your fields, as you do for the props of React components?

The missing link

The missing link is a framework that has decoupled APIs as a service, but lets you define your content blocks as components (for example React or Vue components), providing some magic to enable visual editing over the texts and images. The props of this components enforce constraints so that designers can be sure that nobody will break the design. As a plus, it would be great if the schema of components could self-document itself.

I didn't find the missing link...

... so I created it ;P
Its name is React Bricks.

How does it work?

It’s just React

Content blocks are React components. No back and forth between the front-end and the headless CMS. Define the fields as props on your component, get visual editing for free from React Bricks <Text>, <RichText>, <Image>, <Repeater> components.
Props like background or anything you need can be changed via sidebar controls (you can choose a standard control like text, number, select, color, etc. or provide a custom component).

Great editing experience

The editing interface is very easy and familiar with Visual editing and a Sidebar to change props, with no way to break the design.
In the Playground you get the documentation for all of your content blocks for free.

Is it flexible enough?

You can configure everything: add custom fields on the page accessible via hooks, provide your own components for rich text rendering or for the sidebar controls, validate props, change ui like logo or responsive breakpoints, set user permissions...

Is it fast?

You bet! The starter projects use the latest Next.js versions with a blazing fast statically generated website.
Images are optimized for responsive view and lazy load and served from a fast global CDN.
You can provide a build web hook to let your editors trigger a rebuild on the server with the click of a button.

Developer experience

React Bricks is written in TypeScript and fully typed.
Scaffold a project in seconds using the CLI.
The Documentation is very complete.
You may start from the Step-by-step Tutorial where you gain points... with a final surprise!

Ok, but you are biased!

Of course I am, but I am sincere when I tell you that I love creating "bricks" of content in React and seeing our customers happy while creating content.
But don't take my word for it. We have big startups like CapBase and Casavo powering their websites (and empowering their marketing) with React Bricks. And Swizec Teller wrote a great post about React Bricks.
// Detect dark theme var iframe = document.getElementById('tweet-1237872398889701378-960'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1237872398889701378&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1374480533955047424-2'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1374480533955047424&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1374479894692818950-987'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1374479894692818950&theme=dark" }
// Detect dark theme var iframe = document.getElementById('tweet-1359186869402013699-66'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1359186869402013699&theme=dark" }

What do you think about it?

Please, let me know what do you think about React Bricks.
What do you like (or not) about it? What would you use it for? How may I help you start with a project?

Last thing: see me explain why React Bricks will change the way we edit websites

Static Site generation impact on API Servers

Matteo Frana — Tue, 07 Apr 2020 14:51:56 +0000

Does the new trend of Static site generation have an impact on API server resources? Let’s see!

What is Static Site Generation?

With Static Site Generation, a website dynamic content is generated via a build process.

The result of the build process is a static website: something like a 1996 pure HTML website, but often with very smart JavaScript tricks to preload content when it is likely to be needed, obtaining a perceived performance which is the best you can have.

All the calls to external resources that are needed to gather content and generate the pages (for example a CMS API) are made during the build process.

Then, the resulting static website may be hosted on a CDN, with no other call to the APIs.

In this way the website is:

Super fast (static content + CDN + preload tricks)
Very secure, as the attack surface of a static website is very limited
Less demanding on API / DB server resources

If you like to see the differences between Server Side Rendering and Static Site Generation, see this post.

Note

Actually, the static website could need API calls at run time: if we think of an e-commerce, all the product pages may be statically generated, but the order management requires API calls to create an order. Anyway, these “POST” calls typically represent a small part of all the API calls to “GET” the content.

Impact on API and DB Server resources

As we saw, with static site generation, most of the API calls are at build time, so they are:

From just 1 client machine (the one where the build is launched)
Many at once for each build (all the API calls to build all the pages)
Interleaved by a (more or less) long idle time before the next build

As for the 2nd point, the API calls may be less if we can use an incremental build process, so that just the new / changed / needing frequent updates pages are generated.
For example Next.js recently created an RFC for incremental site generation.

As for the 3rd point, if we think that on a server we may host the APIs / DB of more than one website, the high-CPU / idle cycles may be balanced between the hosted websites.

The same, we have requests in burst and from few clients.

This will mean, on the API server:

Less network usage
Less DB usage (only for builds, not for every request)
Less average CPU usage
CPU/disk usage in bursts
A higher write / read ratio on the disk (having much less read operations)

In general, the usage on the API server will be much less with SSG, especially with the adoption of incremental builds, which greatly flattens the usage bursts for websites with many pages.

Of course, this is true unless you have a website with 100K pages, just 2 visitors per day and you rebuild it all every minute… 😊

Advantages of a serverless architecture

I manage servers since 1997 (I still jealously guard the Windows NT 4.0 box) and we still manage our servers, so I am "old school", but with SSG, serverless services are great, because:

You need bursts usage, and with serverless architectures you just pay for what you use (so you don't pay during the idle time between builds)
Absolute performance is not required, as the build process is a batch process with no user perceiving the performance. So, even the cold startup time of a lambda function is not a problem here.

Impact on reliability and brand image

With a server side rendered website, if the API server goes down, the site goes down.

With a static generated website, if the API server goes down, we have no immediate impact.
The website is served on the edge by the CDN and works independently of the API server.

We still have an impact, because we cannot update the website content: the users don’t see errors, but stale content, until the API server is restored. The API server in a way becomes less critical.

Even if we have an e-commerce website, with API calls to manage orders, the impact of a failure is limited to the checkout phase, while the website is still visible. In this case, we surely have impact on the income, but less damage on the brand image of the website.

Conclusion

With Static Site Generation, in general, we need less resources on the API server than using server-side rendering.
What’s more, a server admin could sleep better at night, as the impact of the API / DB server failure is less severe and less immediate.

Let me know what you think about this post: I'd be super interested in receiving usage data stats that confirms (or prove wrong) my educated guesses. Thank you.

React Bricks

By the way, if you’d like to build a blazing fast static website using Gatsby or Next.js and keep the WYSIWYG editing that is missing in headless CMSs, you may try our hybrid block-based CMS React-Bricks! It’s now in beta! 🚀

React Hook Form: the best form library?

Matteo Frana — Thu, 02 Apr 2020 12:45:00 +0000

This is a very short post on a library I recently discovered (to build the beta subscription of React Bricks CMS) and which I love: React Hook Form.

I come from Redux Form (which still haunts my old projects), then embraced the great Formik by Jared Palmer.

Today I use React Hook Form everywhere, replacing Formik.

Why?

1. Less and cleaner code

This is the main reason why I love React Hook Form: it has the smallest amount of code of any other library: you just execute a hook and add a ref to your fields. Done.

Validation is added in one second too, using the provided required, min, max, minLength, maxLength, pattern, validate rules.

Out of the box it focuses on the first field with a validation error.
If you prefer, you may use a centralized yup schema.

And... I love Hooks: you completely avoid the wrappers hell problem you typically have with Render Props (in this talk at ReactJsDay I explain why Hooks are superior to Higher Order Components and Render Props).

Here's a simple example, complete with validation:

import React from 'react'
import { useForm } from 'react-hook-form'

const Example = () => {
  const { handleSubmit, register, errors } = useForm()

  const onSubmit = values => {
    console.log(values)
  }

  return (
    <form onSubmit={handleSubmit(onSubmit)}>

      <input
        name="fullName"
        ref={register({ required: true })}
      />
      {errors.fullName && <span>Enter your name</span>}

      <input
        name="email"
        ref={register({
          required: 'E-mail required',
          pattern: {
            value: /^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i,
            message: "Enter a valid email address"
          }
        })}
      />
      {errors.email && errors.email.message}

      <button type="submit">Submit</button>
    </form>
  )
}

Very easy, huh?

2. Documentation

The documentation is a pleasure to read.
It is very well done and also beautiful: to me this is very important.

3. Easy integration with UI libraries

I integrated it very easily with react-select and I wrapped my custom form components in a snap.

No friction here means you can start using it with no worries about how well it would play with your existing components' stack: it plays well.

4. Super light and zero dependencies

Absolutely no dependencies, which is very good from a tech debt perspective and... just 5 KB!

5. Performance

I am not one of those evaluating a library based on a couple of milliseconds of difference, but, also from this point of view, React Hook Form beats them all: it reduces the number of re-renders to the bare minimum and it mounts faster than Formik or Redux Form.

6. Batteries included

Form Builder

React Hook Form comes with a Form Builder which comes in handy, especially for a quick form with simple validation rules.

Dev Tools

It has its own Dev Tools to debug the form status.
I admit that I still haven't used it, but I think it's a nice-to-have plus.

Conclusion

Really, I couldn't ask for more.
So... yes, in my opinion this is the best React form library today.

Try it yourself and let me know your opinion!