Core Web Vitals are key metrics that help Google evaluate a website's user experience. Good SEO rankings depend on optimal metrics -- here's how to improve them.

[Guide] Core Web Vitals: What They Are and How to Improve Them

If you’ve started to dig into the technical side of SEO, inevitably the term Core Web Vitals will have come across your path. In this post, we’ll explore not only what Core Web Vitals are, but also how you can take steps to improve them on your website.

Before learning about Core Web Vitals, we must first define the broader term, Web Vitals, and explain the motivation behind their creation. Web Vitals is a project spearheaded by Google to give web developers consistent recommendations for performance measurements. The design of each metric ensures that they assess signals that predict superior user experiences on the web.

Core Web Vitals are a curated subset of metrics selected from the full list of Web Vitals. Google recommends anyone with a website check their Core Web Vitals to evaluate the user experience (UX) of their site.

They display the results of Web Vital diagnostic tests throughout many of their developer tools, like Page Speed Insights and Lighthouse. Each vital is selected because they believe it’s one of the most relevant vitals for improving UX. Each of these vitals captures a unique aspect of the UX that aims to reflect the real-world experiences of users on the web.

Google’s secrecy when it comes to disclosing what variables factor into SEO ranking is infamous.  The specific extent to which bad performance harms SEO ranking is unknown, but Google and their developer advocates have made numerous public statements confirming that sites with poor Lighthouse scores will be ranked lower than sites with good Lighthouse scores. Which brings us to Lighthouse and our next important question.

How do you measure and evaluate core web vitals?

Lighthouse collects "Lab data" (also known as synthetic data) from a controlled environment to measure different web vitals. It is important to note that this data is not derived from actual users since it's going to run scripts with synthetic data.

This puts them in sharp contrast with real user metrics (RUM) since the data can be collected during the development process and incorporated into CI processes. Another example of a tool that collects synthetic data is WebPageTest.

On the other hand, Google’s Page Speed Insights provides results that are based on a mixture of real-world data and lab data, which can provide another perspective of a site’s performance.

What are the Primary Vitals and what do they measure?

There are many web vitals you can track, but there are specifically three that are referred to as Core Web Vitals. These metrics are:

Largest Contentful Paint: when the largest element on the page becomes visible, which helps Google understand how users will perceive page load speed.

First Input Delay: how long it takes before the user can interact with the content they see on the page, telling Google how quickly the page becomes “usable” from the user perspective.

Cumulative Layout Shift: how much the elements on the page move around while the page is loading, which helps Google evaluate how stable the user’s experience on the page will be.

Let’s take a closer look at each of these metrics and how you can improve them.

Largest Contentful Paint (LCP) and how to improve it

Largest Contentful Paint (LCP) observes the time needed for the largest element to load and appear on the user’s screen. This is important because users want to be immediately served viewable content when they open the page instead of having to wait and stare at a blank screen. According to Google, the following elements are considered for Largest Contentful Paint:

Tags loading a background image with the `url()` function

Block-level tags containing nodes or inline-level text elements.

The element size that is reported will usually be determined by the size that is visible to users within the viewport. Elements that extend outside the viewport do not count toward the final size. Google's guidelines advise aiming for less than 2.5 seconds across 75% or more of page visits.

To achieve this, Google recommends eliminating resource load delay and element render delay along with reducing resource load time and time to first byte (to understand these terms better, you can find them here, in Google’s documentation).

To reduce your LCP scores, consider the following strategies:

Load CSS stylesheets and JavaScript files asynchronously to eliminate render-blocking resources. Alternatively, the resources can be inlined directly inside the HTML.

Use `DNS-prefetch` or `preconnect` resource hints to initiate an early connection to any required third-party origins.

Defer unused or unnecessary JavaScript that delays rendering the page.

Compress and resize images to ensure as few bytes as possible are sent over the network.

You can observe granular timing information in JavaScript by utilizing performance APIs such as the Largest Contentful Paint API, the Navigation Timing API, and the Resource Timing API.

