ReactJS

Getting Started with GatsbyJS

Published Dec 14, 2020

Updated Feb 14, 2023

7 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

GatsbyJS is a React framework and a Static Site Generator (SSG) tool used in building web applications. It combines Server Side Rendering (SSR) features, and static site development for building SEO-powered, secured, and fast applications.

In this article we’ll start with an introduction to Gatsby, we’ll learn the terms SSG, CSR, and SSR, how Gatsby improves SEO, and then we’ll build a simple website with Gatsby.

Introduction

GatsbyJS is built on React. React is a frontend UI library for frontend implementations. It supports the idea of small components that merges with other components to make bigger components.

As a UI library, React is a tool that can be combined with other tools for building web applications. Therefore, React on its own may require other tools (like routing tools, webpack server, and so on) for building full-fledged frontend applications.

With that being said, when you install React, you need to install other tools to make up your application. This results in an opinionated setup aided by Create React App (CRA). Despite this, more configurations and tools needed to be installed for a full application.

Then, Gatsby!

Gatsby is an opinionated framework that takes away the hassle of setting up the application and allows you to begin development immediately. Asides from this, Gatsby also solves the issue of Search Engine Optimisation (SEO) that using only React provides. react-helmet is not an effective SEO solution. This article explains that further.

SSR, CSR, and SSG

Client-Side Rendering (CSR)

In CSR, all routings and renderings are handled by the browser with JavaScript. For this technique, different HTML files are not created for different pages, instead, one page referencing some JavaScript files that determine what to display depending on the URL. React is a CSR tool. This means all routings are handled by the browser. In React, you have an index.html file found in the public folder which codes similar to this:

<html>
  <head>
    <title>React App</title>
  </head>
  <body>
    <div id='root'></div>
  </body>
</html>

After the build process (npm run build), the index.html will look like this:

<html>
  <head>
    <title>React App</title>
  </head>
  <body>
    <div id='root'></div>
    ...
    <script src="/static/js/2.711c516a.chunk.js"></script>
    <script src="/static/js/main.139dd313.chunk.js"></script>
  </body>
</html>

The referenced .js files handles all routings and responds to the URL with contents to share. build/index.html is only fetched once, also with the JavaScript files. This may result in low page load speed due to fetching all resources. This method affects SEO in such a way that SEO crawlers only see <title>React App</title> and does not see every other meta changes because those changes only happen when libraries like react-helmet are executed (which is only on the browser).

Server Side Rendering

In contrast to CSR, SSR involves populating the browser with resources from the server. This means that for every route change, a request is made to the server to fetch new resources. SSR is perfect for SEO because SEO crawlers get the right meta information when any page is requested. SSR also has its cons, one of which is a delay when navigating between pages. CSR wins in this area because all JavaScript resources are fetched on the first request and every other navigation does not need a page refresh.

Static Site Generator

An SSG is a tool or set of tools that create static HTML pages from input files or content sources. Many SSG tools work in various ways but most of them take away the issues of security and slow fetching that database-driven platforms use. SSG takes content from different sources and builds them all into static pages which can be accessed faster when fetched by a browser.

How Gatsby improves SEO

Gatsby is an SSG tool that solves the issue of SEO that CSR brings and also makes routing faster compared to SSR. Gatsby does this by pre-building the web application before it is hosted. During the build process, all meta information provided within components is attached to the built pages. So when SEO crawlers or social sharing tools access any page of the application, they get access to the meta-information that has been provided to all pages during development. This does not involve any rendering in the browser. The built files are static pages which looks like each page was built separately like so:

<!-- /about -->
<html>
<head>
  <title>About us</title>
</head>
</html>

Building a simple website with Gatsby

To show how Gatsby sites are built, we’ll be building a very simple website. No much complexities or dynamics, just simple.

Install the CLI tool

Firstly, install the gatsby CLI tool. Or you can use npx if that’s what you want.

npm i -g gatsby-cli

Create new site

