DEV Community: Yoav Ganbar

Modern CSS for 2024: Nesting, Layers, and Container Queries

Yoav Ganbar — Thu, 28 Dec 2023 15:29:58 +0000

I’ve written before about how far CSS has come and how it has gotten way better in the past few years, as well as shared some tips to level your CSS game.

But this time of year is a great time to have a look at what a banger-year CSS had. Especially with projects like Interop 2023 and Baseline.

In this post, I want to focus on 3 features you can start using today. One will help you deal with legacy projects, the second can clean up your CSS code many folds, and the third will change the way you approach responsive design.

All of these features are supported in all modern browsers, so there’s no reason to not start using them today!

Let’s dig in.

What we'll be working on

To get something done that might be a real-world scenario, we need some design to work with. I’ve randomly selected this notification card from Loom:

I’ve added the design to Figma, as that’s usually where most UI work starts.

To save time, and not try and recreate this little UI nugget manually, I ran it through Builder’s Visual Copilot Figma plugin to make it generate the code for us.

💡 You can find the code in this link. Also, you can scroll to the last section to see how I generated the code.

Less code with native CSS nesting

Notice the initial code above has some duplication for media queries. Some might like to just take out the CSS rules into one media query.

However, in the age of components, to me, it makes more sense to have each class of styles encapsulate how it should behave in different breakpoints under it.

Also, it would be nice to groups of children so we don’t need to have to use descendant combinators (.parent .child) selectors.

Native CSS nesting is now ready to help with such a task!

In the past, you’d need to rely on pre-processors such as SaSS or Less, but not anymore… Native CSS nesting has landed on all major modern browsers.

Here’s how we could refactor the code:

<article class="wrapper">
 <div class="content">
  <div class="column">
   <img loading="lazy" srcset="..." class="img" />
  </div>
  <div class="column">
   <div class="text">
    <p class="top">
     Record a loom to add a personal touch to your messages
    </p>
    <p class="bottom">
     Add a personal touch to your communication by sending a Loom. Discover
     all the ways you can use Loom
     <a href="#">
      here.
     </a>
    </p>
   </div>
  </div>
  <div class="column">
   <button class="rec-btn">Record now</button>
  </div>
 </div>
</article>

.wrapper {
 /* ... styles */

 @media (max-width: 767px) {
  /* the styles specific for the beakpoint nested under the calss it affects */
 }
}

.content {
 /* ... styles */

 /* nested children */
 .column:nth-of-type(2) {
  width: 44%;
 }

 .column:first-child {
  padding: 0;
 }

 /* nested media query */
 @media (max-width: 767px) {
  flex-direction: column;
  gap: 0px;

  /* nested child affected by media query */
  .column:nth-of-type(2) {
   width: 100%;
  }
 }
}

/* ... more styles */

💡 See the full code in this Codepen link.

After running a character count (not including white spaces), without nesting I was at 975 characters vs with nesting which ended up being 868 characters (at least according to ChatGPT 😅).

It might not seem much with this small example but just think about a decent size project and how much less code and less complexity you can get.

What you can nest

It’s important to note that besides media queries and children of parents, you can nest:

multiple @media rules
@layer (more on that in a bit)
@supports
@scope (Currently only works on Chrome)
@container (more on this below)

More nesting info

Before we got similar syntax to SaSS and Less styled nesting, native CSS nesting had to be done with an & character to explicitly state the relationship between parent and style rules.

Now with general availability in all browsers, you can choose whether to use it or just nest like the good ol’ days. However, it’s important to understand there’s a difference when not using it.

When using the & nested child selectors are relative to the parent element. Whereas, not using & makes you use the child rule selector is the one selecting the elements. That means the child rule selector has the same specificity as using :is().

For a deeper dive into nesting, I recommend going through the MDN docs, reading Adam Argyle’s post, and this post by Ahmad Shadeed.

Say Goodbye to `!important` with CSS `@layer`

The headline is somewhat true. It’s not to say that with @layer you can take a legacy project that is littered with !important changes one or two things and you’re off to the races, able to change styles with ease and add new things without worrying about breaking the existing styles.

However, it can come in handy instead of littering your codebase with !important.

The general idea of @layer is that you can decide on the order of the cascade. In other words, it can help you define the order of precedence in case of the multiple cascade layers.

Let’s have a look at a simple example to understand the syntax:

@layer module, state;

@layer state {
  .alert {
    background-color: brown;
  }
  p {
    border: medium solid limegreen;
  }
}

@layer module {
  .alert {
    border: medium solid violet;
    background-color: yellow;
    color: white;
  }
}

At the top of the file, we declare the layer order. The "state" layer is last and so, it will override the "module" layer. The rest of the code is just the different declarations for each layer.

So, in essence, we can utilize this to override styles in case of a legacy project, or even use it to apply one-off theming.

Let’s imagine our notification card from above is inside some sort of legacy project, to which we do have access to the CSS source.

Let’s also say that we have a new requirement to change the text size of the top section, the text color in the bottom section, and the color of the button.

What we could do in this case is the following:

/* Decide on the cascade layer order */
@layer legacy, new;

/* Add a "new" layer with the overrides we want */
@layer new {
 .text {
  .top {
   font-size: 1.5rem;
  }
  .bottom {
   color: rebeccapurple;
  }
 }
 .rec-btn {
  background-color: hotpink;
 }
}

/* wrap the legacy code with the layer name "legacy" */
@layer legacy {
 /* same code as before  */
 /* ... */
}

Pretty nice, no?

We used both nesting and layers. In the past, to achieve this we would have had to either fight with specificity or add a new stylesheet and make heavy use of !important.

💡 Codepen link.

Bye-bye media queries, hello container queries

CSS Container Queries are a game-changer in the world of responsive design, stepping beyond the limitations of traditional media queries.

Unlike media queries that base responsiveness on the viewport size, container queries allow styling based on the size of a parent container. This shift empowers developers to create more modular, reusable components that adapt seamlessly within different container contexts.

The benefits are clear: enhanced layout control improved component-based responsiveness, and simplified, cleaner CSS.

For instance, let’s take the use of our notification card example code. Using container queries, we can remove almost all of our media queries and dictate what needs to change if the card's width is below our threshold (692px which we arbitrarily decided, is the max-width for our card):

.wrapper {
 /* define the container type */
 container-type: inline-size;
 /* name the container (optional) */
 container-name: notification-card;
 border-radius: 16px;
 border: 1px solid rgba(108, 102, 133, 0.2);
 max-width: 692px;
 padding: 0.5rem;

 /* This media query was kept as you can't target the element which is the container */
 @media (max-width: 767px) {
  padding: 0.5rem;
 }
}

/* ... rest of the code is the same, only media queries removed from classes */

/* what changes once the container is below our threshold */
@container notification-card (width < 692px) {
 .content {
  flex-direction: column;
  gap: 0px;

  /* we can use nesting as well */
  .column {
   width: 100%;
  }
  .column:nth-of-type(2) {
   width: 100%;
  }
 }
 .img {
  margin-top: 40px;
  border-radius: 0;
 }
 .text, .rec-btn {
  margin-top: 40px;
 }
}

💡 Codepen example.

In this example, .wrapper becomes a container, and we can target its child elements to adapt their layout based on the card's width, not the viewport. I don’t know about you, but to me this feels more in line with modern, component-based web development.

Contain yourself

Of course, there are more things to know. For example, there are more keywords we can use besides (width < {value}).

For different logic, we can use the following:

and - allows combining 2 or more conditions (@container (width > 400px) and (height > 400px))
or - like and can be used to combine conditions that apply when one is true. (@container (width > 400px) or (height > 400px))
not - as the name suggests, negates the condition. Allowed only one time per query and can’t be used in combination with and or or.

Other than logical keywords, you can use different descriptors other than width, such as aspect-ratio, block-size, height, inline-size or orientation.

There are also special container query length units.

How we generated the HTML + CSS

All it took was a few simple steps, that can be seeing in this video:

💡 You can check out the initial output here.

Granted, it’s not perfect on the first go, but it was something to start with. We were able to convert Figma to HTML in just one click, how cool is that?!

After that, I copied it to Codepen.io, and tweaked it.

Visual Copilot automatically made all the code responsive, but it has made some weird assumptions and class naming here and there, (this is using the free “fast” code generation, which is getting better every day 🙂, and using the “quality” tab yields better results).

After that I’ve made a few changes like better class names, semantic tags, and fixed some responsive issues (you can see the cleaned up code in this Codepen link).

Conclusion

There you have it, 3 new CSS features to start using in the new year.

CSS has truly transformed into a mighty tool in the web dev arsenal, especially with these killer features.

Embracing the power of native CSS nesting and @layer can produce smarter, cleaner style sheets.

But the real showstopper? CSS Container Queries. They're rewriting the rules of responsive design, making our lives as devs a whole lot easier. No more wrestling with media queries for every little tweak. Just set your container's size and watch as your components adapt like magic.

It's not just about writing less code; it's about writing smarter, more efficient code.

The future of web design is looking pretty darn exciting, and we're just getting started! 🚀💻🎨

What do you say? Would you start using these in your projects?

Introducing Visual Copilot: a new AI model to convert Figma designs to high quality code in a click.

No setup needed. 100% free. Supports all popular frameworks.

Try Visual Copilot

Astro + Qwik: Houston, we have Resumability!

Yoav Ganbar — Wed, 20 Dec 2023 15:19:41 +0000

Originally written by Jack Shelton

Hey Devs! My name is Jack, and I am a freelance fullstack developer based in Texas. I also work on this thing called Qwik UI in my free time. 🙂

The problem

In mid-late 2022, I had the opportunity to try Astro, a server-first, content-focused, and extremely flexible meta-framework on my day job.

It quickly became my go-to for creating landing pages, marketing websites, and even small web apps. If my clients needed something, it was almost always a click and integration guide away.

Astro sites significantly outperformed the previous static site generators I had used. I appreciated the speed and found it intuitive to work with.

Unfortunately, as I added more interactivity, my Astro sites began to slow down, despite Astro being the fastest meta-framework I had used up to that point!

My clients and I took notice of this. I spent a lot of time researching how to improve site speed, but in the end it always felt like an uphill battle of optimizing versus adding the stuff my clients needed.

The journey

In an ideal world, you could build your application, and it would be extremely fast, regardless of the level of interactivity or the size of your page. This appears to be an unsolvable problem. The more components we add, the slower it gets.

I wondered, did it have to be this way? Is it even possible to have a fast and easy development process? Is it the developer’s fault when our apps are slow?

Looking back, I’d say no! Developers should focus on what matters most: building the product! So, how do we solve this issue? For a while, it was a big what if. 😅

That what if quickly became a reality when I discovered Qwik’s resumability. I was 100% certain it was exactly what I was looking for.

So I did some research. I saw a lot of comparisons between the two in terms of performance. April this year I thought “why don’t we use them together?” One is a meta-framework, and the other a UI framework.

Would it still be resumable?

Is Astro’s partial hydration approach going to be a problem with a framework that doesn’t have hydration?

How would it work with islands?

Well, turns out I wasn’t the only one!

After some awesome help from Misko, creator of Angular and Qwik, as well as the Astro core team, I can finally answer that question I had back in April.

Introducing @qwikdev/astro:

Astro’s first resumable UI framework.

Starts fast, stays fast

One of Astro's key features is Zero JS, by default.

Unfortunately, this is usually not the case after adding a JavaScript framework and any subsequent components.

If we want to introduce interactivity with a framework, such as React, Vue, Svelte, and so on, the framework runtime is then introduced. The number of components added to the page also increases linearly O(n) with the amount of JavaScript.

Adding Qwik

Qwik builds on top of Astro's Zero JS, by default principle and then some. Thanks to resumability, the components are not executed unless resumed. Even with interactivity, the framework is also not executed until it needs to be. It is O(1) constant, … with zero effort on the developer.

This integration for Astro enables resumability, fine-grained lazy loading, and many of the Qwik core stuff we know and love.

This includes all of the Astro goodies, like view transitions, MDX collections, and the hundreds of integrations that Astro provides.

So where would @qwikdev/astro make sense?

You can use it anywhere you’re currently using a framework component in Astro! Using Qwik and resumability should significantly speed up your site.

Do Qwik components need hydration directives?

Short answer, no!

In other UI frameworks, a hydration directive, such as client:only or client:load, would be needed for interactivity. However, these are not needed with Qwik because there is no hydration!

When using Qwik inside a meta-framework like Astro or Qwik City, components are loaded on the server, prefetched in a separate thread, and "resumed" on the client.

For example, here's how we use a Qwik counter component in Astro.

counter.tsx

import { component$, useSignal } from "@builder.io/qwik";

export const Counter = component$(() => {
  const counter = useSignal(0);

  return <button onClick$={() => counter.value++}>{counter.value}</button>;
});

index.astro

---
import { Counter } from "../components/counter";
---

<html lang="en">
  <body>
      <h1>Astro.js - Qwik</h1>
      /* no hydration directive! */
      <Counter />
  </body>
</html>

Does resumability work?

Yes! We can lazily execute code on interaction, just like using Qwik with Qwik City.

Here, we are refreshing the page, and you'll notice that nothing was executed until the button was clicked. Without resumability, our `` component would have been executed on page load.

The 402 byte q-chunk is our Counter's onClick$ handler.

What's in that 17.61kb chunk?

That's the framework! We do not execute it until it is needed. In this case, it is gzipped using SSG.

How about islands?

Instead of islands, we have Qwik containers! These fit quite well into Astro’s island model, having similar limitations.

Below is an example of a Qwik container in Astro. In the DOM, you'll notice there aren't any `` custom elements. This is because, to Astro, Qwik appears as static data.

This is just the beginning! You can try out the integration in Alpha today, by running:

npx astro add @qwikdev/astro

💡 This integration is currently in Alpha release. We encourage you to try it and share your feedback. If you run into any problems, open up an issue in our GitHub Repository.

You can also view the package on NPM, Github, Qwik integration page, and the Astro integration page.

Join the fun and contribute!

Stay awesome devs,

-Jack

💡 Tip: Visit our Qwik hub to learn more.

Introducing Visual Copilot: a new AI model to convert Figma designs to high quality code in a click.

No setup needed. 100% free. Supports all popular frameworks.

Try Visual Copilot

Read the full post on the Builder.io blog

Bun vs Node.js: Everything you need to know

Yoav Ganbar — Thu, 21 Sep 2023 15:01:06 +0000

Written by Vishwas Gopinath

On September 8th, there was fresh buzz in the JavaScript community: Bun v1.0, created by Jarred Sumner, had arrived. But with all the talk, many are left wondering: What's the essence of Bun? Why is everyone drawing parallels with the tried-and-true Node.js? Is Bun just another fleeting trend, or is it here to redefine the game? In this article, let’s dive deep into Bun, check out its features, and find out how it compares to the well-established Node.js.