First Input Delay (FID) and how to improve it

First Input Delay (FID) detects the length of time from a user interacting with a page for the first time to the browser being able to process a response to that interaction.

For example, it would detect the length of time between when a user clicks a link on the page and when the browser responds to their click by processing event handlers. FID is calculated even if an event listener hasn’t been registered.

HTML elements like `<input>`, `<textarea>`, `<select>`, and `<a>` must wait for the browser’s main thread to complete any tasks that are in progress before they can respond to user interactions.

Google's guidelines advise aiming for 100 milliseconds or less for FID across at least 75% of page loads.

To achieve the ideal FID, Google recommends breaking up long tasks, optimizing the page for interaction readiness by minimizing the data needed for post-processing on the client, and freeing up more capacity on the main thread.

To reduce your FID scores, consider the following strategies:

Offload computation to a web worker so the main thread is not blocked. Partytown is a library built specifically for this task and can be integrated with many popular JavaScript frameworks.

Minimize work on the main thread since the less work the main thread has to do, the more responsive it will be to input events. To minimize this work, use efficient algorithms and data structures. For example, don’t sort an array of 10 items when only the first five items are needed. Break up work into smaller chunks such as parsing a large JSON file in pieces instead of all at once.

Use `requestIdleCallback()` API to allow developers to schedule work to be done when the main thread is idle. Low-priority work can be performed in the background without disturbing any latency-sensitive events. It’s similar to `setTimeout()`, but instead of scheduling work to be done as soon as possible, `requestIdleCallback()` schedules work to be done when the main thread is idle. If there’s no idle time before the scheduled time, work will happen immediately.

Cumulative Layout Shift (CLS) and how to improve it

Cumulative Layout Shift (CLS) measures how much elements on the page move from their initial position as the page loads.

Google guidelines advise having a CLS score of 0.1 or less for 75% of pages or more. They recommend including image dimensions such as `width` and `height` size attributes, anticipating and alleviating layout shifts from advertisements, avoiding dynamically inserting new content on top of existing content, and using `transform` animations.

How can I reduce my Cumulative Layout Shift?

To reduce your Cumulative Layout Shift, consider the following strategies:

Lazy-load offscreen images and videos rather than loading all images and videos when the page first loads. Only loading those that are visible in the viewport reduces the amount of layout shifts that can occur as new content is loaded.

Minimize third-party scripts by reducing or eliminating scripts that aren’t needed for your page to function. These can cause unexpected layout shifts when they load.

Under the "Core Web Vitals" section of Google Search Console you can find a report on your site's CLS score. This report can help you identify specific URLs that are affecting your score.

How Web Vitals patterns can further improve performance

The Web Vitals patterns are a curated selection of patterns designed to attain high scores on Core Web Vitals. They target common UI components that are frequently difficult to optimize. web.dev provides a list of these patterns and recommendations for how to avoid common problems:

Carousel - A component that displays content like a slideshow with each image cycled through, one by one. A page’s LCP element can be contained within large carousels above the fold and impact LCP scores. CSS scroll snaps can be used to create transitions free of layout shifts.

Fonts - Browsers typically delay rendering any text that uses a web font that hasn't been loaded yet. FCP and LCP can be delayed due to fonts loading too late and layouts can shift when the text finally renders the correct font. This can be avoided by using inline font declarations, the WOFF2 font format, or preconnect resource hints. See web.dev's Best practices for fonts for more details on those techniques.

Images - Layout shift can be caused by images if they load after the rest of the page has already been rendered. This happens more often with slow-loading images due to weak internet connections or images with large file sizes. This can be avoided by specifying the width and height of the image or by using density descriptors.

Infinite Scroll - A continuous stream of content is loaded and appended to the page as the user continues to scroll past the end of the currently available content. This technique may lead to layout shifts with some implementations. See web.dev’s infinite scroll implementation for an example of how to use JavaScript when creating an infinite scroll to avoid causing any layout shifts.

