• DecapCMS - Github Link

• TinaCMS - Github Link

• SveltiaCMS - Github Link

• Outstatic - Github Link

• Keystatic - Github Link

Core Features Comparison

Technical Aspects

User Experience

Use Cases & Best Fits

Deployment & Hosting

Unique Strengths

Recent Updates & Development

This tool is called Farm and it currently has 3.4k stars in their Github. Its creator is brightwu（吴明亮） worked in ByteDance.

The first commit of the Github was from 2 years ago - however I believe the Design and architecture thinking must be longer than that.

What is Farm?

So what is Farm? Quoting from their own intro in their Github readme.

Farm is a extremely fast vite-compatible web-building tool written in Rust. It's designed to be fast, powerful and consistent, aims to provide best experience for web development, which is the real next generation build tool.

Performance Benchmark Comparison

The Stable version 1.0 has been released few weeks now. On top of Rust, they used a benchmark from Turborepo which is to render 1000 React components. and managed to be faster in different timings like Cold Start, Hot Start, HMR, Build Time, etc.

Check this for more info https://github.com/farm-fe/performance-compare on the comparison and benchmark performance.

Other Exciting Features

It is mentioned in their release docs, that Farm is compatible with Vite ecosystem / plugins and not only that it has other features like

• Basic compilation capabilities

• Lazy compilation

• Incremental Building: Module-level disk persistent cache supported, unchanged modules won't be compiled twice, hot start time is reduced by 80%, with lazy compilation enabled, preview projects of any size in 1s

• Production optimization / Browser compatibility

• Partial Bundling: Bundle thousands of modules into about 20-30 output files according to dependency ship. Perfectly avoiding the two extreme modes of bundle and bundless and can ensure loading performance while improving cache reuse rate.

• Plugin Ecosystem

• SSR Support

Future Features / Roadmaps

• Continue to build more top-level frameworks, such as SSR framework. (NextJS/ NuxtJS/ etc)

• Extend the Rust plugin ecosystem, use Rust to implement or reconstruct existing common tools, and provide a more extreme performance experience

My Thoughts on Farm

New technology that comes out every now and then is always great and disrupting the development ecosystem like how even Vite comes out itself because Webpack is slow. I really enjoy how Vite makes it faster for new projects as well compared to 5 years ago where everything will take longer to start and so on (HMR will take 2 - 5 secs in big projects).

With this coming who knows, Vite and other tools may take inspiration from it and grow each other as better tools for the ecosystem.

As Farm is still new to the ecosystem, there soon will be issues and reports for many different testing environment from many people like different devices, OS, etc. Who knows Farm can handle all of those like Vite and the rest do yet. As of the time writing this article Farm has only < 100 issues in their Github.

They have tested Farm with many options as well like Electron and Tauri which is cross platform tools which will definitely speed things up in their build time with Rust multithread features.

I hope for the best for the ecosystem to keep pushing each other to get to a better performance, stability, and scalability throughout the ecosystem.

Quick Start (Try it yourself)

Farm provides official templates to quickly create a React, Vue, Solid, Svelte, etc. project:

pnpm create farm

Then select the type of project, features, etc. to be created. After the project is created, start the project:

pnpm start

You can create and start your first Farm project in 20 seconds!

Let me know your thoughts on the comment below whether Farm will succeed or not and what is your reasoning!

To use this trick I installed zustand for global state management - can be used with other global state management libraries as well.

I know the importance of the First Time Load in SEO sense, so usually we will have to dynamic load the Dialog component where it is not visible to the first page load hence reducing the Dialog component from being downloaded. In NextJS this can be dynamic loaded by using next/dynamic built-in from NextJS.

Getting Started

For a starter, we will use NextJS with ShadcnUI.

First, we make our Dialog component that uses ShadcnUI Dialog component and the inside can be anything for now - usually Wizard components has quite few files inside it for different forms for each steps - to make it succinct we are skipping that part.

// src/app/wizard-dialog/dialog.tsx

import { Dialog, DialogContent } from '@/components/ui/dialog';

export const WizardDialog = ({
  open,
  setOpen
}: {
  open: boolean;
  setOpen: (by: boolean) => void;
}) => {
  return (
    <Dialog open={open} onOpenChange={setOpen}>
      <DialogContent>
        {/* Pretty Big Content that needs to be dynamic loaded */}
      </DialogContent>
    </Dialog>
  )
}