What is Bun?

Bun is a super fast all-in-one toolkit for JavaScript and TypeScript apps. The beauty of Bun lies in its ability to streamline the development process, making it smoother and more efficient than ever. This is possible because Bun is not just a runtime, it's also a package manager, a bundler, and a test runner. Imagine having a Swiss Army knife for JS development; that's Bun for you.

What Bun solves for

The inception of Node.js in 2009 was groundbreaking. However, as with many technologies, as it grew, so did its complexity. Think of it like a city. As a city expands, traffic congestion can become a problem.

Bun aims to be the new infrastructure that alleviates this congestion, making things run smoother and faster. It's not about reinventing the wheel but refining it, ensuring that while we get the speed and simplicity, we don't lose the essence of what makes JavaScript unique and powerful.

Bun is designed as a faster, leaner, more modern replacement for Node.js so let’s take a closer look at some comparison. But first let’s discuss one other topic.

Node.js versus Deno versus Bun

When discussing the evolution of JavaScript runtimes, it's hard to overlook Deno. Ryan Dahl, the creator of Node.js, introduced Deno as a new runtime that aimed to address some of the challenges and regrets he identified with Node.js.

Deno is a secure runtime for JavaScript and TypeScript. It directly addresses many of the shortcomings of Node.js. For instance, Deno natively supports TypeScript without the need for external tools. Unlike Node.js, where scripts have broad permissions by default, Deno adopts a security-first approach requiring developers to explicitly grant permissions for potentially sensitive operations, such as file system access or network connectivity.

While Deno presents a compelling alternative to Node.js, it hasn't matched Node.js's widespread adoption. Therefore, this article centers on contrasting Bun with the well-established Node.js.

Getting started

With Bun, we can scaffold an empty project with the command bun init -y. We have a few files generated and in index.ts, add a line, console.log("Hello, Bun!"). In the terminal, run the command bun index.ts to see “Hello, Bun!” logged.

Bun versus Node.js: JavaScript runtime

A JavaScript runtime is an environment which provides all the necessary components in order to use and run a JavaScript program.

Both Node.js and Bun are runtimes. Node.js is primarily written in C++ where as Bun is written with a low-level general purpose programming language called Zig. But that is just the tip of the ice berg. Let’s take a closer look at other differences when treating Bun as a runtime alone.

JavaScript engine

A JavaScript engine is a program that converts JavaScript code we write into machine code that allows a computer to perform specific tasks.

While Node.js uses Google's V8 engine that power's Chrome browser, Bun uses JavaScriptCore (JSC), which is an open source JavaScript engine developed by Apple for Safari.

V8 and JSC have different architectures and optimization strategies. JSC prioritizes faster start times and reduced memory usage with a slightly slower execution time. On the other hand, V8 prioritizes fast execution with more runtime optimization which may lead to more memory usage.

This makes Bun fast, starting up to 4x faster than Node.js.

Summary: bun ran 2.19 times faster than deno and 4.81 times faster than node

Transpiler

While Node.js is a powerful runtime for JavaScript, it doesn't natively support TypeScript files. To execute TypeScript in a Node.js environment, external dependencies are required. One common approach is to use a build step to transpile TypeScript (TS) into JavaScript (JS) and then run the resulting JS code. Here's a basic setup that uses the ts-node package:

1. Installation

npm install -D typescript ts-node

2. Script configuration

In your package.json, you can set up scripts to streamline the process:

{
  "scripts": {
    "start": "ts-node ./path/to/your/file.ts"
  }
}

3. Execution

With the above script, you can easily run your TypeScript file:

npm start

In contrast, Bun offers a more streamlined approach. It comes with a JavaScript transpiler integrated into the runtime. This allows you to directly run .js, .ts, .jsxand .tsx files. Bun's built-in transpiler seamlessly converts these files to vanilla JavaScript, facilitating immediate execution without additional steps.

bun index.ts

The difference in speed is magnified when running a TypeScript file as Node.js requires a transpilation step before it can be run.

ESM and CommonJS compatibility

A module system allows developers to organize code into reusable segments. In JavaScript, the two primary module systems are CommonJS and ES modules (ESM). CommonJS, originating from Node.js, uses require and module.exports for synchronous module handling, ideal for server-side operations.

ESM, introduced in ES6, employs import and export statements, providing a more static and asynchronous approach, optimized for browsers and modern build tools. Let's use colors for CommonJS and chalk for ESM, two popular packages for adding colored outputs to the console and to better understand the module systems.

Node.js has been traditionally associated with the CommonJS module system. Here's a typical usage:

// CommonJS in Node.js (index.js)
const colors = require("colors");
console.log(colors.green('Hello, world!'));

For ES modules in Node.js, you have one of two options:

You need to include "type": "module" in your package.json.
Use the .mjs extension.

// ESM in Node.js (index.mjs)
import chalk from 'chalk';
console.log(chalk.blue('Hello, world!'));

The transition from CommonJS to ES modules (ESM) has been a complex journey. It took Node.js half a decade post ESM's introduction to support it without the experimental flag. Still, CommonJS remains prevalent in the ecosystem.

Bun simplifies the module system by supporting both without any special configuration. Bun's standout feature is its ability to support both import and require() in the same file, something not natively possible in Node.js:

// Mixed modules in Bun (index.js)
import chalk from "chalk";
const colors = require("colors");

console.log(chalk.magenta('Hello from chalk!'));
console.log(colors.cyan('Hello from colors!'));

Web APIs

Web APIs, integral to browser-based applications, offer tools like fetch and WebSocket for web interactions. While these have become browser standards, their support in server-side environments like Node.js has been inconsistent.

In earlier versions of Node.js, Web standard APIs commonly available in browsers weren't natively supported. Developers had to rely on third-party packages like node-fetch to replicate this functionality. However, from Node.js v18, there's experimental support for the fetch API, potentially eliminating the need for these packages.

Bun simplifies this by offering built-in support for these Web standard APIs. Developers can directly use stable fetch, Request, Response, WebSocket and other browser-like APIs without any additional packages. Furthermore, Bun's native implementation of these Web APIs ensures they are faster and more reliable compared to third-party alternatives.

Here's an example compatible with both Node.js (v18 and above) and Bun. While it's experimental in Node.js, the same functionality is stable in Bun:

// Experiment fetch in Node.js (v18 and above) and built-in fetch in Bun
async function fetchUserData() {
  const response = await fetch("https://jsonplaceholder.typicode.com/users/1");
  const user = await response.json();
  console.log(user.name);
}

fetchUserData(); // Leanne Graham

Hot reloading

Hot reloading is a feature that boosts developer productivity by automatically refreshing or reloading parts of an application in real-time as the code changes, without requiring a full restart.

In the Node.js ecosystem, you have a couple of options for achieving hot reloading. One popular tool has been nodemon, which hard-restarts the entire process:

nodemon index.js

Alternatively, starting from Node.js v18, there's an experimental --watch flag introduced:

node --watch index.js

Both methods aim to provide real-time reloading of the application as code changes. However, they might have different behaviors, especially in certain environments or scenarios.

For instance, nodemon can lead to disruptions like disconnecting HTTP and WebSocket connections, while the --watch flag, being experimental, might not offer the full suite of features and has some reported issues in the GitHub issues.

Bun takes hot reloading a step further. By running Bun with the --hot flag, hot reloading is enabled:

bun --hot index.ts

Unlike the Node.js methods that might require a full process restart, Bun reloads your code in-place without terminating the old process. This ensures that HTTP and WebSocket connections remain uninterrupted and the application state is preserved, providing a smoother development experience.

Node.js compatibility

When transitioning to a new runtime or environment, compatibility is often a primary concern for developers. Bun addresses this by positioning itself as a drop-in replacement for Node.js. This means that existing Node.js applications and npm packages can seamlessly integrate with Bun without any modifications. Key features that ensure this compatibility include:

Support for built-in Node.js modules such as fs, path, and net.
Recognition of global variables like __dirname and process.
Adherence to the Node.js module resolution algorithm, including the familiar node_modules structure.

Bun is still evolving. It's tailored to enhance development workflows and is ideal for environments where resources are limited, such as serverless functions. The team behind Bun is striving for comprehensive Node.js compatibility and better integration with prevalent frameworks

While Bun ensures compatibility with Node.js, it doesn't stop there. Bun ships with highly-optimized, standard-library APIs for the things you need most as a developer.

Bun APIs

Bun.file()

Lazily load files and access their content in various formats. This method is up to 10x faster than its Node.js counterpart.

// Bun (index.ts)
const file = Bun.file("package.json");
await file.text();

// Node.js (index.mjs)
const fs = require("fs/promises");
const fileContents = await fs.readFile("package.json", "utf-8");

Bun.write()

A versatile API to write data to disk, from strings to Blobs. It writes up to 3x faster than Node.js.

// Bun (index.ts)
await Bun.write("index.html", "<html/>");

// Node.js (index.mjs)
const fs = require("fs/promises");
await fs.writeFile("index.html", "<html/>");

Bun.serve()

Set up HTTP server or WebSocket server using Web-standard APIs. It can serve 4x more requests per second than Node.js and handle 5x more WebSocket messages than the ws package in Node.js. This backend capability is reminiscent of how developers use Express in Node.js but with the added benefits of Bun's performance optimizations.

// Bun (index.ts)
Bun.serve({
  port: 3000,
  fetch(request) {
    return new Response("Hello from Bun!");
  },
});

// Node.js (index.mjs)
import http from "http";
const server = http.createServer((req, res) => {
  res.writeHead(200, { "Content-Type": "text/plain" });
  res.end("Hello from Node.js!");
});
server.listen(3000);

Bun also has support for sqlite and password built-in.

Bun versus Node.js: package manager

Bun is more than just a runtime; it's an advanced toolkit that includes a powerful package manager. If you've ever found yourself patiently waiting during dependency installations, Bun offers a refreshingly faster alternative. Even if you don't use Bun as a runtime, its built-in package manager can speed up your development workflow.

Check out this table comparing Bun commands with npm, Node's package manager:

At a glance, Bun's commands might seem familiar but the experience is anything but ordinary. Bun boasts installation speeds that are orders of magnitude faster than npm. It achieves this by leveraging a global module cache, eliminating redundant downloads from the npm registry. Additionally, Bun employs the fastest system calls available for each operating system, ensuring optimal performance.

Here's a speed comparison of installing dependencies for a starter Remix project from cache, comparing Bun and npm:

The bun CLI contains a Node.js-compatible package manager designed to be a dramatically faster replacement for npm, yarn, and pnpm

Moreover, a bun run <command> takes just 7ms, while npm run <command> takes 176ms. While Node.js's npm has been the standard for JavaScript package management for years, Bun really is a speed powerhouse and presents a compelling alternative.

Bun versus Node.js: bundler

Bundling is the process of taking multiple JavaScript files and merging them into one or more optimized bundles. This process can also involve transformations, such as converting TypeScript to JavaScript or minifying the code to reduce its size.

In the Node.js ecosystem, bundling is typically handled by third-party tools rather than Node.js itself. Some of the most popular bundlers in the Node.js world include Webpack, Rollup, and Parcel, offering features like code splitting, tree shaking, and hot module replacement.

Bun, on the other hand, is not just a runtime and a package manager but also a bundler in its own right. It's designed to bundle JavaScript and TypeScript code for various platforms, including frontend applications in the browser (React or Next.js applications) and Node.js.

To bundle with Bun, you can use a simple command:

bun build ./index.ts --outdir ./build

This command bundles the index.ts file and outputs the result in the ./build directory. The bundling process is incredibly fast, with Bun being 1.75x faster than esbuild, and significantly outpacing other bundlers like Parcel and Webpack.

Bun takes 0.17s, esbuild 0.3s, rspack 4.45s, Parcel 2 26.32s, Rollup 32s and Webpack 5 38.02s

A standout feature in Bun is its introduction of JavaScript macros. These allow for the execution of JavaScript functions during bundling, with the results directly inlined into the final bundle. This mechanism offers a fresh perspective on bundling.

Check out this example where Bun's JavaScript macros are leveraged to fetch a username during the bundling process. Instead of making a runtime API call, the macro fetches the data at bundle-time, inlining the result directly into the final output:

// users.ts

export async function getUsername() {
  const response = await fetch("https://jsonplaceholder.typicode.com/users/1");
  const user = await response.json();
  return user.name;
}

// index.ts

import { getUsername } from "./users.ts" with { type: "macro" };
const username = await getUsername();

// build/index.js

var user = await "Leanne Graham";
console.log(user);

While Node.js has its established bundling tools, Bun offers an integrated, faster, and innovative alternative that could reshape the bundling landscape.

Bun versus Node.js: test runner

Testing is a crucial aspect of software development, which ensures that code behaves as expected and catches potential issues before they reach production. In addition to being a runtime, a package manager and a bundler, Bun is also a test runner.

While Node.js developers have traditionally relied on Jest for their testing needs, Bun introduces a built-in test runner that promises speed, compatibility, and a range of features that cater to modern development workflows.

Bun's test runner, bun:test, is designed to be fully compatible with Jest, a testing framework known for its "expect"-style APIs. This compatibility ensures that developers familiar with Jest can easily transition to Bun without a steep learning curve.

import { test, expect } from "bun:test";

test("2 + 2", () => {
  expect(2 + 2).toBe(4);
});

Executing tests is straightforward with the bun test command. Moreover, Bun's runtime supports TypeScript and JSX out of the box, eliminating the need for additional configurations or plugins.

Migrating from Jest or Vitest

Bun's commitment to compatibility shines through its support for Jest's global imports. For instance, importing from @jest/globals or vitest will be internally re-mapped to bun:test. This means that existing test suites can run on Bun without any code modifications.

// index.test.ts
import { test } from "@jest/globals";

describe("test suite", () => {
  test("addition", () => {
    expect(1 + 1).toBe(2);
  });
});

Performance benchmarks

Bun's test runner is not just about compatibility; it's about speed. In a benchmark against the test suite for Zod, Bun proved to be 13x faster than Jest and 8x faster than Vitest. This speed advantage is further highlighted by Bun's matchers, which are implemented in fast native code. For instance, expect().toEqual() in Bun is a staggering 100x faster than Jest and 10x faster than Vitest.

Whether you're looking to migrate existing tests or start a new project, Bun provides a robust testing environment that aligns with modern development needs.

Conclusion

Node.js has long been a cornerstone in the JavaScript world, setting benchmarks and guiding developers. However, Bun is stepping onto the scene as a noteworthy challenger, pushing boundaries.

While it's still early days for Bun, the buzz it's generating is undeniable. Currently, it's optimized for MacOS and Linux, and while Windows support is in progress, some features are still on the horizon. With all it offers, Bun is certainly a toolkit you should consider exploring.