Banners and Notices - Banners and notices commonly cause layout shifts because lower page elements are pushed further down the page when a banner is inserted into the DOM after the rest of the page has already been rendered. Adding a banner that slides in from the bottom can avoid layout shift. Modals can also be used as alternatives to banner notices.

Placeholders - One solution to layout shifts that occur from injected page content is reserving space for anticipated content with a placeholder. They can also be used along with lazy-loading to visually indicate to the user that fresh content is loading.

Video - Video can cause layout shifts and can also delay LCP by monopolizing network resources. This delays the loading of other page resources. The `<video>` tag can be used to display a poster image which doesn't cause layout shift.

Core Web Vitals are a collection of metrics designed to capture important aspects of the user experience. They can be a complex and bewildering array of metrics. Thankfully, the creators behind these metrics have gone to great lengths to explain the purpose of each metric and how to address them. Google provides tools to help developers measure their Core Web Vitals scores and offers recommendations on how to improve them.

Some common techniques for improving Core Web Vitals scores include optimizing images, fonts, and videos; reserving space for content with placeholders; and using alternatives to banner ads and modals. By taking the time to improve their site's performance on these metrics, developers can make a real difference in the user experience of their visitors all over the world. And furthermore, they can impact the business outcomes that their websites are designed to support.

Next.js has embraced TypeScript in recent years. Together we will explore how to set up a new Next.js project with TypeScript, how to migrate an existing Next.js project to TypeScript, and common pitfalls that developers should be aware of when using TypeScript and Next.js together.

Next.js + TypeScript: Tips and FAQs for Every Stage of Your Journey

TypeScript has increasingly become a standard tool for web developers and one of the most common languages for writing web applications. For evidence of TypeScript's popularity, see the State of JavaScript 2021 survey under the section "JavaScript Flavors" (or languages that compile to JavaScript). TypeScript overwhelmingly comes in first place with 69% of the votes while Elm comes in at second place with 2.4%.

Likewise, Next.js is one of the most popular JavaScript back-end frameworks, coming in at second place after Express with 45% usage. Built with JavaScript originally in mind, Next.js has slowly been embracing TypeScript over the past few years. For example, most of the official examples are now using TypeScript by default.

In this article, we will explore how to set up a new Next.js project with TypeScript, how to migrate an existing Next.js project to TypeScript, and common pitfalls that developers should be aware of when using TypeScript and Next.js together.

Benefits of converting a Next.js project to TypeScript

But why are so many developers using TypeScript instead of "vanilla" JavaScript? To understand this, we must first understand the definition of a type (also called a static type or data type). A type is a programming language concept that defines a set of possible values and a set of allowed operations on it.

A data type tells the compiler or interpreter how the programmer intends to use the data. For example, it says whether you want to use a string or an integer for a particular variable. The benefits from types typically involve increased visibility into the state of your code inside your code editor through VS code's TypeScript language server.

This visibility can lead to the following benefits:

Types enable better introspection, which catches bugs before they have a chance to run in the application.

Code editors are able to provide more intelligent autocompletion.

Error handling can be done even before compile time and surfaced while coding.

Functions, classes, and variables can be renamed automatically in every instance throughout the codebase.

As files are moved around the project, module imports can be appropriately renamed to the new locations.

The benefits of adding types to Next.js itself are similar to the benefits of adding types to React. With React, you're using functional components that can be passed props to customize the data displayed in the components. These props themselves can be typed and the React documentation includes a page on "Type Checking With PropTypes".

Use `create-next-app` with the TypeScript flag to start from scratch

Use any of the following commands to create a Next.js application with TypeScript enabled:

Start the development server with the corresponding CLI tool:

Migrating a Next.js project from JavaScript to TypeScript

If you already have a Next.js project created with JavaScript, you can migrate to TypeScript by following the sequence of instructions presented in this section. First, create a `tsconfig.json` file.

Then, install the TypeScript and type dependencies with any of the following commands:

Next, change any files ending in `js` and `jsx` to `ts` and `tsx` and your project should be all set up for TypeScript! You will also notice that a new file has been created called `next-env.d.ts`.

What purpose does this file serve? TypeScript has two main kinds of files:

`.ts` files are implementation files containing types and executable code and are the files that produce `.js` outputs.

`.d.ts` files are declaration files that contain only type information.

While `next.config.js` must be a JavaScript file since it does not get parsed by Babel or TypeScript, it is possible to add some type checking by using JSDoc like so:

Getting Next.js `getStaticProps` working with TypeScript can be a large pain point when trying to migrate a current Next.js JavaScript application. Vitamindev.com provides a thorough accounting of using `GetStaticProps` and `GetStaticPaths` with TypeScript. You can also find additional discussion about this issue on StackOverflow. The high-level conclusions include:

Using the following types provided by Next.js: `NextPage`, `GetStaticProps`, and `GetStaticPaths`.

Adding additional type safety for props and paths by providing generic types to `NextPage`, `GetStaticProps`, and `GetStaticPaths`.

Next.js specific types and where to include them

Next.js includes a handful of built-in data fetching functions including `getStaticProps`, `getStaticPaths`, and `getServerSideProps`. Each of these includes its own built-in types called `GetStaticProps`, `GetStaticPaths`, and `GetServerSideProps`.

Here is a full-page example using some of these types:

`PageProps` is typed using the inferred return type from `getStaticProps()` and `fetchedData` is typed as the return value of `client.someAPI()`.

`NextApiRequest` and `NextApiResponse` are the built-in types for API routes. These correspond to requests and responses to your serverless functions on each route:

The built-in type `AppProps` can be used for a custom `App` by changing the file name to `./pages/_app.tsx`:

The custom `App` component can be useful for persisting the layout between page changes, keeping state when navigating pages, injecting additional data into pages, and adding global CSS.

Next.js starter projects written in TypeScript

The Next.js team has an officially supported TypeScript example app at next.js/examples/blog-starter. This takes the blog starter that the official Next.js tutorial builds out on the Next.js documentation site. This is the best place to start to see a modern project built with the standards that Next.js believes should be applied to projects today.

However, it will not show you how to integrate many other libraries that may be required for a complete application. If this is important for you, you will want to look at community starters and frameworks that expand upon Next.js by themselves.

There have been numerous different starters created by community members, companies, and popular open-source libraries. Some prominent starters on this list include:

<ixartz/Next-JS-Landing-Page-Starter-Template> - Landing page with Tailwind CSS

jpedroschmitz/typescript-nextjs-starter - Minimal starter with ESLint and Prettier

pankod/superplate - Includes Jest, styled-component, Axios, and various plugins

graphile/starter - Includes GraphQL integration with Apollo and Graphile

trpc/examples-next-prisma-starter - Includes Prisma and tRPC for fullstack, end-to-end type safety

These will provide different flavors and additional libraries for various use cases. These can provide useful inspiration and jumping-off points, but all will have opinions specific to their project's creators.

One fairly recent addition to the increasingly competitive framework landscape is `create-t3-app`. ct3a is an interactive CLI tool that generates a boilerplate Next.js project configured with TypeScript and various other option libraries.

This gives a greater level of flexibility in designing your own project structure compared to community starters. The optional libraries include Tailwind, NextAuth, tRPC, and Prisma. tRPC and Prisma in particular enable end-to-end type safety since Prisma Client is a type-safe database client, and tRPC uses typed remote procedure calls.

The front end is able to seamlessly introspect the back end and become "aware" of the typed models residing within the database. ct3a is especially useful if you are interested in building a full-stack project complete with a database. It's even more useful if your project requires authentication.

Additional considerations, including common pitfalls and how to avoid them

How to integrate other libraries such as Tailwind