After having the dialog component, we need to setup our global state management store for storing the state of the Dialog, like its open state and loading state - this can be custom to our needs - for now we will go with the basic setting.

// src/app/wizard-dialog/store.ts

import { create } from 'zustand'

interface WizardDialogState {
  open: boolean
  setOpen: (by: boolean) => void
  isLoading: boolean
  setIsLoading: (by: boolean) => void
}

export const useWizardDialog = create<WizardDialogState>()((set) => ({
  open: false,
  setOpen: (by) => set(() => ({ open: by })),
  isLoading: false,
  setIsLoading: (by) => set(() => ({ isLoading: by })),
}))

Having the store and the dialog component now, we can create our dynamic loaded functionality we will call it consumer.tsx - which we will put it in the app/layout.tsx for global usage.

// src/app/wizard-dialog/consumer.tsx

'use client'

import { useWizardDialog } from '@/app/wizard-dialog/store'
import dynamic from 'next/dynamic'
import { useEffect } from 'react'

const WizardDialogLoading = () => {
  const setIsLoading = useWizardDialog((s) => s.setIsLoading)

  useEffect(() => {
    setIsLoading(true)
    return () => {
      setIsLoading(false)
    }
  }, [])

  return null
}

const WizardDialog = dynamic(
  () => import('@/app/wizard-dialog/dialog').then((mod) => mod.WizardDialog),
  {
    ssr: false,
    loading: WizardDialogLoading,
  }
)

export const WizardDialogConsumer = () => {
  const open = useWizardDialog((s) => s.open)
  const setOpen = useWizardDialog((s) => s.setOpen)
  return open && <WizardDialog open={open} setOpen={setOpen} />
}

A bit explanation here, we use the open state from the store to indicate that when it is true, it will start the dynamic load the <WizardDialog /> component.

After creating a the consumer here we can put it inside the app/layout.tsx

// src/app/layout.tsx

import { Inter } from 'next/font/google'
import { WizardDialogConsumer } from '@/app/wizard-dialog/consumer'

import './globals.css'

const inter = Inter({ subsets: ['latin'] })

export default function RootLayout({
  children,
}: Readonly<{
  children: React.ReactNode
}>) {
  return (
    <html lang='en'>
      <body className={inter.className}>
        <WizardDialogConsumer />
        {children}
      </body>
    </html>
  )
}

WizardDialogLoading is pretty interesting trick here to manipulate our global state for our loading state. When the component is being first loaded, it will set loading to true and when it is mounted it will make our loading state to be false - with this logic, we can use globally the loading state later in our trigger to render any global loading component.

Below is the code for our trigger.tsx

// src/app/wizard-dialog/trigger.tsx

'use client'

import { useWizardDialog } from '@/app/wizard-dialog/store'
import { cn } from '@/lib/utils'
import { Loader2 } from 'lucide-react'
import React from 'react'

export const WizardDialogTrigger = ({
  children,
}: {
  children: React.ReactElement
}) => {
  const setOpen = useWizardDialog((s) => s.setOpen)
  const isLoading = useWizardDialog((s) => s.isLoading)

  const onClick = () => {
    setOpen(true)
  }

  return (
    <>
      {children &&
        React.cloneElement(children, {
          onClick,
          className: cn(
            children?.props?.className,
            isLoading && 'flex flex-items-center justify-center'
          ),
          children: isLoading ? (
            <Loader2 className='animate-spin text-current' />
          ) : (
            children?.props?.children
          ),
        })}
    </>
  )
}

A bit explanation here, we are using React.cloneElement to our children component to modify its onClick function - so that we can globally let whichever component children of this trigger would be clickable and changing the state to be true.

And we can use the trigger like so - just wrap any clickable component with our custom trigger component.

// src/app/page.tsx

import { WizardDialogTrigger } from '@/app/wizard-dialog/trigger'

export default function Page() {
  return (
    <div>
      <WizardDialogTrigger>
        <button>Take Survey</button>
      </WizardDialogTrigger>
    </div>
  )
}

Learnings

We have done making our Dialog component dynamically loaded into the our NextJS app to ensure it will not block the first page timing of our page.

This is only one way of doing it - hope it can be a foundation of what next to be implemented in the future enhancements.