Visually build with your components

Builder.io is a visual editor that connects to any site or app and lets you drag and drop with your components.

Try it out Learn more

// Dynamically render your components
export function MyPage({ json }) {
  return <BuilderComponent content={json} />
}

registerComponents([MyHero, MyProducts])

Read the full post on the Builder.io blog

A First Look at HTMX and How it Compares to React

Yoav Ganbar — Mon, 18 Sep 2023 20:33:22 +0000

For a while now, we've had heavyweights like React taking center stage in the world of dynamic web apps. While they're powerful, sometimes they can feel like overkill, especially if you're more of a backend champ navigating the frontend labyrinth.

Now, there’s a fresh perspective on the block: HTMX. It gracefully bridges that space between classic server-side rendering and today's client-side interactivity. No need to juggle a ton of JavaScript; HTMX has got you.

Curious about HTMX? In this article, we’ll unpack its features, the advantages it offers, and see how it sizes up against the well-known development giants. Let’s get into it!

Web dev's wild ride

Once upon a time, web pages were just static displays. You wanted a change? Update that HTML by hand. But the web's appetite grew, craving more action, more interaction. JavaScript entered the game, turning pages into lively stages.

Fast forward to the AJAX game-changer in the 2000s. No more full page reloads – it was all about that sleek, seamless vibe. And jQuery? It made AJAX cool and way more developer-friendly.

Next chapter: Frameworks. React, Vue, and Angular stepped in, bringing structure but also, well, some brain-teasers for the backend folks.

Today? Tools like HTMX hint at a new era. They're asking, "Why not mix the best of both worlds?" Dynamic and sleek, but without the heavyweight lifting. Just check the buzz from DjangoCon 2022.

HTMX explained

The heartbeat : What's HTMX's jam? Keeping things simple. Dive deep into web wizardry without ditching your good ol' HTML. It spices up HTML, sprinkling attributes that unleash dynamism without you diving deep into JavaScript jungles.
The magic : No separate script spells here. HTMX tosses custom attributes into your regular HTML tags. User taps a button? Boom, those attributes whisper AJAX-like requests. Servers hit back, and HTMX refreshes that content, smooth and easy. Logic's chilling server-side, giving client-side scripting a lil' break.
Plays well with others : And get this, HTMX buddies up with your go-to tech. Rocking with Django or vibing with Flask? HTMX slips right in, boosting your game without a total remodel.
Lean & mean : In a universe where chunky frontend giants rule, HTMX steps up as the slick alternative. It's not here to boot out the big guns like React or Vue. It's that streamlined choice when the heavyweights might just be a bit much.

HTMX: rethinking interactivity

When HTMX comes into play, the dynamic of web interactivity shifts. It's about delivering function without the heavy pull of typical JavaScript setups.

Dynamic content on-the-go

As users navigate content, HTMX ensures a seamless feed without reloading the entire page.

<div
  hx-get="/more-content"
  hx-trigger="revealed"
  hx-indicator="#loadingIndicator"
>
  Starting Content
</div>
<div id="loadingIndicator">Fetching...</div>

Behind-the-scenes form submissions

Forms operate in the backdrop, updating just the specific parts of the page that matter.

<form hx-post="/submit-form" hx-swap="outerHTML" hx-target="#formResponse">
    <input type="text" name="data">
    <button type="submit">Send</button>
</form>
<div id="formResponse">Here's the response.</div>

Auto updates

Things like live score updates? HTMX handles them, no manual refreshes required.

<div hx-get="/latest-scores" hx-trigger="every 10s" hx-target="#scoreDisplay">
    <span id="scoreDisplay">Starting Score</span>
</div>

Managing UI elements

UI components, including pop-up modals, are effortlessly controlled.

<button hx-get="/modal-content" hx-swap="afterend" hx-target="#modalContainer">
    Show Modal
</button>
<div id="modalContainer"></div>

Syncing with server logic

Operations like adding to a cart align smoothly with server-side actions.

<button hx-post="/add-to-cart" hx-swap="outerHTML" hx-target="#cartStatus">
    Add Item
</button>
<div id="cartStatus">Added to cart.</div>

From these examples, it's clear: HTMX offers a streamlined approach. Melding perfectly with server-side mechanics and minimizing the dense client-side scripts.

The technical stuff: how HTMX works

Understanding the mechanics of HTMX is crucial for developers looking to harness its full potential. While its syntax is reminiscent of standard HTML, the underlying processes are what set HTMX apart.

Extending HTML

At its core, HTMX is about extending HTML's capabilities. It introduces new attributes that, when added to standard HTML tags, enable dynamic behaviors without the need for additional scripts.

<div hx-get="/update-content" hx-trigger="click">
  Click to Update Content
</div>

Server communication

HTMX seamlessly communicates with the server. When an event specified by hx-trigger occurs, HTMX makes an AJAX request. The server processes this request and sends back a response.

<button hx-post="/submit-data" hx-trigger="click">
  Submit Data
</button>

Swapping content

One of HTMX's standout features is its ability to swap content on the page based on the server's response. The hx-swap attribute dictates how this content replacement occurs.

<div hx-get="/fetch-data" hx-trigger="load" hx-swap="innerHTML">
  Data will load here on page load.
</div>

Handling events

HTMX provides a robust event system. Developers can listen for specific events, such as htmx:afterSwap, to execute custom logic after HTMX has updated content.

document.body.addEventListener('htmx:afterSwap', function(event) {
  console.log('Content has been swapped!');
});

Integration with CSS

HTMX works seamlessly with CSS. For instance, developers can use the hx-indicator attribute to display a loading spinner, leveraging CSS animations.

<div hx-get="/load-content" hx-trigger="click" hx-indicator="#spinner">
  Click to Load
</div>
<div id="spinner" class="hidden">
  Loading...
</div>

Error handling

In the event of an error, such as a failed AJAX request, HTMX provides mechanisms to handle these gracefully, ensuring a smooth user experience.

<div hx-get="/fetch-data" 
     hx-trigger="load" 
     hx-swap="innerHTML" 
     hx-swap-oob="true"
>
  Data will load here.
</div>

By offering a blend of familiar HTML syntax with powerful dynamic capabilities, HTMX simplifies the process of creating interactive web applications. It bridges the gap between frontend and back-end development, allowing for rich user experiences without the complexities of traditional frameworks.

Benefits of adopting HTMX

1. Simplicity and learning curve

Unlike comprehensive frontend frameworks that come with a steep learning curve, HTMX offers a more straightforward approach. By extending HTML, it provides a familiar environment for developers, making it easier to get started.

<div hx-get="/load-content">Simple HTMX Example</div>

2. Performance gains

HTMX's lightweight nature means faster page loads. Without the overhead of loading extensive JavaScript libraries or frameworks, users experience quicker interactions and reduced latency.

3. Reduced Client-Side Complexity

By shifting much of the dynamic behavior to server-side logic, HTMX reduces the complexity on the client side. This results in cleaner, more maintainable code.

4. Seamless integration

HTMX is designed to integrate smoothly with existing technologies. Whether you're working with server-side frameworks or databases, HTMX can fit right in without the need for major overhauls.

5. Enhanced user experience

With its ability to update content dynamically without full page reloads, HTMX ensures a smoother user experience. Transitions are seamless, and users aren't disrupted by jarring page refreshes.

6. Cost-efficient development

Given its simplicity and reduced reliance on extensive frontend development, projects using HTMX can often be completed faster, leading to cost savings in development time and resources.

7. Empowerment for backend developers

Backend developers can now play a more active role in crafting the user interface. With HTMX, they can build interactive UI components without diving deep into frontend scripting.

In a world where efficiency, performance, and user experience are paramount, HTMX emerges as a compelling choice for web developers. It offers a balanced blend of power and simplicity, making it a valuable tool in modern web development.

HTMX vs. React: a comparative analysis

In the realm of web development, tools and frameworks are often weighed against each other to determine their strengths, weaknesses, and best use cases. As React is currently the reigning king of frontend, it’s expected one would compare HTMX and React. While they serve similar end goals of creating dynamic web applications, their approaches are different.

Philosophy and Approach :

HTMX : It extends HTML, allowing developers to add interactivity directly within the markup. The focus is on simplicity and leveraging server-side logic.

<div hx-get="/dynamic-content">Load Content with HTMX</div>

React : A JavaScript library for building user interfaces, React emphasizes component-based architecture and a virtual DOM for efficient updates.

function App() {
  return <div>Hello from React!</div>;
}

Learning curve

HTMX : With its HTML-centric approach, HTMX offers a gentler learning curve, especially for those familiar with traditional web development.
React : While powerful, React comes with its own set of concepts like JSX, state, and props, which can be overwhelming for newcomers.

Performance

HTMX : Being lightweight, HTMX ensures faster initial page loads and reduced client-side processing.
React : Thanks to its virtual DOM, React can efficiently update the UI, making it suitable for large-scale applications with frequent updates.

Integration

HTMX : Designed to work seamlessly with existing server-side technologies, making it a plug-and-play solution for many projects.
React : While versatile, integrating React might require additional configurations, especially in projects not built around a JavaScript ecosystem.

Use cases

HTMX : Best suited for projects that require dynamic interactivity without the overhead of a full-fledged frontend framework. It's also ideal for backend developers looking to add interactivity without extensive JavaScript.
React : Perfect for single-page applications (SPAs) and projects that demand a rich, interactive user experience with complex state management.

Community and ecosystem

HTMX : While growing in popularity, its community is smaller compared to established frameworks. However, the quality of support and resources is commendable.
React : Boasts a vast community, a plethora of third-party libraries, and extensive resources, making it a go-to choice for many developers worldwide.

Drawbacks and tradeoffs

Nothing is sunshine and rainbows, and obviously, there are tradeoffs to any tool you use. Below are some things that are important to take into account, and just know, before going all in.

The approach is not new, essentially a variation of Knockout, Alpine, and similar "JS-in-HTML" approaches.
Limited Domain Specific Language (DSL) makes it less convenient — lacks features like syntax highlighting, linting, and static analysis.
No type safety.
Debugging can be challenging for the same reasons.
Bottom line, this approach is really only good for smaller projects where you need just a touch of JavaScript. We've been down this road before with vanilla and jQuery years ago, and we moved on for solid reasons.

Both HTMX and React have their merits. The choice between them boils down to the project's requirements, the team's familiarity with the tools, and the desired development experience. While React remains a dominant force in the frontend world, HTMX is carving its niche, offering a simpler, yet powerful alternative.

HTMX's role in upcoming web development

HTMX is gaining traction in web development, and here's a glance at its potential impact:

1. Blending old and new

HTMX offers a balance, merging server-side rendering's reliability with the zest of modern client-side interactions. It's an appealing solution for dynamic yet efficient web projects.

2. Inclusive development

Not all developers delve deeply into frontend complexities. HTMX provides a platform where backend-focused individuals can also design interactive web pages without wrestling with dense JavaScript frameworks.

3. Prioritizing performance

With online users valuing speed, HTMX's streamlined approach promotes the development of swift and agile web platforms.

4. Adapting to fresh trends

The web world is ever-evolving. HTMX's adaptable design means it's poised to mesh well with emerging technologies and standards.

5. Possible shift in approach

The growing interest in HTMX suggests a potential evolution in web development methods. While substantial frontend frameworks have their place, simpler, efficient tools are gaining momentum.

6. Community expansion

As HTMX garners more followers, its community will naturally grow. This paves the way for additional resources, extensions, and collaborations, enhancing its utility in web development.

In summary, HTMX presents a promising avenue in the realm of web development. It resonates with current developer needs, providing an innovative way to design interactive websites. Its future influence will largely depend on the evolving community and their inventive applications.

Key takeaways

In a constantly changing web development landscape, HTMX has its own lane. It enhances HTML, giving developers a familiar setting and making it easier to dive into web interactivity.

At a time when a web page's speed can define its user experience, HTMX shines with its lightweight nature, ensuring quick loads and silky interactions. It also empowers backend developers, letting them dive deeper into frontend play, bridging the often vast chasm between server logic and client dynamics.

While the frontend world seems captivated by giants like React and Vue, HTMX brings a refreshing take. It challenges the common belief that you need heaps of JavaScript for a dynamic web app, showing there's another path forward.

HTMX might be more than just the latest tool on the block. It hints at a possible evolution in how we think about web development, highlighting the delicate balance between tech intricacies and user experience. As its community grows and more adopt it, who knows where HTMX might lead the future narrative of web development?

One thing for sure is that their Twitter (X) account has got some serious meme game...

We've been working on something...

Don't miss our AI launch event on Oct. 12

Claim your ticket

Read the full post on the Builder.io blog

Finding the Best React CMS: A Comprehensive Guide

Yoav Ganbar — Sun, 10 Sep 2023 13:12:05 +0000

Last updated: September 6, 2023

Choosing the right tools for a React project can be a daunting task, especially when it comes to managing content. Whether you're building a simple blog, an ecommerce app, or a complex enterprise solution, the right Content Management System (CMS) can make or break your project. A CMS not only streamlines the development process but also enhances collaboration, flexibility, and scalability.

But with so many options available, how do you choose the best CMS for your React project? In this guide, we'll explore the benefits of integrating a CMS with React, provide you with the insights you need to make an informed decision and outline the process of integrating a React app with a headless CMS.

What is React?

React is an open-source JavaScript library for building user interfaces. It offers a declarative approach, simplifying UI creation through efficient virtual DOM utilization. With a component-based architecture, developers create encapsulated and reusable components for intricate user interfaces.

What is a CMS?

A content management system (CMS) is a software platform that enables users to create, edit, organize, and publish digital content, such as articles, images, videos and more. Importantly, a CMS allows you to change content on your website without having to make changes in the application code or any other underlying codebase.

React and CMS: an analogy

React is like a team of skilled craftsmen who intuitively understand your vision. You don't need to instruct them on every nail and screw; you just describe the desired outcome, and they bring it to life with precision. Similarly, developers use React in a declarative manner (via JSX) to specify what the web application interface should look like, and React ensures it's rendered seamlessly.

A CMS is like a curated furniture and décor boutique. You can pick ready-made furniture and decorations to fill your rooms. Yet, the beauty of a CMS is that it allows you to modify or reconfigure your interiors independently, without needing the expertise of the craftsmen who originally constructed the space.

Understanding the headless CMS

A headless CMS is a content management system that decouples the content creation and presentation layers. Unlike traditional CMS platforms, a headless CMS does not enforce a specific front-end (the "head") for displaying content.

Instead, it provides APIs (Application Programming Interfaces) that help developers fetch from a single content source and deliver data to any desired front-end, such as single page applications, websites, mobile apps, IoT devices, and more, often leveraging CDNs for faster content delivery.