You can either create a new Gatsby site with a basic template ([gatsby-starter-default]9https://www.gatsbyjs.com/starters/gatsbyjs/gatsby-starter-default/)) provided by the team, or use a specify another template to customize.

For the default template, a new site is created like so:

gatsby new new-site

Where new-site is the name of the project you’re creating.

This gives the following project structure:

The template provides SEO configurations using GraphQL which you can improve. To see the site in action, run:

gatsby develop

At localhost:8000, you’ll find your site displayed like so:

Alternatively, you can specify a template you want to use. You can find different starter templates from their list of starter libraries.

To use a template, say, gatsby-starter-blog, the following command will be used:

gatsby new my-gatsby-project https://github.com/gatsbyjs/gatsby-starter-blog

This gives the following project structure:

On starting the development server, localhost:8000 shows this:

Improving the gatsby-starter-default template

The template has three folders under src namely components, images and pages. The components and images page are optional, but pages is a required page for Gatsby. Unlike React, where you need a router library to show a set of components for a particular URL, in Gatsby, you create pages by having React JavaScript files under the pages folder.

Let’s add an about page under pages like so:

In about.js, you can create your React components or import components. For example:

import React from "react"
import Layout from "../components/layout"
import SEO from "../components/seo"
const About = () => {
  return (
    <Layout>
      <SEO title="About my website" />
      <h1>About my beautiful website</h1>
    </Layout>
  )
}
export default About

SEO is a component that dynamically updates meta information about each pages and Layout is a wrapper component that serves as the layout of all pages. This can be configured to fit your needs too.

When you start your development server, go to localhost:8000/about and you’ll find this:

Note that: whatever you can do in React (components structuring, prop-types, and so on), you can do the same in Gatsby. Gatsby makes things easier allow you to focus on the important parts of your application and pre-building your site to make SEO-fit. Also, Gatsby makes your site fast and since they are static pages, they can be served from anywhere (like CDNs).

Conclusion

Gatsby goes beyond the general understanding of “static pages”. Gatsby can source content from Content Management Systems and build static pages for them. An example is gatsby-source-instagram. It sources content from Gatsby at every building process, source the latest content from Instagram, and makes them available on your website.

There a lot of other awesome applications that can be achieved by using Gatsby, such as e-commerce tools, portfolios, and so on. Here's a gallery of sites using Gatsby.

Another beautiful thing about Gatsby is the community. You’ll find a ton of plugins that make development easier and more effective.

This article gives introductory information on what makes Gatsby an awesome tool. There are still more to learn to make the best use of Gatsby such as Gatsby and GraphQL, SSR APIs, and many more. Their documentation gives a very great guide to learning more about the tool.

I hope this article gives you reasons to try out Gatsby in your next project.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Dillion Megida

Loves learning, building and teaching tech.

@iamdillion @dillionmegida

How to build an AI assistant with OpenAI, Vercel AI SDK, and Ollama with Next.js

In today’s blog post, we’ll build an AI Assistant using three different AI models: Whisper and TTS from OpenAI and Llama 3.1 from Meta. While exploring AI, I wanted to try different things and create an AI assistant that works by voice. This curiosity led me to combine OpenAI’s Whisper and TTS models with Meta’s Llama 3.1 to build a voice-activated assistant. Here’s how these models will work together: * First, we’ll send our audio to the Whisper model, which will convert it from speech to text. * Next, we’ll pass that text to the Llama 3.1 model. Llama will understand the text and generate a response. * Finally, we’ll take Llama’s response and send it to the TTS model, turning the text back into speech. We’ll then stream that audio back to the client. Let’s dive in and start building this excellent AI Assistant! Getting started We will use different tools to build our assistant. To build our client side, we will use Next.js. However, you could choose whichever framework you prefer. To use our OpenAI models, we will use their TypeScript / JavaScript SDK. To use this API, we require the following environmental variable: OPENAI_API_KEY— To get this key, we need to log in to the OpenAI dashboard and find the API keys section. Here, we can generate a new key. Awesome. Now, to use our Llama 3.1 model, we will use Ollama and the Vercel AI SDK, utilizing a provider called ollama-ai-provider. Ollama will allow us to download our preferred model (we could even use a different one, like Phi) and run it locally. The Vercel SDK will facilitate its use in our Next.js project. To use Ollama, we just need to download it and choose our preferred model. For this blog post, we are going to select Llama 3.1. After installing Ollama, we can verify if it is working by opening our terminal and writing the following command: Notice that I wrote “llama3.1” because that’s my chosen model, but you should use the one you downloaded. Kicking things off It's time to kick things off by setting up our Next.js app. Let's start with this command: ` After running the command, you’ll see a few prompts to set the app's details. Let's go step by step: * Name your app. * Enable app router. The other steps are optional and entirely up to you. In my case, I also chose to use TypeScript and Tailwind CSS. Now that’s done, let’s go into our project and install the dependencies that we need to run our models: ` Building our client logic Now, our goal is to record our voice, send it to the backend, and then receive a voice response from it. To record our audio, we need to use client-side functions, which means we need to use client components. In our case, we don’t want to transform our whole page to use client capabilities and have the whole tree in the client bundle; instead, we would prefer to use Server components and import our client components to progressively enhance our application. So, let’s create a separate component that will handle the client-side logic. Inside our app folder, let's create a components folder, and here, we will be creating our component: ` Let’s go ahead and initialize our component. I went ahead and added a button with some styles in it: ` And then import it into our Page Server component: ` Now, if we run our app, we should see the following: Awesome! Now, our button doesn’t do anything, but our goal is to record our audio and send it to someplace; for that, let us create a hook that will contain our logic: ` We will use two APIs to record our voice: navigator and MediaRecorder. The navigator API will give us information about the user’s media devices like the user media audio, and the MediaRecorder will help us record the audio from it. This is how they’re going to play out together: ` Let’s explain this code step by step. First, we create two new states. The first one is for keeping track of when we are recording, and the second one stores the instance of our MediaRecorder. ` Then, we’ll create our first method, startRecording. Here, we are going to have the logic to start recording our audio. We first check if the user has media devices available thanks to the navigator API that gives us information about the browser environment of our user: If we don’t have media devices to record our audio, we just return. If they do, then let us create a stream using their audio media device. ` Finally, we go ahead and create an instance of a MediaRecorder to record this audio: ` Then we need a method to stop our recording, which will be our stopRecording. Here, we will just stop our recording in case a media recorder exists. ` We are recording our audio, but we are not storing it anywhere. Let’s add a new useEffect and ref to accomplish this. We would need a new ref, and this is where our chunks of audio data will be stored. ` In our useEffect we are going to do two main things: store those chunks in our ref, and when it stops, we are going to create a new Blob of type audio/mp3: ` It is time to wire this hook with our AudioRecorder component: ` Let’s go to the other side of the coin, the backend! Setting up our Server side We want to use our models on the server to keep things safe and run faster. Let’s create a new route and add a handler for it using route handlers from Next.js. In our App folder, let’s make an “Api” folder with the following route in it: We want to use our models on the server to keep things safe and run faster. Let’s create a new route and add a handler for it using route handlers from Next.js. In our App folder, let’s make an “Api” folder with the following route in it: ` Our route is called ‘chat’. In the route.ts file, we’ll set up our handler. Let’s start by setting up our OpenAI SDK. ` In this route, we’ll send the audio from the front end as a base64 string. Then, we’ll receive it and turn it into a Buffer object. ` It’s time to use our first model. We want to turn this audio into text and use OpenAI’s Whisper Speech-To-Text model. Whisper needs an audio file to create the text. Since we have a Buffer instead of a file, we’ll use their ‘toFile’ method to convert our audio Buffer into an audio file like this: ` Notice that we specified “mp3”. This is one of the many extensions that the Whisper model can use. You can see the full list of supported extensions here: https://platform.openai.com/docs/api-reference/audio/createTranscription#audio-createtranscription-file Now that our file is ready, let’s pass it to Whisper! Using our OpenAI instance, this is how we will invoke our model: ` That’s it! Now, we can move on to the next step: using Llama 3.1 to interpret this text and give us an answer. We’ll use two methods for this. First, we’ll use ‘ollama’ from the ‘ollama-ai-provider’ package, which lets us use this model with our locally running Ollama. Then, we’ll use ‘generateText’ from the Vercel AI SDK to generate the text. Side note: To make our Ollama run locally, we need to write the following command in the terminal: ` ` Finally, we have our last model: TTS from OpenAI. We want to reply to our user with audio, so this model will be really helpful. It will turn our text into speech: ` The TTS model will turn our response into an audio file. We want to stream this audio back to the user like this: ` And that’s all the whole backend code! Now, back to the frontend to finish wiring everything up. Putting It All Together In our useRecordVoice.tsx hook, let's create a new method that will call our API endpoint. This method will also take the response back and play to the user the audio that we are streaming from the backend. ` Great! Now that we’re getting our streamed response, we need to handle it and play the audio back to the user. We’ll use the AudioContext API for this. This API allows us to store the audio, decode it and play it to the user once it’s ready: ` And that's it! Now the user should hear the audio response on their device. To wrap things up, let's make our app a bit nicer by adding a little loading indicator: ` Conclusion In this blog post, we saw how combining multiple AI models can help us achieve our goals. We learned to run AI models like Llama 3.1 locally and use them in our Next.js app. We also discovered how to send audio to these models and stream back a response, playing the audio back to the user. This is just one of many ways you can use AI—the possibilities are endless. AI models are amazing tools that let us create things that were once hard to achieve with such quality. Thanks for reading; now, it’s your turn to build something amazing with AI! You can find the complete demo on GitHub: AI Assistant with Whisper TTS and Ollama using Next.js...

Sep 27, 2024

8 mins

AINextJSJavaScript

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

The HTML Dialog Element: Enhancing Accessibility and Ease of Use Dialogs are a common component added to applications, whether on the web or in native applications. Traditionally there has not been a standard way of implementing these on the web, resulting in many ad-hoc implementations that don’t act consistently across different web applications. Often, commonly expected features are missing from dialogs due to the complexity of implementing them. However, web browsers now offer a standard dialog element. Why use the dialog element? The native dialog element streamlines the implementation of dialogs, modals, and other kinds of non-modal dialogs. It does this by implementing many of the features needed by dialogs for you that are already baked into the browser. This is helpful as it reduces the burden on the developer when making their applications accessible by ensuring that user expectations concerning interaction are met, and it can also potentially simplify the implementation of dialogs in general. Basic usage Adding a dialog using the new tag can be achieved with just a few lines of code. ` However, adding the dialog alone won’t do anything to the page. It will show up only once you call the .showModal() method against it. ` Then if you want to close it you can call the .close() method on the dialog, or press the escape key to close it, just like most other modals work. Also, note how a backdrop appears that darkens the rest of the page and prevents you from interacting with it. Neat! Accessibility and focus management Correctly handling focus is important when making your web applications accessible to all users. Typically you have to move the current focus to the active dialog when showing them, but with the dialog element that’s done for you. By default, the focus will be set on the first focusable element in the dialog. You can optionally change which element receives focus first by setting the autofocus attribute on the element you want the focus to start on, as seen in the previous example where that attribute was added to the close element. Using the .showModal() method to open the dialog also implicitly adds the dialog ARIA role to the dialog element. This helps screen readers understand that a modal has appeared and the screen so it can act accordingly. Adding forms to dialogs Forms can also be added to dialogs, and there’s even a special method value for them. If you add a element with the method set to dialog then the form will have some different behaviors that differ from the standard get and post form methods. First off, no external HTTP request will be made with this new method. What will happen instead is that when the form gets submitted, the returnValue property on the form element will be set to the value of the submit button in the form. So given this example form: ` The form element with the example-form id will have its returnValue set to Submit. In addition to that, the dialog will close immediately after the submit event is done being handled, though not before automatic form validation is done. If this fails then the invalid event will be emitted. You may have already noticed one caveat to all of this. You might not want the form to close automatically when the submit handler is done running. If you perform an asynchronous request with an API or server you may want to wait for a response and show any errors that occur before dismissing the dialog. In this case, you can call event.preventDefault() in the submit event listener like so: ` Once your desired response comes back from the server, you can close it manually by using the .close() method on the dialog. Enhancing the backdrop The backdrop behind the dialog is a mostly translucent gray background by default. However, that backdrop is fully customizable using the ::backdrop pseudo-element. With it, you can set a background-color to any value you want, including gradients, images, etc. You may also want to make clicking the backdrop dismiss the modal, as this is a commonly implemented feature of them. By default, the <dialog> element doesn’t do this for us. There are a couple of changes that we can make to the dialog to get this working. First, an event listener is needed so that we know when the user clicks away from the dialog. ` Alone this event listener looks strange. It appears to dismiss the dialog whenever the dialog is clicked, not the backdrop. That’s the opposite of what we want to do. Unfortunately, you cannot listen for a click event on the backdrop as it is considered to be part of the dialog itself. Adding this event listener by itself will effectively make clicking anywhere on the page dismiss the dialog. To correct for this we need to wrap the contents of the dialog content with another element that will effectively mask the dialog and receive the click instead. A simple element can do! ` Even this isn’t perfect though as the contents of the div may have elements with margins in them that will push the div down, resulting in clicks close to the edges of the dialog to dismiss it. This can be resolved by adding a couple of styles the the wrapping div that will make the margin stay contained within the wrapper element. The dialog element itself also has some default padding that will exacerbate this issue. ` The wrapping div can be made into an inline-block element to contain the margin, and by moving the padding from the parent dialog to the wrapper, clicks made in the padded portions of the dialog will now interact with the wrapper element instead ensuring it won’t be dismissed. Conclusion Using the dialog element offers significant advantages for creating dialogs and modals by simplifying implementation with reasonable default behavior, enhancing accessibility for users that need assistive technologies such as screen readers by using automatic ARIA role assignment, tailored support for form elements, and flexible styling options....

Oct 25, 2024

4 mins

HTMLJavaScript

Building SEO-Powered Websites With Gatsby

Gatsby is a framework that leverages React for building SEO-powered websites. Many websites are created to be discovered, hence, SEO support is an important factor in such websites. Many factors influence SEO such as accessibility, correct meta-information (at the head tag) and some other external tools. Gatsby supports using appropriate meta information for individual pages to improve their presence online. In this article, we'll look at the limitations of Create React App in respect to SEO, and how Gatsby solves this with SSR. Furthermore in the article, we'll go through a tutorial on building a basic website with good SEO. Why CRA is not a good tool for SEO CRA is an opinionated tool used for building React applications but cannot be used for SEO. Here's why: When using React, you'll most probably be using a library like react-helmet (a document head manager for React) for updating meta-information about the site. The limitations of such libraries is that they contain JavaScript, which means they can only be executed on the browser (so JavaScript can run). SEO crawlers or social media tools that inspect head tags of websites (to display a card, perhaps) would not execute that JavaScript. Instead, they make use of the default meta information they can find. In CRA, the default title in public/index.html is "React App". This means, for every page you create (based on routes), they will all have the same title. They only show different titles when they are executed on the client's browser because the react-helmet library gets the chance to be executed, thereby updating the head tags. This article contains more information. How Gatsby solves React SEO problems with SSR Gatsby is a Static Site Generator (SSG) which uses Server Side Rendering (SSR) to generate static pages during the build process. What this means is that you provide dynamic meta information in every page, and during the process of static site generation, pages are server-side rendered with the specified meta information, thereby making static pages with their own details. With this technique, every page contains its own meta title, meta description and basically every meta information. The following tutorial shows how Gatsby improves SEO in web applications. Building an SEO powered site with Gatsby We'll be building a basic website with two pages: / - Home and /about - About Us. These two pages would have their own meta information attached to them during the build process. To get started, let's created our Gatsby project. Run the following in your terminal: ` This pulls the default template, and installs all necessary dependencies. In the src directory, you'll find three directories: components, images and pages. As you may observe, the template already comes with some configurations for seo and optimizing images. To build our project afresh, delete the following files/directories: ` This will leave us with components/seo.js and images. In a future series, we'll explore the gatsby-image plugin used in components/images.js. But for now, understand that it performs optimizations on images. Let's briefly explore the content of components/seo.js ` _Note that_ this component can look a bit different in another template, or you may do it differently. The SEO component receives four props: title, description, lang and meta with title as required. You can specify more props if you want or take out those you don't need. This allows different pages to specify their titles, descriptions and other meta information specific to them. Helmet is from react-helmet but is used a bit different from how it is used in CRA. It works with gatsby-plugin-react-helmet which provides server rendering support. components/seo.js also contains some GraphQL which we will cover in a future series. The Helmet plugin during the build process populates all pages with their respective meta information depending on the inputs provided during development. Now let's add our pages. With Gatsby, you do not need any routing packages for determining components to show based on specific URLs. To create a page, all you need to do is add the component's file directly under the pages directory. To create the two pages for our project, add two files: index.js for / and about.js for /about. Before proceeding with our pages, let's add a layout. Create components/layout.js and components/header.js. Add the following in components/header.js: ` Same React. The only thing new here is a different Link component from Gatsby is used. In the components/layout.js, add the following: ` For the pages, add the following to index.js: ` I added an unsplash image to images and required it require('../images/laptop.jpg') as seen above. We'll look at the usage of the SEO component soon. For pages/about.js, add the following: ` Create a new directory called styles under src and create a new file: global.css. Copy the following css styles to that file: ` For the global stylesheet to be used for the whole site, the gatsby-browser.js API file would be used. gatsby-browser.js is a reserved API file that gives access to actions within the browser. In gatsby-browser.js (at the root of your project), add the following: ` When you run the gatsby server for your project (gatsby develop), you'll get the following on localhost:8000: For /: For /about: The SEO component makes all the pages unique and SEO-ready. For index.js, we have: ` Just as we have configured the SEO component using react-helmet, this updates the meta information for the homepage during the build process. This way, the first thing crawlers will see is the unique meta details for the page, as they do not require any JavaScript to be updated. To test this, do the following: - build for project for production (gatsby run build) - serve the production build (gatsby run serve) This will run the built content on localhost:9000. You can use curl on your terminal to inspect the source code (or run inspect on the browser). ` The result: The reason it came out as "Homepage | Gatsby Default Starter" is because of the prop titleTemplate provided by Helmet which was configured like so in the SEO template: ` This appends a default title to every title provided by the pages. Conclusion In this article, we looked at how Gatsby solves the problem of SEO using server side rendering for generating static pages. The basic example used in the tutorial shows how each page contain their own meta information that can easily be crawled by SEO bots or social media tools....

Dec 16, 2020

6 mins

GatsbyReact

Angular Signals for Simpler State Management and DOM Performance

In this episode of the Modern Web Podcast, host Rob Ocel is joined by Adam Rackis, Danny Thompson, and guest Braydon Coyer, Senior Front-End Developer at LogicGate to talk about using Angular Signals for improved state management and DOM performance. Braydon explains how Signals simplify Angular development and offer better readability and efficiency compared to traditional methods like RxJS. The conversation also touches on hiring in the AI era, discussing challenges around take-home tests and live coding, and how AI tools like ChatGPT are changing the interview process. Chapters 00:00 - Introduction 00:57 - The Angular Renaissance 02:24 - Signals in Angular 03:27 - Transitioning to Signals 04:19 - Signals in Utility Development 05:09 - RxJS and Signals 07:52 - Signals vs Other State Management Solutions 09:34 - Testing Signals 10:29 - Control Flow and Standalone Components in Angular 12:02 - Angular's Evolution and Accessibility 13:28 - Angular’s Framework Governance 17:10 - Hiring in the Age of AI 19:15 - Pair Programming and Real-Time Problem Solving 22:24 - The Role of AI in Interviews 27:58 - Wrapping Up Follow Braydon Coyer Twitter: https://x.com/BraydonCoyer Linkedin: https://www.linkedin.com/in/braydon-coyer/ Github: https://github.com/braydoncoyer...

Oct 30, 2024

1 min

Angular

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

Getting Started with GatsbyJS

Introduction

SSR, CSR, and SSG

Client-Side Rendering (CSR)

Server Side Rendering

Static Site Generator

How Gatsby improves SEO

Building a simple website with Gatsby

Install the CLI tool

Create new site

Improving the gatsby-starter-default template

Conclusion

Dillion Megida

You might also like

How to build an AI assistant with OpenAI, Vercel AI SDK, and Ollama with Next.js

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

Building SEO-Powered Websites With Gatsby

Angular Signals for Simpler State Management and DOM Performance

Let's innovate together!

You might also like

How to build an AI assistant with OpenAI, Vercel AI SDK, and Ollama with Next.js

The HTML Dialog Element: Enhancing Accessibility and Ease of Use

Building SEO-Powered Websites With Gatsby

Angular Signals for Simpler State Management and DOM Performance