For styling libraries like Tailwind, TypeScript is mostly unimportant. This is because CSS cannot be typed like JavaScript, at least not today. One consideration may be including `ts` and `tsx` file extensions in your tailwind.config.js. This is useful if you have a project that is being incrementally migrated to TypeScript and not all files have `ts` and `tsx` extensions yet:

Examples of Next.js projects using TypeScript with different styling libraries such as Tailwind can be found on the Next.js GitHub repo. It is also worth mentioning that the Tailwind CSS VS Code plugin provides autocompletion like TypeScript. As previously discussed, it’s not type checked like the rest of the code, but it gives a TypeScript-like code editor experience.

Type checking can slow down an application if it gets too large. One way to help mitigate this is with incremental type checking. This will tell TypeScript to save information about the project graph from the last compilation to help speed up type checking in bigger applications.

Ignoring TypeScript errors while type checking in production

Sometimes you have some TypeScript errors that you know aren't an issue but are causing your build to crash when running `next build`. If you absolutely have to ignore TypeScript errors in production (which is highly ill-advised), you can do so with the following setting in your `next.config.js` file:

In these situations, it may be tempting to throw an `any` type instead. However, using `any` is effectively the same as `ignoreBuildErrors`, except scoped to a specific location and with negative trickle-down effects. Other strategies, like using `unknown` in place of `any`, type assertion with `as`, and `// @ts-ignore` are better alternatives to `any`.

In this article, we’ve discussed the rising popularity of TypeScript and the benefits of including types in your JavaScript code. We also saw how to create new Next.js projects from scratch and how to migrate existing Next.js projects to TypeScript.

But what is the implication of the Next.js and broader JavaScript framework ecosystem moving to a TypeScript-first world? There are a handful of different implications to consider:

Types may be built into the language itself somehow through the TC39 process. Right now there is a Stage 1 proposal called Type Annotations that may build types directly into the language in a way where they can be ignored by browsers.

Types may become required for many frameworks. `create-t3-app` for example cannot be used with JavaScript at all.

Developers reacting against this trend may become more resistant to using types and build identities around not using TypeScript similar to how people have built identities around using “vanilla JavaScript” instead of frameworks.

More jobs will be looking for developers who know how to use TypeScript or can easily switch between JavaScript and TypeScript.

MACH architecture stands for microservices, API-first, cloud-native, and headless. It's an approach that's part of a growing trend leading teams away from monolithic architectures and toward systems that are more flexible, adaptable, and agile.

10-Minute Read: Understanding MACH Architecture and Its Counterparts

For many businesses, competing in the digital world requires adapting and deploying updates to applications at a rapid pace. As a result, monolithic architecture is becoming a thing of the past for many teams, and taking its place are new approaches, like MACH architecture. While MACH is just one of several similar approaches, it’s an interesting participant in this movement that emphasizes four key areas:

Below, we’ll explore what MACH architecture is, as well as its origin and key principles.

MACH architecture is an approach to building applications that allows developers to build more reliable and usable systems by implementing principles that emphasize composability. 

Origins and Philosophy of the MACH Architecture

The architecture eschews building applications as large, monolithic apps with the frontend and backend all living in a single project. Instead, projects utilizing the MACH architecture leverage microservices, APIs, headless CMSs, and cloud deployment platforms. MACH Architecture is primarily promoted by the MACH Alliance. 

MACH is designed to solve the challenges posed by monolithic applications. But why is monolithic architecture a problem? Monoliths are a powerful force when a product is just getting started and trying to find product-market fit. Monolithic applications can be easily modified and redeployed in the beginning. 

However, as they grow larger, and more teams start to work on a monolithic app, the benefits start to break down. This can lead to communication overhead for the team anytime a change has to be made to the application. If a change in one part of the application can have unintended downstream effects on other parts of the application, engineers on every critical component will need to be consulted to ensure that no business functionality will be disrupted.

How does MACH solve the problems of previous architectures?

Monolithic architecture breaks down because different parts of the project become tightly coupled. Making a change in one part of the application cannot be separated from the rest of the application. This means that a single change leads to the entire project needing to be tested and redeployed.