Further enhancement can be like dividing the loading state into multiple keys states instead of one global loading state. React.cloneElement is easy to get pitfall from the React documentation - we can use alternative like pass the children into a prop.

I have uploaded a sample repo into GitHub as well incase needed.

https://github.com/linkb15/blog-dynamic-load-dialog

Cheers!

pnpm create next-app@latest my-app --typescript --tailwind --eslint

and fill up with the prompt with default answer like so.

✔ Would you like to use `src/` directory? … Yes
✔ Would you like to use App Router? (recommended) … Yes
✔ Would you like to customize the default import alias (@/*)? … No

Install the Library that we need for our form and zod schema validation.

pnpm i react-hook-form zod @hookform/resolvers

Schema

For this tutorial we will be creating a simple register form which user will have fill up email, password and confirm their password. A zod schema would look like this

// src/app/register-form/schema.ts
import z from 'zod'

export const registerSchema = z
  .object({
    email: z.string().email().min(1, { message: 'Email is Required' }),
    password: z.string().min(1, { message: 'Password is Required' }),
    confirmPassword: z
      .string()
      .min(1, { message: 'Please confirm your password' }),
  })

To add validation for the confirm password, there are multiple ways we can do that. In this tutorial I will use .superRefine from zod to have more freedom than normal .refine in defining our validation. The modified schema will look like this.

// src/app/register-form/schema.ts
import z from 'zod'

export const registerSchema = z
  .object({
    email: z.string().email().min(1, { message: 'Email is Required' }),
    password: z.string().min(1, { message: 'Password is Required' }),
    confirmPassword: z
      .string()
      .min(1, { message: 'Please confirm your password' }),
  })
  .superRefine((val, ctx) => {
    if (val.password !== val.confirmPassword) {
      ctx.addIssue({
        code: z.ZodIssueCode.custom,
        message: 'Password is not the same as confirm password',
        path: ['confirmPassword'],
      })
    }
  })

export interface RegisterSchema extends z.infer<typeof registerSchema> {}

Take note, since we are using typescript, we need to export the schema type as well by using z.infer of our schema.

Register form component

We will use the schema with the react-hook-form and create a simple register form with simple styling and when we finish filling up the form, it will alert the data.

// src/app/register-form/form.tsx
'use client'

import { useForm } from 'react-hook-form'
import { zodResolver } from '@hookform/resolvers/zod'
import { registerSchema, RegisterSchema } from '@/app/register-form/schema'

export const RegisterForm = () => {
  const {
    register,
    handleSubmit,
    formState: { errors },
  } = useForm<RegisterSchema>({
    resolver: zodResolver(registerSchema),
  })

  const onSubmit = handleSubmit((data) => {
    console.log(data)
    alert(JSON.stringify(data))
  })

  return (
    <form onSubmit={onSubmit} className='space-y-3'>
      <div className='flex flex-col gap-1'>
        <label htmlFor='email'>Email</label>
        <input
          id='email'
          {...register('email')}
          className='bg-transparent border py-2 px-4'
        />
        {errors.email?.message && <p>{errors.email?.message}</p>}
      </div>

      <div className='flex flex-col gap-1'>
        <label htmlFor='email'>Password</label>
        <input
          id='password'
          type='password'
          {...register('password')}
          className='bg-transparent border py-2 px-4'
        />
        {errors.password?.message && <p>{errors.password?.message}</p>}
      </div>

      <div className='flex flex-col gap-1'>
        <label htmlFor='confirmPassword'>Confirm Password</label>
        <input
          id='confirmPassword'
          type='password'
          {...register('confirmPassword')}
          className='bg-transparent border py-2 px-4'
        />
        {errors.confirmPassword?.message && (
          <p>{errors.confirmPassword?.message}</p>
        )}
      </div>

      <input type='submit' className='px-4 py-2 rounded bg-gray-500' />
    </form>
  )
}

now to test this we just need to replace our page component like so.

// src/app/page.tsx
import { RegisterForm } from '@/app/register-form/form'

export default function Home() {
  return (
    <main className='flex min-h-screen flex-col items-center justify-between p-24'>
      <RegisterForm />
    </main>
  )
}

Now we can test this code in our http://localhost:3000 using pnpm dev in our terminal.

Additional information

Zod is powerful schema validation library that can help you type-safe your code, if you refactor your schema like changing from email to username, all your code will have an error because, you have to update them from email to username in the files that use the schema.

.superRefine is a powerful functions to do a custom validation as well as doing so much things like we can call an APIs for checking email uniquely or not for the validation.

Cheers!

To solve this

We can reuse next/font that we use in the app/layout.tsx in our storybook configuration. To do this, we need to create another file and export the font from there to be used in our app/layout.tsx and our storybook configuration.

// app/font.ts

// Pick your font family that you want
import { Mukta, PT_Serif } from 'next/font/google';

export const fontSerif = PT_Serif({
  subsets: ['latin'],
  weight: ['400', '700'],
  variable: '--font-serif',
  display: 'swap'
});

export const fontSans = Mukta({
  subsets: ['latin'],
  weight: ['300', '400', '500', '700'],
  variable: '--font-sans',
  display: 'swap'
});

In the .storybook/preview.tsx , we just need to create a decorator that will inject our variable class using useEffect so that it is applied in the body, not just in the iframe of our story.

// .storybook/preview.tsx
import { fontSans, fontSerif } from '@/app/font';
import type { Preview } from '@storybook/react';

const preview = {
  decorators: [
    (Story) => {
      useEffect(() => {
        document.body.classList.add(
          fontSans.variable,
          fontSerif.variable,
          'font-sans',
          'antialiased'
        );
      }, []);

      return (
        <TooltipProvider>
          <Story />
        </TooltipProvider>
      );
    }
  ],
} satisfies Preview;

export default preview;

Why do we do this? The reason is if we do add the font class in a div and have the <Story /> as the children - it will not work for Dialog / Modal component that injects itself in a Portal as sibling of the storybook iframe - hence our font will not be applied.

Since Shadcn UI has been mostly a popular option for many frontend developers to be used and their Dialog component is using Radix UI which is injecting element into the Portal as sibling of the iframe.

Now after adding this decorator, you should see the body has the class added as well as the font updated.

Cheers!

In this blog, we will explore the basics of Storybook testing with its runner.

Getting Started

We will be following this installation documentation from Storybook Test Runner

Start by installing the add-on

bun add -d @storybook/test-runner

and add new scripts to the package.json

"scripts": {
    "test-storybook": "test-storybook"
}

Since the underlying of this package is using Jest and Playwright - we need to run our code first before running the test.

Run the storybook first in the first terminal

bun storybook

Run the test on the second terminal

bun test-storybook

Running this command directly will be a smoke test for every story in the storybook. This is useful to check if there are any errors in mounting or rendering the components.

Adding Form for Interaction

In this example, we will add a Form component using the ShadcnUI Form and Input component.

bunx shadcn-ui@latest add form input

For illustration purposes, we will just use the example from the ShadcnUI Profile Form component. Add this ProfileForm component to the components folder.

// components/ProfileForm.tsx
'use client'

import { zodResolver } from '@hookform/resolvers/zod'
import * as z from 'zod'

import { Button } from '@/components/ui/button'
import {
  Form,
  FormControl,
  FormDescription,
  FormField,
  FormItem,
  FormLabel,
  FormMessage,
} from '@/components/ui/form'
import { Input } from '@/components/ui/input'
import { useForm } from 'react-hook-form'

const formSchema = z.object({
  username: z.string().min(2, {
    message: 'Username must be at least 2 characters.',
  }),
})

export function ProfileForm() {
  const form = useForm<z.infer<typeof formSchema>>({
    resolver: zodResolver(formSchema),
    defaultValues: {
      username: '',
    },
  })

  const onSubmit = form.handleSubmit((values) => {
    // Do something with the form values.
    // ✅ This will be type-safe and validated.
    console.log(values)
  })

  return (
    <Form {...form}>
      <form onSubmit={onSubmit} className='space-y-8'>
        <FormField
          control={form.control}
          name='username'
          render={({ field }) => (
            <FormItem>
              <FormLabel>Username</FormLabel>
              <FormControl>
                <Input placeholder='shadcn' {...field} />
              </FormControl>
              <FormDescription>
                This is your public display name.
              </FormDescription>
              <FormMessage />
            </FormItem>
          )}
        />
        <Button type='submit'>Submit</Button>
      </form>

      {form.formState.isSubmitted && (
        <div className='p-4 bg-green-100 rounded-md'>
          <p className='text-green-800'>
            Your profile has been updated successfully.
          </p>
        </div>
      )}
    </Form>
  )
}

After we have created the ProfileForm component, we can create a new story in the Storybook.

// stories/ProfileForm.stories.ts
import type { Meta, StoryObj } from '@storybook/react'

import { ProfileForm } from '@/components/ProfileForm'

const meta = {
  title: 'Example/ProfileForm',
  component: ProfileForm,
  parameters: {
    layout: 'centered',
  },
  tags: ['autodocs'],
  argTypes: {},
} satisfies Meta<typeof ProfileForm>

export default meta
type Story = StoryObj<typeof meta>

export const Primary: Story = {
  args: {},
}

We can check this in the Storybook it will show like below.

Interactive Testing in Storybook

For the interaction test, we will follow this guideline from Storybook documentation.

Install the library needed for this test.

bun add -d @storybook/testing-library @storybook/jest @storybook/addon-interactions

Now comes the interesting part, writing your user interaction test code. Create a new story for the Filled form.

export const Filled: Story = {
  play: async ({ canvasElement }) => {
    const canvas = within(canvasElement)

    // 👇 Simulate interactions with the component
    await userEvent.type(canvas.getByTestId('email'), 'email@provider.com')

    await userEvent.type(canvas.getByTestId('password'), 'a-random-password')

    // See https://storybook.js.org/docs/react/essentials/actions#automatically-matching-args to learn how to setup logging in the Actions panel
    await userEvent.click(canvas.getByRole('button'))

    // 👇 Assert DOM structure
    await expect(
      canvas.getByText(
        'Everything is perfect. Your account is ready and we should probably get you started!'
      )
    ).toBeInTheDocument()
  },
}

add the import lines as well

import { userEvent, within } from '@storybook/testing-library'
import { expect } from '@storybook/jest'

I faced a type error while writing the test.

hence add this to the compilerOptions in the tsconfig.json

"types": ["@testing-library/jest-dom"]

Running again the storybook and checking the Filled story of ProfileForm, there will be a Pass test in the interaction tab.

With this, we can even move back to the previous state and play the interaction on our own in the Storybook UI.

We can test again the test-storybook command and see the results of this new interaction test in the test runner.

bun test-storybook --verbose

Running in verbose mode --verbose, so we can see that the Filled story is different than the rest of the stories here which is "play-test" instead of "smoke-test".

Final Thoughts

Testing is a huge subject to cover - we only cover a small portion of it.

After going through this post, testing with Bun and Storybook in Vite React App seems working fine.

Following this documentation, we can try to run the Storybook in bun runtime as well like so

bun --bun storybook

However, it is still a tracked issue currently in the Bun Repository - therefore we shall await more stability coming into the Bun runtime in the coming weeks.

The tutorial will cover installing Bun and creating a React project with Typescript, and Vite and the styling will be using TailwindCSS, ShadcnUI and Storybook.

This tutorial will be using Mac since the stable version of Bun is only for Mac currently, the Windows version is said to be experimental.

Getting Started

Install Bun with the following command from the Bun website.

curl -fsSL https://bun.sh/install | bash

After installing, we create a react project with the following command

bun create vite

The project name is left default as vite-project, and React as the framework with Typescript turned on.

Boom 💥 the installation process did not even more than 10 seconds.

The development server can be started by

bun dev

and it should be running in your http://localhost:5173/

Adding TailwindCSS

Since we are using the Vite app, we will follow the installation for Tailwind with Vite. To install the TailwindCSS library, the Bun command is similar to how Yarn or NPM is used.

bun add -d tailwindcss postcss autoprefixer

following the TailwindCSS tutorial we need to init the configuration.

bunx tailwindcss init -p
// or 
bun run tailwindcss init -p

On NPM we have npx, in Bun, we have bunx to help initialize the module right away.

The rest of the steps are supposed the same as the ones from the guide from TailwindCSS documentation.

edit content inside tailwind.config.js

/** @type {import('tailwindcss').Config} */
export default {
  content: ['./index.html', './src/**/*.{js,ts,jsx,tsx}'],
  theme: {
    extend: {},
  },
  plugins: [],
}

replace the content of your index.css with the TailwindCSS directives

/* index.css */
@tailwind base;
@tailwind components;
@tailwind utilities;

Adding ShadcnUI

ShadcnUI has been a great help in improving the adoption of best practices in styling the whole React projects in the industry.

We will follow this guide from the website documentation.

Since the first two are the same as TailwindCSS documentation, we will skip that and straight towards the Absolute Path configuration in Vite.

Add this part of the code inside compilerOptions object

"baseUrl": ".",
"paths": {
  "@/*": ["./src/*"]
}

Add @types/node for type safety for importing from the path module.

bun add -d @types/node

And change the vite.config.ts to understand the @ sign as well as an alias of the "src" folder.

import path from 'path'
import react from '@vitejs/plugin-react'
import { defineConfig } from 'vite'

export default defineConfig({
  plugins: [react()],
  resolve: {
    alias: {
      '@': path.resolve(__dirname, './src'),
    },
  },
})

Now we can run the init command from ShadcnUI

bunx shadcn-ui@latest init

Pick Typescript and Default style then Slate as base color when asked. For the global CSS, src/index.css - and the rest of the questions mostly we will use the default answer for it.

✔ Would you like to use TypeScript (recommended)? … no / yes
✔ Which style would you like to use? › Default
✔ Which color would you like to use as base color? › Slate
✔ Where is your global CSS file? … src/index.css
✔ Would you like to use CSS variables for colors? … no / yes
✔ Where is your tailwind.config.js located? … tailwind.config.js
✔ Configure the import alias for components: … @/components
✔ Configure the import alias for utils: … @/lib/utils
✔ Are you using React Server Components? … no / yes
✔ Write configuration to components.json. Proceed? … yes

After that is set up we can try to add a Button component from the library.

bunx shadcn-ui@latest add button

That's it! initializing ShadcnUI and adding more components - it is advised to explore their documentation as needed.

Adding Storybook

We will be following the Storybook documentation for this.

bunx storybook@latest init --skip-install
bun i

We are skipping the installation since Bun is new hence they are not detected by the Storybook CLI and by default it will use NPM.

After that, we will have .storybook folder and stories folder added to the root folder.

Run the Storybook and follow their Tour.

bun storybook

Let's update the Story in the stories/Button.stories.ts to use the Button that has been generated by ShadcnUI.

import type { Meta, StoryObj } from '@storybook/react'

import { Button } from '@/components/ui/button'

// More on how to set up stories at: https://storybook.js.org/docs/react/writing-stories/introduction#default-export
const meta = {
  title: 'Example/Button',
  component: Button,
  parameters: {
    // Optional parameter to center the component in the Canvas. More info: https://storybook.js.org/docs/react/configure/story-layout
    layout: 'centered',
  },
  // This component will have an automatically generated Autodocs entry: https://storybook.js.org/docs/react/writing-docs/autodocs
  tags: ['autodocs'],
  // More on argTypes: https://storybook.js.org/docs/react/api/argtypes
  argTypes: {
    // backgroundColor: { control: 'color' },
  },
} satisfies Meta<typeof Button>

export default meta
type Story = StoryObj<typeof meta>

// More on writing stories with args: https://storybook.js.org/docs/react/writing-stories/args
export const Primary: Story = {
  args: {
    variant: 'default',
    children: 'Primary',
  },
}

export const Secondary: Story = {
  args: {
    variant: 'secondary',
    children: 'Secondary',
  },
}

export const Large: Story = {
  args: {
    size: 'lg',
    children: 'Large',
  },
}

export const Small: Story = {
  args: {
    size: 'sm',
    children: 'Small',
  },
}

Update the import and all the props to match our Button props.

However, even after adding all of this, the styling from TailwindCSS has not applying yet. This is because we have not import the index.css into our Storybook. We can do this by adding an import into our .storybook/preview.ts

// .storybook/preview.ts

import '@/index.css'

...

Once, save the hot reload should apply and the styling should be applied to our Butotn stories.

Final Thoughts

Testing Bun with React, Typescript, Vite, TailwindCSS, ShadcnUI and Storybook has been successful so far. The installation and runtime speed of Bun has been a breeze. Looking forward to more development from Bun, Node and Deno in the Javascript world to keep improving the industry standard ahead for years to come.