📖 Explore our visual guide on the concept of a headless CMS for a deeper understanding

Advantages of a headless CMS with React

In the world of React, a headless CMS is often preferred for several reasons:

Flexibility : Developers have complete control over the frontend so they can use their preferred tools and frameworks like React, Next.js, Gatsby, or Remix.
Multi-platform support : Content can be delivered to websites, mobile apps, and even IoT devices.
Real-time updates : Changes to content can be reflected in real-time across all platforms to enhance user experiences.
SEO benefits : By using a headless CMS with React, developers can optimize the site for search engines to improve visibility and ranking.

Embracing a headless CMS paves the way for React developers to craft more dynamic and adaptive applications. This naturally leads to the question: how do you zero in on the perfect headless CMS for your next project?

What to consider when choosing a headless CMS

When integrating a headless CMS with your React app, several concerns might arise. Here's an in-depth look at what to consider:

Ease of use : How friendly is the CMS for developers? Does it integrate well with popular React or a meta framework like Next.js? Is the documentation clear, and are there tutorials to help you get started?
Multi-device presentation : In today's multi-device world, your content must look great everywhere. How easy is it to present the frontend on various devices, including mobile apps, tablets, and desktops? Does the CMS support responsive design and provide tools for testing on different devices?
Content team operation : Content editors and marketing teams need a system that's intuitive and efficient. Does the CMS offer a friendly editor, templates, and workflows that streamline content creation and publishing? How easy is it for non-technical users to manage content?
Collaboration : Collaboration is key in modern development. How collaborative is the CMS? Does it offer features like real-time editing, comments, and permissions that facilitate teamwork? Can multiple users work on the same content simultaneously without conflicts?
Content localization : If your audience is global, content localization is crucial. How supportive is the tool in managing content localization efforts? Does it offer features like multi-language support, currency conversion, and regional customization?
Third-party tool integration : Integration with third-party tools can extend the platform's functionality and streamline workflows. How well does the headless CMS handle plugins and third-party tools and solutions? Is there a wide range of available integrations, and how easy is it to develop custom integrations?
Revision history and backups : Content changes and updates are inevitable. Does the CMS offer automatic backups and a clear revision history? Can you easily revert to previous versions if needed? How are backups stored and secured?
Guides and docs : Comprehensive guides, schema, and docs are essential for both beginners and experts. Are there detailed tutorials, examples, and documentation available? Is there community support through forums, social media, or other channels?
Reliability, performance, scalability, and security : These critical areas can make or break your project. How does the CMS perform in terms of reliability, performance, scalability, and security? Are there regular updates, monitoring tools, and support to ensure the system runs smoothly?
Customer support : What level of customer support is provided? Is there 24/7 support, live chat, email, or phone support? How responsive and knowledgeable is the support team?

Selecting the right headless CMS requires a comprehensive understanding of various factors, from ease of use to customer support. Aligning these considerations with your project's needs will lead to a more streamlined development process. Once you've made the right choice, the next step is understanding how to integrate the CMS into your React application.

Integrating a React app with a headless CMS

Starting a new React app with a headless CMS is a seamless process. Set up a new Next.js app and integrate a headless CMS of your choice. Use the data editor to define your data models and create content entries. Once the content is prepared, publish it. Fetch and render this published data in your Next.js application by consuming the content API from the headless CMS.

Here's a step-by-step tutorial assuming Next.js as the React framework of choice:

1. Create Next.js app : Use the create next app CLI tool to create a new Next.js project with all the necessary dependencies and configurations.

npx create-next-app@latest nextjs-cms-app

2. Integrate headless CMS: Choose a headless CMS that suits your needs. Many offer SDKs, templates, and content modeling tools that make integration a breeze.

npm i your-headless-cms

3. Creating models and content: Define your data models (blueprints) and create content entries (houses). This step involves setting up the structure of your content, defining fields and relationships, as well as validation rules, all of which are stored in a database.

4. Publishing: Use the CMS's user interface to publish your content. You can schedule content, set up workflows, and collaborate with team members to ensure quality and consistency.

5. Connect with frontend: Use REST APIs or GraphQL to connect your content with the React components in your app. This step involves mapping your content to the frontend, ensuring a seamless user experience.

async function LandingPage() {
  const cmsData = await fetch("...//my-cms.com/api/...");
  return (
    <>
      <Header title={cmsData.title} />
      <Hero title={cmsData.heroTitle} image={cmsData.heroImage} />
      // ...rest of the landing page
    </>
  );
}

6. Testing and optimization: Test your application on various devices, optimize for performance and SEO, and make necessary adjustments to ensure a successful launch.

While the headless CMS approach offers flexibility and control, there's an evolving trend in the CMS landscape that further empowers both developers and content creators: the visual headless CMS.

Visual headless CMS

A visual headless CMS bridges the gap between the flexibility of a headless CMS and the user-friendly interface of a traditional CMS. This means that while developers enjoy the freedom to design and structure the user interface, content creators and marketers can design, edit, and preview content without the constant need for developer intervention.

This fusion of features streamlines content creation, offering real-time editing capabilities and clear visualization of content across various platforms. Whether you're a developer, content creator, or marketer, a visual headless CMS provides an enhanced, collaborative approach to digital content management.

Traditional, headless, and visual headless

Traditional CMS platforms like WordPress offer a straightforward WYSIWYG (What You See Is What You Get) editor. When integrated into code, it typically involves fetching data from the WordPress API and then rendering it directly, often without much flexibility in design or structure.

async function Page() {
 const cmsData = await fetch('...//wordpress.com/...');
 return <div dangerouslySetInnerHTML={{ __html: cmsData.html }} />;
}

Headless CMS platforms provide a data editor, allowing developers to control rendering. This approach offers more flexibility in terms of UI design and structure, as content is separated from its presentation.

However, this approach does require more time and effort, as developers need to design schemas, build templates, and wire up APIs to models, among other tasks.

async function Page() {
 const cmsData = await fetch('...//contentful.com/...');
 return (
   <>
     <Header title={cmsData.title} />
     <Hero title={cmsData.title} image={cmsData.image} />
     // ... other components
   </>
 );
}

Visual headless CMS platforms like Builder.io combine the best of both worlds. They offer the flexibility of a headless CMS with the visual editing capabilities of a traditional CMS.

This means content creators can visually design their content while frontend developers maintain control over the structure and rendering. Additionally, the integration process is automated, providing a seamless and enhanced developer experience.

async function Page() {
 const cmsData = await fetch('...//builder.io/...');
 return (
   <>
     <Header title={cmsData.title} />
     <BuilderComponent content={cmsData} />
     // ... other components with visual editing capabilities
   </>
 );
}

From the code and images, it’s evident that while a traditional CMS offers simplicity and a headless CMS provides flexibility, a visual headless CMS merges these benefits, ensuring a comprehensive content management solution for everyone involved.

Frequently asked questions

Drag and drop capabilities

Visual building with Next.js

How can I visually construct pages using Next.js?

Visual editing with CMS

What methods are available for visual editing in a headless CMS?

Builder.io Visual Headless CMS

At Builder.io, we offer a powerful combination of user-friendly visual tools, collaboration-friendly features, and efficient publishing capabilities. We have a Google Chrome extension to easily help you with content editing within the web browser, along with a Figma plugin to make a smoother transition from design to web page. You can incrementally adopt our Visual Headless CMS or rebuild your frontend from scratch.

Get started free

Read the full post on the Builder.io blog

An Overview of 25+ UI Component Libraries in 2023

Yoav Ganbar — Sun, 10 Sep 2023 05:15:45 +0000

UI component libraries can get you up and running on a new project pretty fast. However, if you’re building a product that has a bespoke design, trying to customize the look and feel of these libraries is a grueling task and might lead to unmaintainable code.

There are many UI libraries (or, as some call them, UI frameworks) to choose from, and of course, there are different libraries for different front-end frameworks. You might think that coming up on the end of 2023 the industry may have settled on one or two solutions, but it is far from reality.

The truth is, as with anything in software and the web and something that I say often, that it depends…

The above tweet (X?) by Ryan Florence got me thinking about this subject – not about who is to blame, because that does no good, but more about the reasons why and how we got into this situation.

In this post, I’m going to give a brief overview of the styling solutions that have led us to the current ecosystem, and we’ll look at some of the more common and popular UI libraries out there.

(Boot) Strap in, we’re going on a ride.

History of CSS frameworks and libraries

Back in the day, web designers were hand-writing CSS, which, trust me, was a journey full of twists (for more on this, see CSS The Good Parts). Then the 2000s hit, bringing with them CSS frameworks like Blueprint, 960 Grid System, YUI Grids, and YAML (probably not the YAML you’re thinking of). These frameworks introduced responsive grids and clean UI elements, changing the game.

Just when we thought we'd seen it all, giants like Twitter Bootstrap, Foundation, and Bulma entered the scene. They made development quick and ensured consistent styling, but the flip side? Websites began feeling a bit too...uniform.

Recognizing this, the community pivoted, introducing methodologies like BEM to inject some uniqueness and modular style.

Bottom line? CSS frameworks shifted from solely addressing layout needs to offering comprehensive UI toolkits. But alongside this, methodologies emerged, pushing for more tailored and modular styles.

JavaScript frameworks changed the game

With the emergence of JavaScript frameworks such as Angular, React, and Vue, developers needed a more granular approach to correspond with these new component models.

What is one of CSS’s top features (the “C” in CSS, that is the Cascade) became an issue for these new frameworks.

As such, a new breed of solution was born — CSS in JS. Mostly prevalent in the React ecosystem, libraries such as Styled Components and Emotion allowed scoping styles to components and in so, got rid of the cascade problem.

Atomic design FTW

One key concept that got championed by Web Developer and Designer, Brad Frost, was “atomic design”.

The gist of this concept allows developers and designers to think in this new “componentized” world. The idea is that you should think about a component as a sum of atomic design pieces.

A button, for example, is an atom, a card that holds an image, or some text, and a button - is a molecule. A page, which is consistent with several of these “molecules”, is an organism.

The culmination of the concept has boiled down to CSS frameworks such as Tailwind CSS.

💡 If you want to learn some neat tricks in Tailwind, check out some Tailwind CSS Tips and Tricks Worth Knowing.

The need for a UI framework

You may ask yourself: “Do I really need a UI framework?” The answer might just be NO.

Josh Commeau wrote a very good article on the subject titled: “You don’t need a UI framework”.

Like I’ve said, and I’ll probably keep stating over and over again in any software-related subject - it depends.

💡 Check out “Why Do We Need UI Component Libraries? with Alon Valadji” for a deeper dive.

I once thought that building a design system with Styled Components and Tailwind was the way to go. However, It’s not necessarily the case anymore.

Nowadays, there are many options that might fit your needs, get you started quicker, perhaps avoid the need for a designer at all, or lay a foundation for a complete bespoke design system.

The broken promise of web components

At this point in time, I’d imagine there’d be some sort of Web Component standard that would be usable regardless of your frontend tech stack. However, there’s still no one solution that fits all.

Web Components were initially introduced with the promise of providing a convenient way to create reusable and customizable HTML elements, developed much faster without waiting for the full spec and implementation process.

However, they have faced several challenges that have hindered their widespread adoption in UI development. One of the main issues is the complexity introduced by JavaScript frameworks, which has led to overengineered build processes and dependency graphs.

Additionally, web components have struggled with browser compatibility and standardization. As a result, developers have turned to alternative solutions like React, Angular, and Vue, which offer more straightforward and familiar approaches to building UI components.

Despite the initial promise, web components have not yet become the go-to solution for UI development that they were once envisioned to be.

If we can’t use web components, though, what solutions are available to us?

Types of UI Libraries

Theo Brown, a known YouTuber and tech influencer, recently broke down the different types of UI libraries in one of his videos. I think he did quite a good job in categorizing these into these types:

Extensions of CSS: for example, Sass, Less, Tailwind, CSS Modules, to make stuff look a certain way on your own.
Behavior libraries / Headless: for example, HeadlessUI, Radix, React Aria, for how things behave, not style.
Style systems: such as, TailwindUI, DaisyUI, for a baked-in look and behavior that is up to the developer.
Component libraries: for example, MUI, Ant Design, Mantine, are their own thing. You need to learn how to work with them. (ChakraUI, in Theo’s opinion, is a different beast, sitting somewhere close to “where we want to be”.) ## What makes a good UI library

Here are some key considerations for what makes a good UI framework:

Consistency: The framework should provide consistent UI elements, patterns, and behaviors across the application. This helps users quickly understand how to use the interface.
Flexibility: While being consistent, the framework should also allow for customization and extension to fit the specific needs of different applications. Modular and customizable components are ideal.
Performance: The framework should be optimized for performance. Things like file size, render speed, and efficiency matter, especially on mobile.
Accessibility: Following web accessibility guidelines ensures the framework works for all users. ARIA roles, semantic HTML, and keyboard support are examples.
Documentation: Good documentation and examples make the framework easier to learn and implement. API references, style guides, and code samples help speed development.
Browser Support: The framework should work across modern browsers and degrade gracefully in older ones. Progressive enhancement principles apply.
Community: An active community behind the framework provides discussion forums, plugins, and continued maintenance. This helps sustain long-term viability.
Intuitive: The framework should align with users' mental models and expectations. Leverage natural mappings, consistency, standards, and familiar patterns.
Responsive: The framework should accommodate diverse screen sizes and input methods. Mobile-first and fluid layouts are best practices here.

In summary, a good UI framework balances consistency and flexibility while optimizing for performance, accessibility, and device support. Great documentation, an active community, and intuitive design are also key. Following established UX principles and heuristics throughout helps ensure quality results.

Popular UI libraries

React

The React ecosystem probably has the most UI libraries out there, due to the size of its ecosystem and popularity. As I am more familiar with this world, the list here is longer than other frameworks and is not by any means a complete list of ALL React component libraries.

Component libraries:

Material UI : One of the most popular implementations of Google’s Material Design. MUI offers a wide range of components, and theming options, and has been around for ages. With that being said, you are bound by their system.
Ant Design: A solid option that is been used by a lot of heavy hitters, such as Tencent, Baidu, AliBaba, and more. Supports all modern browsers, SSR, esm, and even Electron. Has also community implementations for Angular, Vue, and more. Does use CSS-in-JS, so expect runtime overhead as well as AntD ways of doing things.
ChakraUI: An emphasis on A11y, meaning it is fully compatible with the WAI-ARIA accessibility standard, has won OSS awards, and has a thriving community. As mentioned, it’s one of the better choices out there as it has a great model for building composable UI, built-in hooks, and great dark-mode support. This is the same team behind Zag.js, which handles UI as state machines. Once again, you’d need to learn the API, and swapping might be hard to do.
Mantine : Another fully featured component library with baked in a11y, more than 100 components, and hooks. Mantine is all TypeScript-based and has a way to override default styling. Once more, there’s a lot to learn on how to use its functions and API to achieve your goals.
Blueprint : A collection of components for building data-intensive interfaces for desktops. It specifically states that it is not designed to work for mobile. It is most likely better for building internal tools, dashboards, and Electron apps. Blueprint is one of the few libs in this list that has a Date Picker component.
React-Admin: As the name suggests, this component library is targeted at building administrator interfaces for B2B (business-to-business), for example, managing users in your system. It is based on Material design and has a neat feature where you can let it “guess” your list views by providing a sample API endpoint for your data.
NextUI: Not to be confused with the React meta-framework, Next.js, this library is built on top of Tailwind CSS, and claims to have a minimal learning curve. Themes are handled by your tailwind.config.js file, a11y out of the box, and there’s dark theme support for all components. Overriding styles is done just by putting in different Tailwind class names.

Headless:

HeadlessUI : The library is only the headless part or behaviors you need to build accessible components. It is specifically designed to integrate with Tailwind, but you could use any CSS solution you like.
React Aria: A library built by the team at Adobe. It is a full-fledged headless solution that handles behavior, accessibility, and internalization. The API surface of this library is mostly a collection of hooks that you can use (pun intended 😂) to build your components. The pre-defined built components of this lib are currently in alpha.
RadixUI : Once only a headless component library, the team recently added themes and some styles. The library’s a11y, and composability features are superb, and I myself have had a great experience with working with it. All themes are exposed via CSS custom properties, which can be easily overridden with CSS.

Hybrid approaches:

ShadCN/UI : A new kid on the block, this library takes a different approach than most of the libraries mentioned here. Instead of npm installing components or the whole lib and adding it as a dependency, you copy-paste code into your own code base. This is to give you full ownership of the components and separate the design from the implementation. It is built with Tailwind and In order to use this tool, you use the CLI to generate your component code and adjust your tailwind.config.js.
KumaUI : Another relatively new contender, Kuma uses zero runtime CSS-in-JS to create headless UI components which allows a lot of flexibility. It was heavily inspired by other zero runtime CSS-in-JS solutions such as PandaCSS, Vanilla Extract, and Linaria, as well as by Styled System, ChakraUI, and Native Base. ### Vue

Being someone who’s a bit unfamiliar with the Vue ecosystem, one thing that I noticed is that a lot of the libraries out there have documentation in Chinese and not in English.

I don’t know about you, but my Mandarin is… How’d I put this? Non-existent. Seems like even if a library has excellent docs, you wouldn’t necessarily know it.

Component libraries:

Quasar: It does not consider itself a library, but more of a framework. That, in my eyes is a bit confusing as it is based on Vue, but the idea is that you can use it to create websites and apps, meaning it uses a CLI to generate different outputs for web, mobile, desktop, SPA (Single Page Apps), SSR (Server Side Rendering), and more.
Vuetify: Claims to be a no design skills required Open Source UI Library with beautifully handcrafted Vue Components. It has all the bells and whistles like most fully-fledged component libraries. Once more, you’d need to know the API to use this library, as well as get “locked in” to their component composition model.
Element Plus: As the website states, Element Plus is “a Vue 3-based component library for designers and developers”. Not sure how it differs from the rest of the pack, but it does have about the same variety of components to choose from. It has over 20K stars and over 150K downloads a week, which indicates its popularity.
VueMaterial: As the name suggests, VueMaterial is a Vue implementation of Material design. The documentation boasts about being simple, lightweight, responsive, with an easy-to-use API. Sounds like all the right things for a component library. ### Angular

The last time I used Angular in production was about 7 years ago, which is now called Angular.js. However, the framework is starting to have somewhat of a renaissance with signals being introduced and still a whole lot of enterprise companies using it.

Component libraries:

Angular Material : Like all the rest of the material implementations for the various frameworks. All say about the same about themselves — being high quality, versatile, and frictionless. Whatever superlatives work, I guess 🤷🏽. Watch out for theming and trying to do anything that it doesn’t offer.
PrimeNG: Something nice about this collection is how you choose the base theme. You are presented with choosing design options that are taken from other popular design frameworks such as Material Design, Bootstrap, Soho, Fluent, Nano, and more. This is done with a visual editor, which is part of the theming options. PrimeNG also has a Figma UI kit, ready-made templates, and a SASS API.
NG Bootstrap: Yup, just as it sounds, a binding for Angular with Twitter Bootstrap (4.0). The caveat is that you need to learn both the API surface of the lib as well as knowing bootstrap class names.

Svelte

One thing that I really like about Svelte, is the fact that it has a lot of built-ins for handling things like styles and animations. For styling, you simply have a style tag in your component file where your CSS lives and it is scoped only to that component. On top of that, having motion models that can easily handle tween and spring animations is quite great DX.

Headless:

Svelte Headless UI : A complete port of React Headless UI, which is compatible with SvelteKit (Svelte meta framework). See above for more details.

Component libraries:

SvelteUI : Yet another TypeScript, fully featured component library. It has over 50 components that are highly customizable. Ranging from layout components, actions, inputs, typography, and all that jazz that you need in a component library.
Smelte: a UI framework built on top of Svelte and Tailwind CSS using Material Design spec. Plus, it’s a really fun name to say. The gist of it is that the lib has a Rollup plugin that you can define your themes, colors, etc. Then you need to import the libraries CSS and you’re good to go! This library has a Date Picker, navigation drawer and Treeviews, which are rare in most libs.

SolidJS

SolidJS has been around for a minute and a half, a lot less than most of the above frameworks. I am a fan of Ryan Carniato's work, however I haven't had a chance to work with SolidJS extensively.

It is most definitely a solid (pun intended) contender of choice for your next project.

Thanks to Dave Di Biase for recommending these additions 🙏🏽.

Headless:

Kobalte: An unstyled, accessible, and composable UI toolkit for building design system foundations. Inspired by AriaKit, RadixUI, React Araia, and Zag. From rummaging around in their docs, looks a lot like Radix implementation. Note: Still in beta.

Component Libraries:

SUID: A port of MUI for SolidJS. As the docs state "same API. Same design", if you're coming from React and have used MUI, this will make you feel at home. Same caveats apply. One cool tool they have is a transformer from React 👉🏽 SolidJS.
Solid Bootstrap: Once again, as the name suggests, a SolidJS wrapper on top of ye old Bootstrap. The difference being that instead of working with classes for the most parts, you'd need to use props (e.g. variant). There's also a "Core" offering which has a headless implementation

Qwik

Being the newest framework on the list, the Qwik ecosystem is still new. As such, the options here are slim. However, one thing you could do is leverage the React ecosystem inside your Qwik app and use component libraries from there.

There are also other community implementations in the works for Vue, Angular, and Svelte that would open up those ecosystems as well.

Headless:

QwikUI: Though still in beta, QwikUI offers a headless kit for building fully compatible WAI-ARIA components. Available in beta now are combo boxes, tabs, and accordion.There are drafts for tooltips, selects, and popovers. The team is also working on their own take on ShadCN/UI’s approach codenamed “Fluffy”.

Web components

As I’ve mentioned above, web components were meant to be the savior of the frontend world, but have failed to deliver. However, some companies have found success with them when it comes to UI web components. One of these companies is SalesForce with their Lightning Web Components.

Other than that, I’ve only heard of one component library which I think is worth mentioning:

Shoelace: Being built with web components means this library is framework agnostic, however, React is the only framework that was entitled to get first-class support. It also has built-in localization, and the components were built with Lit. Keep in mind that if you want the get your component content in SSR, this might not fit your needs.

Cross framework

New agnostic libraries that aren’t necessarily built with Web components, but rather with CSS tooling have been popping up lately as well. Here are two interesting newcomers:

ArkUI: Headless accessible components powered by state machines for React, Vue, and SolidJS. Also made by the creators of Zag.js and Chakra UI, this seems to be the middle ground in between those two offerings.
Flowbite: Components on top of Tailwind for not only JavaScript frameworks like React, Qwik, Vue, Svelte, Angular, and SolidJS, but also for popular meta frameworks such as Astro, Next.js, Remix, Nuxt, Meteor, and non JS frameworks such as Laravel, Symfony, Ruby on Rails, Pheonix, Django, and Flask.

Design with fewer limitations, using Builder.io

While on the subject of framework-agnostic solutions, did you know that with Builder’s Headless Visual CMS you can let your designers use your own components inside a drag-and-drop UI?

Whatever stack you’re using, with whichever component library, you can register component code that developers have written and use them to compose pages in a visual way.

Conclusion

As can be inferred from this lengthy post, there is an abundance of options to choose from.

Choosing the right solution for you and/or your team can be either a hell of a productivity booster or a huge foot gun.

I myself have experienced the effect of a bad choices that were made. In my case, it was Material UI that made it almost impossible to get the functionality that our product team desired. We had to either completely rewrite components and even use a forked version of MUI, just to get to what we wanted.

Be wary of your choices.

Hopefully, this post has given you a good enough overview of what’s out there now, and got you seriously thinking wether you need a library or wether it’s a good enough investment to roll out your own. Not only for the sake of your product team, but for the sake of your users.

Just remember, your users don’t care what solution you use, like they don’t care if you’re using Tailwind.

Use what is right for what you’re building and the requirements of the project.

Visually build with your components

Builder.io is a visual editor that connects to any site or app and lets you drag and drop with your components.

Try it out Learn more

// Dynamically render your components
export function MyPage({ json }) {
  return <BuilderComponent content={json} />
}

registerComponents([MyHero, MyProducts])

Read the full post on the Builder.io blog

Building Adaptive User Interfaces in React Native

Yoav Ganbar — Mon, 04 Sep 2023 11:32:38 +0000

Written by Vishwas Gopinath

The world of mobile development is constantly shifting, and with it comes the need for user interfaces that can adapt to any device or orientation. React Native offers a rich set of tools and techniques to build such interfaces.

In this article, we will explore how to design responsive and adaptive UIs in React Native, with a focus on varying device sizes, orientations, safe areas, and platform-specific code.

Adaptive user interfaces

React Native provides components and APIs to adapt to changes in device sizes and orientations. Since users may have different devices ranging from compact phones to larger tablets, it's essential to ensure that the app's UI adapts to these variations.

Dimensions API

The Dimensions API in React Native allows you to obtain the device's width and height. You can use these values to adapt styles based on the device size. Here's an example:

import { StyleSheet, Dimensions } from "react-native";

const windowWidth = Dimensions.get("window").width;
const windowHeight = Dimensions.get("window").height;

const styles = StyleSheet.create({
  container: {
    width: windowWidth > 500 ? "70%" : "90%",
    height: windowHeight > 600 ? "60%" : "90%",
  },
  text: {
    fontSize: windowWidth > 500 ? 50 : 24,
  },
});

However, the Dimensions API has a drawback: it doesn't dynamically update when the window dimensions change, such as during orientation changes or with foldable phones.

useWindowDimensions hook

To overcome the limitations of the Dimensions API, React Native introduced the useWindowDimensions hook. This hook simplifies the process of adapting styles that respond to changes in device dimensions. Here's how you can use it:

import { useWindowDimensions } from "react-native";

const windowWidth = useWindowDimensions().width;
const windowHeight = useWindowDimensions().height;

It’s worth noting that useWindowDimensions is the recommended approach to work with device dimensions in React Native.

SafeAreaView

The SafeAreaView component in React Native ensures that content is rendered within the safe area boundaries of a device. By using SafeAreaView, you can adapt your UI to avoid physical limitations like notches or rounded corners, providing a seamless user experience across different device designs. Here's an example of how to use SafeAreaView:

import { SafeAreaView } from "react-native";

<SafeAreaView style={{ flex: 1 }}>
  {/* Your content here */}
</SafeAreaView>

SafeAreaView is a component specific to iOS.

Platform-specific code

When developing a cross-platform app, you may need to tailor your code to specific platforms. React Native offers two approaches for this, allowing you to adapt your UI to cater to the unique design guidelines and user expectations of different platforms.

Platform module

The Platform module detects the platform on which the app is running, so you can implement platform-specific code. You can use Platform.OS for small changes or Platform.select for more comprehensive platform-specific styles. Here's an example:

const styles = StyleSheet.create({
  container: {
    marginTop: Platform.OS === "android" ? 25 : 0,
  },
  text: {
    ...Platform.select({
      ios: { color: "purple", fontSize: 24 },
      android: { color: "blue", fontSize: 30 },
    }),
    fontWeight: "bold",
    textAlign: "center",
  },
});

Platform-specific file extensions

For more complex platform-specific scenarios, you can split your code into separate files with .ios and .android extensions. React Native detects the extension and loads the relevant platform file when required. Here's an example of how you can create a platform-specific button component:

// CustomButton.ios.js
import React from "react";
import { Pressable, Text } from "react-native";

const CustomButton = ({ onPress, title }) => (
  <Pressable
    onPress={onPress}
    style={{
      justifyContent: "center",
      alignItems: "center",
      backgroundColor: "lightblue",
      borderRadius: 20,
      padding: 10,
    }}
  >
    <Text style={{ color: "purple", fontSize: 18 }}>{title}</Text>
  </Pressable>
);

export default CustomButton;

// CustomButton.android.js
import React from "react";
import { Pressable, Text } from "react-native";

const CustomButton = ({ onPress, title }) => (
  <Pressable
    onPress={onPress}
    style={{
      justifyContent: "center",
      alignItems: "center",
      backgroundColor: "lightblue",
      borderRadius: 5,
      padding: 10,
    }}
  >
    <Text style={{ color: "blue", fontSize: 18 }}>{title}</Text>
  </Pressable>
);

Additional considerations

Besides the mentioned components and APIs, you might also consider using the LayoutAnimation library for smooth transitions and animations when adapting to different screen sizes and orientations.

Conclusion

Building adaptive user interfaces in React Native requires a deep understanding of the tools and techniques available. By leveraging the Dimensions API, useWindowDimensions hook, SafeAreaView component, and platform-specific coding strategies, you can create responsive and adaptive UIs that provide an optimal user experience across different devices and platforms.

Visually build with your components

Builder.io is a headless CMS that lets you drag and drop with your components right within your existing site.

Try it out Learn more

// Dynamically render your components
export function MyPage({ json }) {
  return <BuilderComponent content={json} />
}

registerComponents([MyHero, MyProducts])

Read the full post on the Builder.io blog

Moving from Wordpress to Builder.io

Yoav Ganbar — Sat, 02 Sep 2023 07:44:12 +0000

Written by Gustavo Garcia

Moving content from your existing CMS can be much easier than you think. Already use a CMS like Wordpress? Do you have tools to export your content to a defined structure like JSON or other? If so, you have a pretty easy path to move your content to Builder.