If the different concerns of the application are decoupled, then they can be worked on, tested, and deployed independently of one another. This can be achieved in many different ways by implementing composable architecture. MACH architecture is not just making the case for a composable architecture, though; it is also suggesting specific types of decoupled architectures and deployment paradigms (more on this later).

How does this relate to Composable Commerce or the Smoke Stack?

The great thing about good ideas is that they're guaranteed to be reappropriated multiple times over with different branding. MACH architecture is just one of many different brands for this new programming paradigm and larger movement away from monolith applications to more composable approaches. Other common terms include composable commerce, the SMOKEstack, and API-first architecture.

According to Sitecore, composable commerce is a development approach of selecting best-of-breed commerce components and combining or ‘composing’ them into a custom application built for specific business needs. Redmonk defines the SMOKEstack as Serviceful, Mashable, Open, K(C)composable, and Event-driven. Not to be outdone, Gartner suggests that the future of business itself is composable.

What does MACH stand for and why are these values important?

MACH stands for microservices, API-first, cloud-native, and headless. We will explore each of these virtues individually to explain what they are and why they are important.

Microservices - Individual programs delineated by business functionality

Microservices are an offshoot of service-oriented architecture, which emphasized having individual, discrete services instead of monolithic applications. Microservices take it a step further by advocating for even smaller, decoupled services that interact with each other through clearly defined APIs that define single responsibilities.

They allow for developing, updating, and scaling specific, independent pieces of an application. This reduces risk and impact if something does go wrong. Phased roll-outs can be executed for light prototypes and gradual replacement of services over time. The ability to slot in different pieces also enables selecting optimal approaches for different functionalities.

API-first - All functionality specified and exposed through APIs

Paul Graham said, ”an API is to a piece of software what falsifiable predictions are to a scientific theory.” This means that an API requires a clear definition of intended behavior from a piece of software. Inputs must lead to predictable outputs. Once an API contract has been defined, users can depend on that API always behaving the same way.

This predictability allows for building workflows and more complicated functionality on top of the baseline functionality. APIs are also beneficial because they can provide a wide array of pre-built functionality that can be reused from one application to another.

You may have also heard of the Jamstack, an architectural style originally defined by Netlify, which included JavaScript, APIs, and markup. The acronym is no longer associated with the term, but the Jamstack still lives on APIs. These APIs can expose functionality or content. There are now hundreds of different companies exposing APIs of all different types.

Cloud-native - Utilizes third-party infrastructure hosting providers

One of the biggest software trends of the last decade has been the move to the cloud. It has allowed for more flexibility and scalability for businesses of all sizes. This has been led by pioneers like AWS and imitators like GCP and Azure.

These companies rent out their excess servers to customers looking for computing, storage, and networking capabilities. Since AWS defined the cloud landscape, we have seen a number of "layer 2" clouds, which build services on top of the layer 1 clouds. These services can provide nicer UIs and simpler workflows for working with cloud services.

But regardless of which layer of the cloud you are using, there is a very good chance that you are not racking and stacking your own servers these days. Since keeping a global network of computers available, performant, and secure requires hiring an entire team of DevOps and Site Reliability Engineers, using the cloud can lead to massive operational cost savings.

Headless - Decouples the backend for flexibility in frontend development

To make a system composable, it is useful to separate out the presentation from the content itself. Headless APIs give the ability of consuming data from an API and displaying it with a developer’s tool of choice.

Whether using React, Vue, Svelte, Solid, or just vanilla JavaScript, a headless API can be consumed by any kind of frontend. This is useful for developers who want to use their own preferred tool, but it’s also useful if a frontend needs to be quickly swapped out for a different frontend.

As long as the backend is always exposing a clear contract through an API (as explained in the previous section), then the frontend can be easily replaced with another frontend accessing the same API. SaaS headless services can also do all of the work of maintaining the editing and content management UI for you, so that you can focus elsewhere.

Who is using the MACH Architecture today?

Founded in June 2020, the MACH Alliance was referred to as ‘The Coolest Tech in Town Club’ by Forrester. The MACH Alliance has companies and individuals as members with over 50 member companies in three categories: vendors, system integrators, and enablers. MACH Ambassadors advocate for the architecture and are individual expert members with no ties to any of the member companies.

MACH Architecture is more of a descriptive than prescriptive architecture. It describes a shift that is already being observed in companies that are moving away from monolithic architectures. By decomposing their applications, companies find patterns that allow them to move faster and more reliably, which is essential in the modern landscape.

These patterns typically involve using APIs and microservices hosted in the cloud with a focus on a headless approach between the frontend and backend. By separating out the core units of business logic, teams can become more autonomous and confident in their ability to continually improve their own systems.

Understanding MACH Architecture and Its Counterparts

Despite the differences between the frameworks, a React developer should not have too much trouble picking up a Vue project. It still uses components that include a mixture of JavaScript, CSS, and HTML. However, Vue includes a more concise syntax and a cleaner separation between content, styling, and logic.

Trying Vue as a React Developer: A Quick Introduction

For the last decade, the preferred mode of front-end web development has been architecting applications with JavaScript. Today, among the numerous options, React is the dominant framework of choice for front-end web development. According to the State of JS survey, it has been the number one most-used front-end framework every year since 2016.

However, there has been a steady increase in the usage of Vue instead of React. It has developed its own ecosystem completely separate from React over the years including build tools, meta-frameworks, routers, state managers (like Pinia), component libraries, and more. But what is the reasoning behind this increase in Vue usage? There are many reasons that developers may choose one over the other.

Some developers prefer supporting a community-run project over a project managed by a large corporation. Others find React too complex in comparison to Vue. Some developers also find the separation of content, styling, and logic in a Vue single file component to be more intuitive than the separation of concerns within a JSX file. In this article, we will compare a Vue project to equivalents in React so you can decide for yourself which you find more intuitive.

Evan You created Vue in 2014, taking inspiration from AngularJS and React, which were sponsored by Google and Facebook respectively. Unlike those frameworks, though, Evan was the primary driving force behind the creation and development of the framework. This allowed him to take on different influences from a framework like React, for example, where development has been highly intertwined with the needs of Facebook.

Comparing Vue project structure and syntax

Let’s start with the overall project structure. One way that React and Vue are similar, is their use of an HTML entry file called `index.html`, a JavaScript entry file called `main.js`, and an application entry file called `App.jsx` in React or `App.vue` in Vue.

The HTML entry point will load the application from `main.js` (in Vue or React). The JavaScript entry point imports the top-level application component `App.vue`, so any plugins or integrations can be imported into the JavaScript entry file without interfering with any of the application logic.

However, when it comes to the syntax, we’ll start to see key differences. Vue’s syntax and directives are influenced by AngularJS and include common operations such as for loops (`v-for`), conditionals (`v-else-if`), and event handling (`v-on`). The underlying implementation uses a virtual DOM like React for quickly reconciling DOM manipulations with a declarative syntax.

React, on the other hand, uses JSX so the developer can write for loops, conditionals, and event handlers the usual way with JavaScript. This results in a file containing JavaScript functions at the top and a return function at the bottom. The return function outputs HTML containing any JavaScript variables defined above the function.

This example does not include any CSS, although it is possible to include CSS in a React component with a library like Styled Components or Emotion. 

However, unlike React with JSX, Vue breaks up a single file component into three clearly delineated parts: `script`, `template`, and `style`.

This roughly corresponds to the three languages used to build all websites: JavaScript, HTML, and CSS. If we were to view this component in a web browser, it would look like the following:

Now that we’ve talked a little bit about the similarities and differences between React and Vue, let’s look at a small Vue project and how it would compare to a React project. To tour the Vue project with me, spin up a Stackblitz by clicking here.