Export your content

This section shows you how to migrate your content to Builder.io.

Export your content on a defined structure you can work with, as an example JSON format. Make sure you have your content well-defined in block structures like this example:

<div style="padding-top: 8px" classname="title">...</div>

This example would be parsed to:

{"tag": "div", "classname": "title", "style": {"padding-top": "8px"}, "children": ...}

Create some custom components in code that translates to your components from your CMS. For example, let's say we have a Hero Component that exists in your current CMS and is exported:

{
   "layout_type":"HERO",
   "props":{
      "id":"",
      "title":"This is my hero title",
      "subtitle":{
         "text":"My hero subtitle with a cool slogan",
         "tag":"h2"
      },
      "media":{
         "type":"image",
         "image":{
            "ID":11029,
            "id":11029,
            "title":"What is the universe?",
            "filename":"sample-file.svg",
            "url":"https://cool-wordpress/wp-includes/images/media/default.svg",
            "alt":"What is the universe?",
            "description":"What is the universe?",
            "caption":"What is the universe?",
            "name":"hero-v1",
            "mime_type":"image/svg+xml",
            "type":"image",
            "subtype":"svg+xml",
            "icon":"https://cool-wordpress/wp-includes/images/media/default.png",
            "width":704,
            "height":528,
            "sizes":{
               "thumbnail":"https://cool-wordpress/wp-includes/images/media/default-v3.svg",
               "thumbnail-width":"150",
               "thumbnail-height":"150",
               "medium":"https://cool-wordpress/wp-includes/images/media/default-v3.svg",
               "medium-width":"300",
               "medium-height":"300"
            }
         }
      },
      "background":"custom",
      "backgroundColor":"#123833",
      "colorModifier":"white",
      "size":"s",
      "hasButton":true,
      "button":{
         "label":"Click here",
         "action":{
            "type":"link",
            "value":"/call-to-action"
         }
      }
   }
}

This would turn into a custom component in your code such as:

import React from 'react'
import MyCustomButton from './components/MyCustomButton'

// defined props like title, subTitle, hasButton, buttonLink
export function Hero({
  title, subTitle, hasButton, buttonLink
  }) {
  return (
    <div>
      <h1>{title || 'Default hero title'}</h1>
      <h3>{subTitle || 'Default hero subtitle'}</h3>
      {
        hasButton && (
          <MyCustomButton link={buttonLink} />
        )
      }
    </div>
  )
}

import { Builder } from '@builder.io/react';
import { Hero } from './Hero'

Builder.registerComponent(Hero, {
  name: 'Hero',
  inputs: [
    {
      name: 'title',
      type: 'text',
      required: true,
    },
    {
      name: 'subtitle',
      type: 'text',
    },
    {
      name: 'hasButton',
      type: 'boolean',
    },
    {
      name: 'buttonLink',
      type: 'text',
    },
  ],
})

Create your migration script

Now that you have your content exported and your custom components ready, it's time to get that content into Builder.io so you can edit and publish. Below we have written some step-by-step instructions on how to create your migration script.

Your migration script should:

Read your content from your exported files (in this example JSON files) looking for blocks and content of interest, which will be now parsed to your custom components:

const contentJson = require('./content.json')

const MODEL_NAME = 'blog-page'

async function main() {
  console.log('starting script...', contentJson.title)
  const blocks = <any>[]

  contentJson?.body?.map((layoutItem: any) => {
    let options: any = {
      category: layoutItem.layout_type,
      title: layoutItem.props.title?.text,
      subtitle: layoutItem.props.subtitle?.text,
    }

    if (layoutItem.layout_type === 'Hero') {
      options = {
        ...options,
        type: layoutItem.props.type,
        image: layoutItem.props.image,
        content: layoutItem.props.content,
        hasButton: layoutItem.props.hasButton,
        button: layoutItem.props.button
      }
    } else if (layoutItem.layout_type === 'Text') {
      // ... if you have a custom component for text blocks
      options = {
        ...options,
        content: layoutItem.props.content,
      }
    } 
    // ... continue to identify your blocks of interest
    }

    // push your components to your blocks array to be rendered on the model layout
    blocks.push({
      "@type": "@builder.io/sdk:Element",
      "@version": 2,
      component: {
        "name": layoutItem.layoutType,
        options,
      }
    })
  })

As in the above example, when you find a block of interest, identify the custom component that best suits that block and add the custom component with its options to the blocks array to be rendered on your model layout — in this case blog-page.

Finally, write your content to Builder.io using the Write API so you can edit and publish from the editor:

async function postData(body: any) {
  const res = await axios({
    method: 'post',
    url: `https://builder.io/api/v1/write/${MODEL_NAME}`,
    headers: {
      'Authorization': 'Your private space key goes here',
      'Content-Type': 'application/json',
    },
    data: body,
  });

  return res;
}

// each time you iterate over a page,
// you can call the write API to create a new entry
// with the blocks identified

const res = await postData(
    {
      name: contentJson.url.replaceAll('/', ''),
      query: [
        {
          "property": "urlPath",
          "operator": "is", // can be `startsWith` to match any urls that starts with value
          "value": contentJson.url // must start with /
        }
      ],
      data: {
        title: contentJson.title,
        url: contentJson.url,
        metaTags: contentJson.metaTags,
        blocks: blocks,
      }
    }
  )

So the final migration script on this example should be like this:

const axios = require('axios');
const contentJson = require('./content.json')

async function postData(body: any) {
  const res = await axios({
    method: 'post',
    url: `https://builder.io/api/v1/write/${MODEL_NAME}`,
    headers: {
      'Authorization': 'Your private space key goes here',
      'Content-Type': 'application/json',
    },
    data: body,
  });

  return res;
}

const MODEL_NAME = 'blog-page'

async function main() {
  console.log('starting...', contentJson.title)
  const blocks = <any>[]

  contentJson?.body?.map((layoutItem: any) => {
    let options: any = {
      category: layoutItem.layout_type,
      title: layoutItem.props.title?.text,
      subtitle: layoutItem.props.subtitle?.text,
    }

    if (layoutItem.layout_type === 'Hero') {
      options = {
        ...options,
        type: layoutItem.props.type,
        image: layoutItem.props.image,
        content: layoutItem.props.content,
        hasButton: layoutItem.props.hasButton,
        button: layoutItem.props.button
      }
    } else if (layoutItem.layout_type === 'Text') {
      // ... if you have a custom component for text blocks
      options = {
        ...options,
        content: layoutItem.props.content,
      }
    } 
    // ... continue to identify your blocks of interest
    }

    // push your components to your blocks array to be rendered on the model layout
    blocks.push({
      "@type": "@builder.io/sdk:Element",
      "@version": 2,
      component: {
        "name": layoutItem.layoutType,
        options,
      }
    })
  })


  const res = await postData(
    {
      name: contentJson.url.replaceAll('/', ''),
      query: [
        {
          "property": "urlPath",
          "operator": "is", // can be `startsWith` to match any urls that starts with value
          "value": contentJson.url // must start with /
        }
      ],
      data: {
        title: contentJson.title,
        url: contentJson.url,
        metaTags: contentJson.metaTags,
        blocks: blocks,
      }
    }
  )
  console.log('new entry added', res.status, res.statusText)
}

main().catch(err => {
  console.log(err)
})

Additional considerations

This article showed how to migrate blog pages exported from Wordpress as JSON format files. Even so, you could use this same process to migrate any content to Builder.io exported from the most famous and used of CMSs on the market.

Conclusion

Migrating content from your existing CMS to Builder.io can be straightforward and fast — just make sure to export your content in a way that you can read it while keeping your components as well-defined as possible. This will help a lot in the migration process. Using these techniques, you can smoothly migrate hundreds or even thousands of pages as many of our customers do!

Visually build with your components

Builder.io is a headless CMS that lets you drag and drop with your components right within your existing site.

Try it out Learn more

// Dynamically render your components
export function MyPage({ json }) {
  return <BuilderComponent content={json} />
}

registerComponents([MyHero, MyProducts])

Read the full post on the Builder.io blog

What is a Headless CMS: a Visual Guide

Yoav Ganbar — Thu, 31 Aug 2023 17:58:28 +0000

Last updated: August 30, 2023

In today’s fast-paced digital age, content management systems (CMS) have become essential tools for efficiently managing and delivering content across various platforms. Among the various CMS options available, the concept of a headless CMS has emerged as a powerful and flexible solution.

Headless CMS in 30 seconds

What is a CMS?

A content management system (CMS) is a software platform that enables users to create, edit, organize, and publish digital content, such as articles, images, videos, and more.

CMSs have long been the backbone of digital content creation and delivery. Traditional CMS platforms, including open-source solutions like WordPress, Joomla, and Drupal, have been popular due to their ease of use and integration of content creation and presentation.

Here's a visual representation of a traditional CMS:

A traditional CMS operates as a monolithic application. All of the different functions, such as content creation, storage, and delivery, are tightly integrated into a single system. Users use a WYSIWYG editor within the admin interface to create and oversee content, which is subsequently transformed into a responsive user interface that adapts to various devices.

However, the tight coupling of content creation and presentation in traditional CMS brings about several challenges. One of the main issues is the lack of flexibility when it comes to delivering content across websites, mobile apps, IoT devices, smartwatches, and any emerging technologies.

Each platform often requires specific content formatting and delivery mechanisms, which means content must be managed separately for each touchpoint. This not only creates inefficiencies but also leads to maintenance problems and inconsistencies in user experiences. The need for a more flexible approach gave rise to the concept of CMS with a headless architecture.

What is a headless CMS?

At its core, a headless content management system decouples the content creation and presentation layers. Unlike traditional CMS platforms, a headless CMS does not enforce a specific front-end presentation (the "head") for displaying content.

Instead, it provides APIs (Application Programming Interfaces) that help developers fetch from a single content source and deliver data to any desired front-end, such as websites, mobile apps, IoT devices, and more. Moreover, the headless CMS often provides both RESTful API and GraphQL API options, ensuring versatile and efficient content fetching capabilities.

Here's a visual representation of a headless CMS:

In contrast to traditional monolithic setups, a headless CMS adopts a composable app approach. In this approach, various functionalities such as content creation, external integration, and delivery function independently yet cohesively.

Users engage with a simple data editor to efficiently create and manage content. This content then undergoes a seamless transition into content APIs, which can be used by a technology of choice.

Headless CMS: an analogy

Think of a traditional CMS as comparable to purchasing a frozen pizza — it's convenient but confines you to ready-made choices. In contrast, a headless CMS is like having a fully stocked kitchen complete with fresh ingredients at your disposal.

Imagine crafting not just a pizza, but also experimenting with gourmet pasta dishes or crafting delectable calzones using different techniques and flavors from the same box of ingredients. Such is the potential of a headless CMS.

How a headless CMS works

A headless CMS functions through a straightforward yet powerful process.

Content creation and management: Content creators and administrators use the headless CMS interface to create, edit, and organize content, including text, images, videos, metadata, and other media assets.
API-based architecture: The headless CMS stores content in a database and exposes it through APIs, so developers can programmatically retrieve structured content, such as JSON or XML.
Front-end development and consumption: Developers build front-end applications that interact with headless CMS APIs so that the front-end can retrieve and display content based on design and user experience requirements.

Benefits of a headless CMS

Using a headless CMS comes with a plethora of advantages:

Future-Proofing: The decoupled CMS nature provides easy adaptation to emerging technologies and changes in the digital landscape.
Flexibility: Developers can implement unique user experiences using any tech stack; next.js, gatsby, vue.js, or react, to name a few. This allows for more creativity and customization.
Better Performance: Thanks to optimized front-end design, API-driven content delivery, and integration with CDNs (Content Delivery Networks), sites and apps using a headless CMS improve loading times.
Scalability: Independent scaling of front-end and back-end ensures better performance and handling of traffic spikes.
Collaboration: Content creators and developers can work independently, promoting seamless collaboration and faster iteration cycles.
Content Reusability: A single content repository enables repurposing content across multiple platforms and devices, such as websites, mobile apps, smart devices, and more.

Who's using headless CMSs

Headless CMS is embraced by diverse industries and organizations that value agility, customization, and seamless cross-platform content delivery.

Developers and agencies: Web developers and digital agencies often use headless CMS because it allows them to build custom front-end digital experiences for their clients. They have the freedom to choose the best technologies for the job and create highly tailored and unique websites or applications. They can also optimize better for SEO.
E-commerce businesses: E-commerce platforms often use headless CMS to manage product information, marketing content, and other relevant data. With a headless CMS, they can easily deliver content to multiple channels, such as websites, mobile apps, voice assistants, and other devices to deliver excellent customer experiences for the end user.
Media and publishing companies: Companies that handle a large volume of content, such as news outlets, blogs, and magazines, use headless CMS to streamline their content management processes. The decoupled architecture allows them to distribute and reuse content across various platforms efficiently.
Marketing teams: Marketing teams can use headless CMS to manage marketing content, landing pages, and promotional material across different platforms without relying on IT teams for implementation.
Mobile app developers: Headless CMS helps mobile app developers to manage app content without needing frequent updates through app stores. The same content can be delivered to users in real-time without requiring app updates.
Many others: Headless CMSs are popular in many industries such as education, government agencies, startups, and virtually anyone with sites and apps to maintain.

Traditional CMS versus headless CMS in a snapshot

	Traditional CMS	Headless CMS
Content Presentation	Frontend is tightly linked to backend	Content is separated from presentation
Technology Stack	Uses a single technology stack	Provides APIs for content delivery to any technology stack
Development Freedom	Developers work within the CMS's framework	Developers choose their technology stack
Performance	Monolithic nature may lead to performance issues	Separation enhances performance
Scalability	Scaling may be constrained by the CMS	Can handle increased traffic and content
Content Updates	Backend & Frontend updates often interdependent	Content is separated from presentation
Time to Market	Template-based approach can be time-consuming	Faster as developers work in parallel on frontend and backend
Omnichannel	Requires extra effort to deliver content across channels	Content can be easily distributed to multiple channels
Use Cases	Well-suited for simpler websites or blogs	Suitable for complex, dynamic, and omnichannel projects
Maintenance & Upgrades	More centralized but may be harder to upgrade	Easier to maintain and update due to separation

Drawbacks of a headless CMS

One major challenge of a typical headless CMS is the lack of a visual interface for finding and editing content. This can create difficulties in:

Locating the required content to edit
Intuitively previewing and editing your content
Making non-trivial changes without needing engineering assistance and deployment
Testing and personalizing content

Read more on the problems with a headless CMS.

Fixing the drawbacks with a Visual Headless CMS

To overcome these challenges and improve user experience, a new type of headless CMS has emerged. Known as a Visual Headless CMS, it provides a visual, component-driven approach for creating content experiences.

Key features of Visual Headless CMS

A Visual Headless CMS includes all the features of a regular headless CMS, and also includes features that take the user experience to the next level.

Drag-and-drop Visual Editor

A Visual Headless CMS gives users a way to effortlessly drag and drop content elements, such as images, text blocks, videos, custom components, and more to create captivating and dynamic web pages.

Integrated Approach

Developers and designers find their perfect playground, as Visual Headless CMS offers the flexibility to blend visual building with coding for ultimate customization.

One-Click Experimentation

A Visual Headless CMS streamlines the publishing process, enabling swift delivery of new pages, A/B tests, personalization, localization, roles, and permissions.

Full control over content workflow

With visual tools, content creators can preview their changes in real-time, simplifying collaboration and streamlining the review process.

Here’s a snapshot of the capabilities of a headless CMS versus a Visual Headless CMS

	Headless CMS	Visual Headless CMS
Visual Editing	Offers a basic, form-based content creation interface	Provides a feature-rich, drag-and-drop content editor
Live Preview	Lacks the ability to preview content in real-time, with some (limited) exceptions	Gives an instant preview of edits and changes on a live page
Collaboration	Limited collaboration, requiring business teams to depend on developers for significant features	Facilitates effective real time collaboration among developers, marketing teams, and designers
A/B Testing	Requires developer involvement to create and deploy tests	Enables easy A/B testing with analytics, without developer intervention
Personalization	Requires developer involvement to create and deploy personalized variations	Empowers personalization by leveraging customer data and targeting specific user groups with tailored content

Visual Headless CMS impact on code

With a Visual Headless CMS, the overall structure is the same as any other headless CMS — content is fetched as JSON and rendered within your stack.

The key difference with a Visual Headless CMS, is you get first-class integrations for your choice of framework that let you reduce code clutter and embrace a more component-driven flow as shown below:

Ultimately, this helps developers avoid hard-coding layouts and component compositions — the CMS handles that while developers focus on components.

Builder.io Visual Headless CMS

Get started free

Unleash the Power of the Platform with These HTML Tags

Yoav Ganbar — Tue, 15 Aug 2023 07:39:24 +0000

Get ready to spice up your HTML game with some seriously underrated tags! In this blog post we'll uncover some hidden gems that will make your web development skills shine brighter than a disco ball. From the sassy <details> tag to the snazzy <mark> tag, we'll cover a variety of elements that will take your web pages from drab to fab. So, buckle up and let's explore some exciting new ways to level up your HTML coding skills.

The OG HTML modal - `<dialog>`

How many times did you reach for a library when you needed a modal?

I know I have so many times…

However, since last year, when Safari and Firefox added support for the <dialog> element, you can finally “use the platform”!

Creating a basic dialog looks something like this:

<button>Open</button>

<dialog>
 <h2>Hello World!</h2>
 <form method="dialog">
  <button>OK</button>
 </form>
</dialog>

Whatever is in the <dialog> tag will be hidden from a user. The button in the above code is the means for the user to open the dialog, but in order for this to work we’d need to add a bit of JavaScript:

const dialogElm = document.querySelector('dialog');
const buttonElm = document.querySelector('button');

buttonElm.addEventListener('click', () => {
 dialogElm.showModal();
})

In the video below, you can see how clicking on the open button opens the modal, and the OK button inside the dialog closes it:

Let’s break it down:

In order to show the dialog (modal) we use the built in showModal() function on the <dialog> element. This adds the aria-modal="true" attribute for accessibility purposes as well as provide the ability to close the modal with the Esc key. Furthermore, the initial focus of the user will be set on the first nested focusable element.
The <form method="dialog"> with the <button> (which defaults to type=submit) allows us to close to dialog. Another option is to provide the button with the formmethod="dialog" attribute and remove the method from the <form>.

Styling the backdrop

You can customize the backdrop background using the ::backdrop pseudo element:

::backdrop {
 // you can go all out, if you want 😉
 background-color: lightcoral;
 opacity: 0.8;
}

Here's what our styles look like in action:

Returning values from the dialog

When using a <form> element inside a <dialog> element, it’s possible to get a return value from the <dialog> close event.

Let’s observe a basic example. This is the HTML:

<button id="show">Open</button>
<output></output>

<dialog>
 <h2>Hello Dialog!</h2>
 <form>
  <label for="name-input">Enter something</label>
  <input id="name-input">
  <button id="ok" value="" formmethod="dialog">OK</button>
  </form>
</dialog>

And the Javascript:

const dialogElm = document.querySelector('dialog');
const showButton = document.getElementById('show');
const outputElm = document.querySelector('output');
const nameInput = document.getElementById('name-input');
const okButton = document.getElementById('ok');

// open the modal
showButton.addEventListener('click', () => {
 dialogElm.showModal();
})

// set the input value as the button value
nameInput.addEventListener('change', (e) => {
 okButton.value = nameInput.value;
});

// when the dialog close event is sent, set the <output> as the return value
dialogElm.addEventListener('close', (e) => {
  outputElm.value = dialogElm.returnValue === '' ? "No return value." : `ReturnValue: ${dialogElm.returnValue}.`; 
});

// programatically prevent the default button event and use the dialog close
// event, sending the value of the input field.
okButton.addEventListener('click', (e) => {
 e.preventDefault();
 dialogElm.close(nameInput.value);
})

The next video shows how you can open the modal, fill in the inner form, close it using the confirmation button, and get the value of the input outside of it:

For a deeper dive into the intricacies of the <dialog> element, I suggest checking out Adam Argyle’s post on web.dev.

Disclosure widget with `<details>` and `<summary>`

Using <details> and <summary> allows the creation of collapsible sections of content with a summary that can be clicked to reveal or hide the details:

<details>
    <summary>I will be the title of the content underneath</summary>
    <p>Whatever is written here will be hidden by default</p>
</details>

In the video below we can see how clicking on the <summary> content reveals the rest:

Show and hide content with no JavaScript?!

Is this magic?!

No. It’s part of the platform.

You can also control the open/close state with JS, but the beauty is you don’t have to. In order to render an open widget, one can add an open attribute to the <details> element.

Notice that we do get some browser default styles like the triangle on the left.

If we wanted to change styles we could use the list-style CSS property to change the triangle and the details[open] selector to change the content styles based on the open state.

Check out a working example of these elements below:

Native autocomplete with `<datalist>`

Did you know that your browser has an element that basically gives you an autocomplete with no JavaScript?

Using <datalist>, <option>, and an <input> element is all you need!

Check it out:

<label for="ice-cream-choice">Choose a flavor:</label>
<input list="ice-cream-flavors" id="ice-cream-choice" name="ice-cream-choice">

<datalist id="ice-cream-flavors">
    <option value="Chocolate">
    <option value="Coconut">
    <option value="Mint">
    <option value="Strawberry">
    <option value="Vanilla">
</datalist>

This will show us an input in which, when we start typing, will give us suggestions:

The bonus is that we get keyboard controls for the suggestions, and easily navigate through the list.

Value bars with `<meter>` / `<progress>`

<meter> is an HTML element that allows you to display a value within a predefined range. It's often used to show progress bars or levels. It accepts the following attributes: value, min, max, low, high, and optimum.

With these attributes, we can indicate to the browser what the color of the bar would be, depending on the values.

This is best understood through an example. Let’s take this fuel level example:

<label for="fuel">Fuel level:</label>

<meter id="fuel"
       min="0" max="100"
       low="33" high="66" optimum="80"
       value="70">
    at 70/100
</meter>

What you put between the opening and closing tag does not display.

This results in the a green bar in the browser:

The bar is green because our value (70) is higher than the high attribute, therefore, we get green.

If we change the value to something lower than the high value, for example, 60 our bar will change its color to yellow, without needing to change any CSS:

And if we set the value attribute to lower than the low (33) value, that would result in a red bar:

Pretty neat, no?

Flipping colors

Now, let’s say we want to display something that has the opposite definition, meaning, when we have more, it’s bad, and when we have less, it’s better.

For example, let’s say we want to display how much space we have left on a hard drive. In order to do this, all we have to do is define our attributes opposite to what we did with the fuel example:

<label for="disc-space">Disc space:</label>

<meter id="disc-space"
       min="0" max="1024"
       low="750" high="300"   
       value="850">
</meter>

This will result in a red bar:

When we have more disc space (value is less than low, for example 650) we’ll get a green bar:

Using `<progress>`

The <progress> element differs from <meter> only slightly:

It only has 2 attributes: max + value (the minimum value is always 0).
It only displays one color out of the box.

Here’s a simple example:

<progress value="70" max="100">70 %</progress>

However the one cool feature about this element, is that if you omit all of the attributes, you get an animated loading bar with a blue ellipsis moving back and forward:

When using this element, just remember that there are some accessibility concerns.

Highlight text with `<mark>`

As the name suggests, <mark> can be used to mark/highlight text within a block of content. For example:

<blockquote>
  It is a period of civil war. Rebel spaceships, striking from a hidden base,
  have won their first victory against the evil Galactic Empire. During the
  battle, <mark>Rebel spies managed to steal secret plans</mark> to the Empire's
  ultimate weapon, the DEATH STAR, an armored space station with enough power to
  destroy an entire planet.
</blockquote>

Will render with the words in the <mark> tag as highlighted yellow:

One thing to note about accessibility is that in order for screen readers to announce “marked” content, you need to use CSS in combination with :before and :afterpseudo elements, like so:

mark::before,
mark::after {
  clip-path: inset(100%);
  clip: rect(1px, 1px, 1px, 1px);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
  width: 1px;
}

mark::before {
  content: " [highlight start] ";
}

mark::after {
  content: " [highlight end] ";
}

Responsive image sources with `<picture>`

One of the most underrated HTML tags is the <picture> element, which allows you to serve different images based on the user's device and screen size. This can greatly improve the loading speed and user experience of your website.

To use the <picture> tag, you just include multiple <source> elements within the tag, each with a different image source and media query to determine when it should be displayed.

Here's an example of how to use the <picture> tag:

<picture>

    <source srcset="image-large.jpg" media="(min-width: 1200px)">

    <source srcset="image-medium.jpg" media="(min-width: 768px)">

    <source srcset="image-small.jpg">

    <img src="image-fallback.jpg" alt="Image">

</picture>

In this example, the browser chooses the appropriate image source based on the user's device and screen size. The first <source> element is used for devices with a minimum width of 1200 pixels, the second for devices with a minimum width of 768 pixels, and the third for all other devices.

If the browser does not support the <picture> tag, it will fallback to the <img> element (although, all major browsers have supported this for a few years now).

By using the <picture> tag, you can optimize your images for different devices and improve your website's performance and user experience.

Below we can see this in action, when we resize the window, the browser renders a different image:

For more about image optimizations, I suggest checking out “Optimal Images in HTML” a post that Steve wrote a while back.

Fun with math and science (elements)

MathML is an XML based language for describing mathematical notations.

The gist of it is that there are many elements that you can use to display equations and “sciencey” stuff, in case you need to.

I will not dive in too deeply here, as I probably lack the math knowledge to actually explain anything significant.

It’s just pretty cool to know that you can use the <math> element with a variety of other sub elements to do something like this:

<p>
  The infinite sum
  <math display="block">
    <mrow>
      <munderover>
        <mo>∑</mo>
        <mrow>
          <mi>n</mi>
          <mo>=</mo>
          <mn>1</mn>
        </mrow>
        <mrow>
          <mo>+</mo>
          <mn>∞</mn>
        </mrow>
      </munderover>
      <mfrac>
        <mn>1</mn>
        <msup>
          <mi>n</mi>
          <mn>2</mn>
        </msup>
      </mfrac>
    </mrow>
  </math>
  is equal to the real number
  <math display="inline">
    <mfrac>
      <msup>
        <mi>π</mi>
        <mn>2</mn>
      </msup>
      <mn>6</mn>
    </mfrac></math
  >.
</p>

Which would render this:

Yeah science!

With the <sub> element you can do stuff like this:

<p>
  Almost every developer's favorite molecule is
  C<sub>8</sub>H<sub>10</sub>N<sub>4</sub>O<sub>2</sub>, which is commonly known
  as "caffeine."
</p>

Which would yield this:

This can come in handy for your chemistry website, or if you want to add footnotes.

Some more useful elements are <sup> which can be combined with <var> to show off your algebra:

<p>The <em>Pythagorean theorem</em> is often expressed as the following equation:</p>

<p><var>a<sup>2</sup></var> + <var>b<sup>2</sup></var> = <var>c<sup>2</sup></var></p>

Which would render this:

But you could also use <sup> to add ordinal numbers, like so:

<p>
  The ordinal number "fifth" can be abbreviated in various languages as follows:
</p>
<ul>
  <li>English: 5<sup>th</sup></li>
  <li>French: 5<sup>ème</sup></li>
</ul>

Which gives this result:

Or superior lettering (not sure what that is for, but you can), like for certain French abbreviations (apparently, as I’ve learned from MDN):

<p>Robert a présenté son rapport à M<sup>lle</sup> Bernard.</p>

That would render:

Moaaaaaar elements!

You can show text diffing with <del> and <ins>.
You can use <kbd> to show textual user input from a keyboard, voice input, or any other text entry device.
<abbr> is used to provide an abbreviation or acronym for a term.
Use <cite> to, well, cite creative work.
The <bdi> element can help contain text when you need to isolate bi-directional text, for example mixing a left-to-right (LTR) language with a right-to-left (RTL).

Conclusion

In conclusion, HTML has a wide variety of elements that can help you create rich and interactive web pages. From the lesser-known elements like <dialog> and <picture>, to the more commonly used elements like <div> and <p>, each element provides unique functionality that can help you create a great user experience on your website. By taking advantage of these elements, you can make your website more accessible, more performant, and more engaging for your users.

Happy coding!

Visually build with your components

Builder.io is a headless CMS that lets you drag and drop with your components right within your existing site.

Try it out Learn more

// Dynamically render your components
export function MyPage({ json }) {
  return <BuilderComponent content={json} />
}

registerComponents([MyHero, MyProducts])

Read the full post on the Builder.io blog

Closing the Gap: Simplify Your Web Layouts with the CSS Gap Property

Yoav Ganbar — Thu, 10 Aug 2023 09:21:34 +0000

As a web developer, you're always looking for ways to improve your code and make your layouts more efficient.

One such improvement is the CSS Gap Property, which can simplify your web layouts and make them more visually appealing. Let’s explore the benefits of using the CSS Gap Property instead of margins, and how it can make your life as a developer easier.

Margin is spacing

Like a lot of things in software development, there are opposing opinions and camps for certain mehods and preferences. One of these cases is the use of CSS margin, either using only margin-top or using margin-bottom.

Nowadays, it’s better to use CSS logical properties and values, but the question of which strategy to use is only an opinion.