Of course this Vue project requires slightly different dependencies from what you’d see in React, which you can see in the `package.json` file. You’ll see  `vue` as a project dependency and two development dependencies: `vite` and `@vitejs/plugin-vue`.

If this were a React project, you would see `react` and `react-dom`.

For the project files, you’ll see an HTML entry point file, a main function, application entry point, `HelloWorld` component, and configuration files for Vite. Notice these files in the root of your project directory:

`vite.config.js` - Vite configuration file for the Vue or React plugin

`index.html` - HTML entry file for initializing our application

There will also be two files in the `src` folder (along with two folders):

`main.js` - Root component that imports the Vue application

`App.vue` - Main application with imports for our components

And finally a single file in the `components` folder:

`HelloWorld.vue` - `HelloWorld` component with stateful logic

Overall, the boilerplate files needed for a Vue application and React application should look very similar, especially if you are leveraging Vite for your React applications.

Since Vite supports multiple front-end frameworks including React, the code below in the `vite.config.js` file in the root directory tells Vite that you are developing a Vue project specifically.

Like React, Vue also uses an entry HTML file with a `div` that loads your entire application at once, which you can see in the code below, found in `index.html`.

If this was a React app, the only difference would be replacing `/src/main.js` with `/src/main.jsx` in the script tag.

As we saw previously, inside the `body` tags of our HTML entry file we load `main.js` as a script using the `type` attribute to load a JavaScript `module`. Our `main.js` file is located in our `src` folder.

This file is only used to import `createApp` from the `vue` library and our `App` from `App.vue`, also contained in the `src` directory. Here is the equivalent file in a React application for comparison:

`createRoot` from `ReactDOM` is used to set the application to root with `getElementById`. The `App` is then rendered as a self-closing tag.

As we saw earlier, a single file component in Vue contains a script for any JavaScript code, a template for HTML content, and styling for CSS.

The equivalent React component would import `HelloWorld` and then declare an `App` function that returns the `HelloWorld` component.

Within these components, the organization of concerns shows one of the major contrasts between React and Vue.

Our `App.vue` file is importing the `HelloWorld` component from `HelloWorld.vue`. This file is located inside the `components` folder.

And all of this comes together like this:


Many React developers are aware of “React meta-frameworks” such as Next.js, Gatsby, or RedwoodJS. Vue has similar meta-frameworks including Nuxt.js and Gridsome. Nuxt.js is heavily inspired by Next.js and includes the majority of the same features including SSR, API routes, serverless function integration, and third-party modules.

These frameworks provide additional features such as static site generation, server-side rendering, and authentication. Some of the requirements that would lead a developer to use a meta-framework include SEO optimization, internationalization, localization, or user management and authentication.

Despite the differences between the frameworks, a React developer should not have too much trouble picking up a Vue project. It still uses components that include a mixture of JavaScript, CSS, and HTML. However, Vue includes a more concise syntax and a cleaner separation between content, styling, and logic. The build tooling for both development and the production pipeline is nearly identical, especially now as Vite becomes more popular for React projects.

The Vue ecosystem offers higher-level frameworks for building faster and more reliably on real-world applications. Vue does not have as many third-party libraries as React, but there are still options for most of the tools that a React developer would expect including state management, UI libraries, and reusable components. Overall, with a little bit of research and practice, a React developer should feel confident performing just as efficiently with a Vue project as they do on a React project.

With key metrics and an understanding of how CSS frameworks evolved, you'll have the tools to make an informed choice about which CSS framework is best for you.

Anthony Campolo

[Guide] Core Web Vitals: What They Are and How to Improve Them

Next.js + TypeScript: Tips and FAQs for Every Stage of Your Journey

Understanding MACH Architecture and Its Counterparts

Trying Vue as a React Developer: A Quick Introduction

How to Choose the Best CSS Framework: Understanding Metrics and Context

Remix vs. Next: Which React Meta-Framework Should You Use?

Deliver a website with a visual Page Builder for your marketing team