Go with the flow

As many of you may know, the natural flow (or normal flow) of the DOM is top to bottom. That is to say, any block element will be placed below the preceding block and any inline block will be inline.

Check out the following example to better understand this concept:

That is why a lot of front end developers might prefer using margin-bottom as it feels more natural.

The CSS gap property: an overview

The CSS Gap Property provides several benefits to web developers looking to create visually appealing and organized web layouts. It simplifies layouts, improves readability, enables responsive design, reduces code complexity, and improves browser performance. The Gap Property defines the size of the gap between the rows and columns in flexbox, grid, or multi-column layouts. It is a shorthand for the row-gap and column-gap properties.

Benefits of using gap instead of margin

Using the CSS gap property instead of margins has several advantages:

Simplifies layouts : Previously, developers had to use margin or padding to create space between elements, which could be time-consuming and result in inconsistent layouts. The CSS Gap Property eliminates this problem by providing a simple and efficient way to add space between elements without affecting their dimensions.
Easier responsive design : Gap makes it easier to handle spacing in responsive designs without the need for complex calculations or additional wrapper elements.
Reduced code complexity : Instead of using multiple CSS properties to create space between elements, you can use the CSS gap property to achieve the same effect with a single line of code.
Better browser performance : The CSS gap property can improve the performance of your website by reducing the amount of code required to create space between elements. This can result in faster load times and better overall performance.
No need for negative margins or pseudo selectors : Using the gap property doesn't require thinking about negative margins or using pseudo selectors to remove first or last element margins.

Steve explains this quite well in this video:

Gap versus margin: a visual comparison

To better illustrate the differences between using the CSS gap property and margins, let's consider a minimal example with a flexbox layout:

Using Margin:

<section class="margin-example">
  <div>Box 1</div>
  <div>Box 2</div>
  <div>Box 3</div>
  <div>Box 4</div>
</section>

.margin-example {
 display: flex;
 flex-wrap: wrap;
}

.margin-example div {
 width: 200px;
 margin: 0 10px;
 background: rebeccapurple;
 color: white;
}

.margin-example div:first-child,
.margin-example div:last-child {
 margin: 0;
}

Here’s the result:

Depending on what device you are viewing this from, this might look broken to you, and you would be right. The corresponding margin code from above is only taking into account desktop sizes, and is adding (margin) spacing to the left.

As a result, the mobile display is broken, as can be inferred from the image below:

How can we fix this? We could add a media query to handle what happens on mobile sizes. The naive approach would be to just switch up the margin-left & margin-right to margin-top & margin-bottom values:

@media only screen and (max-width: 425px) {
 /* CSS styles for mobile devices */
 .margin-example div {
  margin: 10px 0;
 }
}

The result:

That still isn’t right, is it?

It’s also clunky in different screen sizes when we resize the viewport window as can be seen below:

When we get to our media query breakpoint things go awry. Suddenly, boxes change sizes, and when we do get to more of our mobile screen size our second and third box get more space between them than we might have expected.

We’d need to do more work to make the responsiveness right.

Same example using gap:

<section class="gap-example">
  <div>Box 1</div>
  <div>Box 2</div>
  <div>Box 3</div>
  <div>Box 4</div>
</section>

.gap-example {
 display: flex;
 flex-wrap: wrap;
 gap: 20px;
}

.gap-example div {
 width: 200px;
 background: rebeccapurple;
 color: white;
}

First off, using the CSS gap property results in cleaner and more concise code compared to using margins.

What about responsiveness? Have a look:

Responsive without hassle!

Embracing the Gap: A Practical Example

Let's say you have a grid layout with multiple elements:

<section>
  <div>Box 1</div>
  <div>Box 2</div>
  <div>Box 3</div>
  <div>Box 4</div>
</section>

To create a responsive design and add space between the elements, you can use the CSS gap property:

section {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(200px, 1fr));
  gap: 20px;
}

This will create a 20px gap between the rows and columns, making the layout more visually appealing and easier to manage:

Conclusion

The CSS gap property is a powerful tool that can simplify your web layouts and make them more visually appealing. By using the gap property instead of margins, you can reduce code complexity, improve browser performance, and create more consistent and responsive designs. So, the next time you're working on a web layout, consider using the CSS Gap Property to make your life as a developer easier and your layouts more efficient.

Visually build with your components

Builder.io is a headless CMS that lets you drag and drop with your components right within your existing site.

Try it out Learn more

// Dynamically render your components
export function MyPage({ json }) {
  return <BuilderComponent content={json} />
}

registerComponents([MyHero, MyProducts])

Read the full post on the Builder.io blog

UI over APIs

Yoav Ganbar — Fri, 04 Aug 2023 05:16:20 +0000

One technique that is changing the way we think about user interfaces (UIs) is sending UIs over APIs, also known as server-driven UIs. This approach offers a new level of dynamism and flexibility that is transforming the traditional paradigms of UI development.

Server-driven UIs are not just a theoretical concept; they are being implemented by some of the biggest names in the tech industry. Instagram, Lyft, and Airbnb for instance, have been part of this movement, leveraging server-driven UIs to deliver dynamic content and updates to millions of users worldwide.

But what exactly are server-driven UIs? How do they work, and why are they becoming so important in modern JavaScript development? This blog post aims to answer these questions and provide an in-depth look at server-driven UIs, their benefits, and how you can implement them in your own projects.

Understanding server-driven UIs

Server-driven UIs represent a new approach to UI development. They offer a dynamic and flexible way to generate UIs on the server and send them to the client through APIs. This approach can provide faster iteration and more personalized user experiences.

While there are challenges to consider, such as app store guidelines and offline user experience management, server-driven UIs offer an exciting direction for the future of UI development.

In contrast, server-driven UIs are dynamically generated on the server and sent to the client via APIs. The server sends a JSON representation of the UI, which the client then renders. This means that the UI can be updated on the server side without requiring any changes to the client.

The UI becomes dynamic and flexible, capable of changing in real-time based on various factors such as user behavior, A/B testing results, or new feature rollouts. Builder.io for example, uses this approach in its framework SDKs by providing a component that can accept the JSON as an input and render designs that were built visually:

import { BuilderComponent } from "@builder.io/react";

export default async function MyPage({ params }) {
  const builderJSON = await builder
    // Get the page content JSON from Builder with the specified options
    .get("page", {
      userAttributes: {
        // Use the page path specified in the URL to fetch the content
        urlPath: "/" + (params?.page?.join("/") || ""),
      },
    })
 return (
   <>
     <YourHeader />
     <BuilderComponent content={builderJSON} model="page" />
     <YourFooter />
   </>
 );
}

This approach has several advantages over traditional UI development. For one, it allows for faster iteration, as changes can be made on the server side and immediately reflected on the client. It also enables backend developers to contribute to frontend development, as they can define the UI structure and behavior on the server.

However, server-driven UIs are not without their challenges. They require a different way of thinking about UI development, and there are technical considerations to take into account, such as how to handle actions and maintain a smooth user experience. But with careful planning and implementation, these challenges can be overcome.

The Role of server-driven UIs in Instagram

Instagram's adoption of server-driven UIs provides a compelling case study of this innovative approach in action. The social media giant has developed a technology called "blocks" that leverages the concept of server-driven UIs to deliver dynamic content and updates to its users.

Steve Sewell,CEO @ Builder.io, and Yaser Alkayale, engineer @ Instagram/Meta, had a conversation about Sending UIs over APIs:

In Instagram's implementation, the server sends a tree-like structure of blocks to the client. Each block represents a part of the UI and contains information about what component to render and what props to pass to that component. The client then traverses this tree structure, rendering the components as specified by the blocks.

This approach allows Instagram to make immediate updates to the UI without needing to push a new version of the app. For example, if a bug is found in a particular UI component, the server can simply stop sending blocks that render that component, effectively fixing the bug for all users instantly.

Moreover, server-driven UIs have enabled Instagram to iterate faster on its product. Instead of waiting for a new app version to be released, product teams can make changes to the UI on the server and see those changes reflected in the app immediately. This has led to a more agile and responsive product development process.

The benefits of server-driven UIs

The adoption of server-driven UIs brings a host of benefits that can significantly enhance the development process and the end-user experience.

Immediate bug fixes and faster iteration : As demonstrated by Instagram's use case, one of the most significant advantages is the ability to make immediate bug fixes and faster iterations. Changes to the UI can be made on the server side and reflected instantly on the client side, without the need for users to update their app or for developers to go through a lengthy app store review process.
Backend developers contribute to frontend development : Server-driven UIs also blur the line between frontend and backend development. Backend developers can define the UI structure and behavior on the server, allowing them to contribute more directly to the frontend development process. This can lead to more efficient use of resources and a more cohesive development team.
Dynamic and personalized user experiences : With server-driven UIs, the user experience can be dynamically tailored based on a variety of factors. For example, the server could send different UIs based on the user's behavior, preferences, or even A/B testing results. This can lead to more personalized and engaging user experiences.
Reduced client complexity : By moving much of the UI logic to the server, server-driven UIs can also reduce the complexity of the client. This can make the client lighter and faster, leading to improved performance and a smoother user experience.

Building server-driven UIs: a practical guide

Building server-driven UIs may seem daunting at first, but with a clear understanding of the process and some practical steps, it can be a manageable and rewarding endeavor. Here's a step-by-step guide on how to build server-driven UIs:

Create a tree structure : The first step in building a server-driven UI is to create a tree-like structure that represents your UI. Each node in the tree corresponds to a UI component and contains information about what component to render and what props to pass to that component.
Handle actions : Actions, such as user interactions, need to be handled in a server-driven UI. This can be done by including action handlers in your components that send requests to the server. The server can then respond with a new UI tree based on the action.
Use JSON format : The UI tree is typically represented in a JSON format, which can be easily sent over an API and parsed by the client.
Implement a rendering engine : On the client side, you'll need a rendering engine that can traverse the UI tree and render the components as specified by the tree.
Test and iterate : As with any development process, testing and iteration are key. Be sure to thoroughly test your server-driven UI and make improvements based on your findings.

Remember, building server-driven UIs requires a shift in mindset from traditional UI development. It's not just about coding, but also about architecting your UI in a way that can be dynamically generated and updated from the server.

Navigating the challenges of server-driven UIs

While server-driven UIs open up new possibilities for UI development, they also introduce new considerations that developers need to be aware of:

App store guidelines : App stores have guidelines that need to be followed. It's important to ensure that your use of server-driven UIs aligns with these guidelines. Transparency about your UI approach when submitting your app for review can help avoid any potential issues.
Offline user experience : Since server-driven UIs depend on server communication, managing the user experience when offline can be a challenge. Implementing strategies like caching can help maintain a consistent user experience even without a network connection.
Performance considerations : While server-driven UIs offer dynamic capabilities, there can be performance considerations to keep in mind. Efficient network requests and optimized rendering techniques can help maintain a smooth user experience.
Added complexity : Implementing server-driven UIs can add a layer of complexity to the development process, as UI management occurs on both the server and client side. However, with a well-structured approach and clear separation of responsibilities, this complexity can be effectively managed.

While these considerations present their own challenges, they also offer opportunities for problem-solving and innovation. With thoughtful planning and execution, server-driven UIs can be a valuable addition to your development toolkit.

Conclusion

Sending UIs over APIs, or server-driven UIs, represents a significant shift in the landscape of UI development. By moving much of the UI logic to the server, this approach offers a level of dynamism and flexibility that is reshaping the industry.

From immediate bug fixes and faster iteration to enabling backend developers to contribute to frontend development, server-driven UIs bring a host of benefits. They also allow for more personalized and engaging user experiences, and can reduce the complexity of the client for improved performance.

While there are challenges to navigate, such as app store guidelines and managing the offline experience, these can be effectively addressed with careful planning and strategic approaches.

In the world of advanced JavaScript development, server-driven UIs are not just a theoretical concept, but a practical approach being adopted by major platforms like Instagram. As we continue to push the boundaries of what's possible in UI development, server-driven UIs offer an exciting direction for the future.

Visually build with your components

Builder.io is a headless CMS that lets you drag and drop with your components right within your existing site.

Try it out Learn more

// Dynamically render your components
export function MyPage({ json }) {
  return <BuilderComponent content={json} />
}

registerComponents([MyHero, MyProducts])

DEV Community: Yoav Ganbar

Modern CSS for 2024: Nesting, Layers, and Container Queries

What we'll be working on

Less code with native CSS nesting

What you can nest

More nesting info

Say Goodbye to !important with CSS @layer

Bye-bye media queries, hello container queries

Contain yourself

How we generated the HTML + CSS

Conclusion

Astro + Qwik: Houston, we have Resumability!

The problem

The journey

Introducing @qwikdev/astro:

Starts fast, stays fast

Adding Qwik

Do Qwik components need hydration directives?

Does resumability work?

What's in that 17.61kb chunk?

Read the full post on the Builder.io blog

Bun vs Node.js: Everything you need to know

What is Bun?

What Bun solves for

Node.js versus Deno versus Bun

Getting started

Bun versus Node.js: JavaScript runtime

JavaScript engine

Transpiler

ESM and CommonJS compatibility

Web APIs

Hot reloading

Node.js compatibility

Bun APIs

Bun versus Node.js: package manager

Bun versus Node.js: bundler

Bun versus Node.js: test runner

Migrating from Jest or Vitest

Performance benchmarks

Conclusion

Read the full post on the Builder.io blog

A First Look at HTMX and How it Compares to React

Web dev's wild ride

HTMX explained

HTMX: rethinking interactivity

Dynamic content on-the-go

Behind-the-scenes form submissions

Auto updates

Managing UI elements

Syncing with server logic

The technical stuff: how HTMX works

Extending HTML

Server communication

Swapping content

Handling events

Integration with CSS

Error handling

Benefits of adopting HTMX

HTMX vs. React: a comparative analysis

Philosophy and Approach :

Learning curve

Performance

Integration

Use cases

Community and ecosystem

Drawbacks and tradeoffs

HTMX's role in upcoming web development

Key takeaways

Read the full post on the Builder.io blog

Finding the Best React CMS: A Comprehensive Guide

What is React?

What is a CMS?

React and CMS: an analogy

Understanding the headless CMS

Advantages of a headless CMS with React

What to consider when choosing a headless CMS

Integrating a React app with a headless CMS

Visual headless CMS

Traditional, headless, and visual headless

Frequently asked questions

Say Goodbye to `!important` with CSS `@layer`

Svelte

Design with fewer limitations, using Builder.io

Export your content

The OG HTML modal - `<dialog>`

Disclosure widget with `<details>` and `<summary>`

Native autocomplete with `<datalist>`

Value bars with `<meter>` / `<progress>`

Using `<progress>`

Highlight text with `<mark>`

Responsive image sources with `<picture>`