Javascript

What's new in Next.js 12

Published Dec 7, 2021

Updated Feb 13, 2023

5 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.

NextJS 12 came with a number of new features. Some are quiet and largely automatic, but others unlock completely new ways of working. I'll be giving you the highlights of each category, alongside ideas about how to leverage the new features and potential pitfalls.

In order of decreasing stability:

Stable: Performance improvements

In the category of features that have seen stable releases, require very few changes to your existing code, and can give you an immediate improvement we have a raft of performance optimizations for both user and developers:

Faster compiler

Next now includes a Rust-based compiler which it uses by default instead of Babel. This provides spectacular improvements in build times, especially for large projects, but it's worth noting that it does not include any plugin system, so if you are using a custom babel configuration, you will need to wait until the Next team adds support for what you need and keep using Babel until then. This de-optimization will happen automatically if you have a .babelrc file. At time of writing, for example,styled-components is now supported experimentally, but other systems like emotion or vanilla-extract aren't at all.

NextJS moving away from the Babel ecosystem, and towards a custom compiler, will likely mean decreased support for custom configurations going forward as well. In this environment, it seems advisable to stick as much as possible to the approaches officially recommended and supported by the NextJS team, like using CSS modules, SCSS, or styled-jsx for styling as opposed to a third-party CSS-in-JS solution. Trading flexibility for performance is sadly a common theme as software matures, but at least NextJS has a good variety of built-in tools to suit different situations.

Smaller images

NextJS can now generate AVIF images, which are smaller and thus faster to load than even WebP images. This optimization is opt-in, but there's very little downside to adding it to your next.config.js file. In the worst case, you might see slower build times if you have a lot of images.

module.exports = {
  images: {
    formats: ["image/avif", "image/webp"],
  },
};

Beta: Middleware

The most exciting change that you can actually use straight away — we'll get into the experimental React 18 features later — is page middleware. Middleware are functions that you can define, and which always run on the server right before a user enters any page in that folder or any subfolders.

It's a great way to enforce authentication by placing a middleware like this in an /app or /members folder where all registered-only content lives:

export async function middleware(req: NextRequest, res: NextResponse) {
  try {
    // check whether a user has a login token, like a JWT
    const userId = await verifyAndExtractToken(req.cookies[cookieName]);

    if (!userId) throw new Error("No userId encoded in token");

    // If they have a token the "next()" call delegates to the page to render
    return NextResponse.next();
  } catch (err) {
    // If they do not have a token we redirect them to login
    return NextResponse.redirect("/login");
  }
}

Middleware is somewhat limited by the fact it executes in an isolated context separate from the code that renders that page. It can read the request parameters like cookies and headers, and modify the response parameters in the same way but it cannot, for example, read some data and pass that on to a getServerSideProps function. Any augmentation of getServerSideProps will still require calling a function in the page file itself, although I hope in the future middleware gets some way of communicating with SSR, even if it is only through limited serializable values. It would be useful to be able to have getServerSideProps read the user id decoded from the token in the above example.

Still, a lot of common operations you need a server for are covered by reading and writing cookies and issuing redirects. A/B testing, page view and render time metrics, filtering out bots... the NextJS team have provided a whole raft of examples you can draw on for ideas.

Experimental: React 18

React 18 isn't even out yet, but NextJS 12 already includes support for it and all of its major features.

npm install react@alpha react-dom@alpha

If you install the React 18 like so, you can start testing out new features like update batching and startTransition, an API that lets you leverage async rendering to avoid blocking user interactions while UI updates render. However, the most transformational features, streaming render, and server components, are gated behind Next config flags:

module.exports = {
  experimental: {
    concurrentFeatures: true,
    serverComponents: true,
  },
};

There are full details of how to use these features, which promise a server-rendering experience that is faster and more seamless, in the NextJS docs. But keep in mind that React 18 is still in alpha, and these APIs might change before release, so it's not a good idea to restructure applications to rely on them yet. Couple that with the fact that many common React libraries you might be using or want to use won't be updated to be compatible with React 18 yet, and it's clear that this is something to just test out for now, and keep an eye on, in the coming months as final APIs and releases begin to appear.

Experimental: URL imports

In the final experimental category, we have an idea that might be familiar to those of us who've used Deno: importing dependencies not by adding them to a package.json, but by including their URL in code. It's better to still structure your code so that a given URL is only imported in one place, so that becomes the canonical version used throughout your app, and which you can update by changing its URL. This usually takes the form of a central dependencies file, or set of files with declarations like the following:

export { default as padLeft } from "https://cdn.jsdelivr.net/npm/pad-left@2.1";

You can enable this feature by listing the host names from which you want to import dependencies in Next config:

module.exports = {
  experimental: {
    urlImports: ["https://cdn.jsdelivr.net"],
  },
};

This approach can have certain advantages over the standard central package.json model:

You don't get errors when you pull code that adds dependencies but don't know to run an install.
You can divide up dependencies as you wish. For example, if different sections of the site are being developed separately they can each have their own dependencies file.
If some parts of the application depend on an old version of a package, you can still use the newer version for new code until you get around to tackling the tech debt.

However, many packages and tools don't yet work well under this model, with the concept of peer dependencies being particularly difficult to translate although CDNs like ESM have some ideas to get them working.

Conclusion

It's good to see NextJS get ahead of the React 18 and continue making performance improvements, but it doesn't look like this update contains anything truly life-changing or paradigm-shifting yet. However, this is a clear sign that React's streaming and async renderer is going to be a reality very soon, so if you are not already familiar with the concepts or your app doesn't quite run in Strict Mode, it's a good time to learn and prepare.

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.

About the author(s)

Jae Anne Bach Hardie
@dulcedejae

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

Tim Neutkens, Co-Author of Next.js on the State of Next

Watch this episode! Tim Neutkens, Co-author and Tech Lead for Next.js, discusses how open source maintainers are simplifying the web, and covers the challenges faced with the current Next.js setup. Tim talks about TurboPack, a solution that optimizes bundling, improves parallelism, caching, and module graph calculations. He also talks about TurboAC, which focuses on addressing performance and compatibility issues, providing seamless transitions for Next.js users. Tim highlights the importance of efficient bundling processes to avoid excessive recompilation and discusses the updates in Next.js versions to enhance caching, rendering behavior, and client-side caching. Tim also discusses some exciting upcoming features in Next.js 15. Tim Neutkens' Socials - Twitter: @timneutkens - GitHub: timneutkens - Bluesky: timneutkens.bsky.social - Website: https://timn.tech/ Links - Vercel on Twitter, LinkedIn, Facebook, Instagram, YouTube, GitHub and Vercel's website - Next.js on Twitter, GitHub, LinkedIn, YouTube, Instagram, Facebook, official Next.js website - Turbopack on Twitter, GitHub, YouTube, LinkedIn, Instagram, Official Turbopack Docs - Webpack on GitHub, Twitter, YouTube, and Official Webpack Website Show Notes - [00:00:02] Podcast episode featuring Tim Neutkens discussing Next.js and the upcoming release of TurboPack. - [00:04:27] JavaScript bundlers evolving to handle growth. - [00:07:58] TurboPack solves Webpack limitations efficiently. - [00:12:12] Bundler compatibility for optimal app performance. - [00:16:50] Client components separated in webpack instance. Turbo pack for better parallelism and stability. Industry moving towards server-side. Feed and rollup still relevant. Collaboration between tools for future. - [00:20:57] Replacing part with roll down, similar to Webpack. Overlapping ecosystem with Avonetic Conference. Limits with unbundling and loading on demand. Cycle of building frameworks and hitting limits. History of using Webpack for client-side code. Two compiler architecture for server and client. Coordination between server and client with Webpack. - [00:25:38] Server action imports, turbo pack improves performance. - [00:30:04] Next.js is popular for websites. - [00:34:18] Chipotle using Next in Vercel, exciting improvements. - [00:38:51] Next.js 15 release candidate with changes. This episode is sponsored by Wix Studio....

Aug 7, 2024

2 mins

VercelNextJS

Building Web Applications using Astro - What makes it special?

You might already have heard that there is a new player in the static site generator space that is generating a lot of excitement and asking some hard questions of the modern Javascript ecosystem. I'm talking about Astro, a framework constructed around two simple but revolutionary concepts: 1. Accepting components from any UI framework 2. Partial hydration I have recently been working on a site built from the ground up using Astro, and even in the early state its in, I've been able to see the amazing possibilities it opens up in web development. So, let me give you a tour of what those two points mean, both conceptually and for the future of Javascript development. Bring your own framework The modern Javascript ecosystem is divided into separate and sometimes very distant camps, based on what UI library you're using. Next for React, Nuxt for Vue, SvelteKit for Svelte, etc. It doesn't have to be this way. All of these UI libraries ultimately use the same Javascript to output and transform the same HTML and CSS. Why should you have to replace your whole toolkit just to use a different brand of paint? Astro uses a set of plugin renderers to support components written in different formats. Currently, they have ones for React, Preact, Vue, and Svelte, as well as supporting their own minimalist templating format in .astro files. However, there's no reason why this couldn't be expanded by the community in the future. Of course, to hydrate components on the client you need to bring the framework's runtime with you, so it's never going to be particularly efficient to mix and match components from different frameworks on the same page. But, if you absolutely have to, it's now an option. What's much more important is the ability to leverage the potential of Astro, no matter which set of tools you're most familiar with. In a future where more parts of the ecosystem plug into different libraries like this, we might even see more iteration in the UI library space without new entrants having to worry about producing an end-to-end build, serve and hydrate story. Just a sip (of client hydration) The framework compatibility is great, but at the end of the day, the only thing it meant for us was that using Astro with React was possibile. It's all well and good that you can use it, but why would you want to? Partial hydration is the answer. You see, most websites you will ever build have some interactivity beyond just clicking hyperlinks. It isn't the 90s anymore, rich app-like behavior is increasingly part of user expectations. This is why frameworks like Vue and React have taken off the way they have. However, most websites you will ever build also have large sections which _don't_ have any interactivity beyond clicking hyperlinks. Maybe you have a blog that is totally static except for a search bar and a comment section. Or a marketing site that includes a carousel and a navigation popover. Or even a very complex interactive app, which is mostly fully interactive, but needs some highly-performant static marketing and e-commerce pages to sell it to customers. This is the "islands of interactivity" model. Most web applications are a mix of static content and interactive widgets. However, in all of our frameworks, even if they pre-generate some HTML at build time or on the server using Server-Side Rendering, if you want to use components, you have to download those components on the client. Even if they're never going to do anything! A set of paragraphs with CSS classes that won't ever change? The client has to download that twice: once in the HTML that will actually be displayed, and then again as a sluggishly-parsed Javascript bundle that will execute during hydration, but have exactly no effect on the result. Astro says "no" to this inefficient use of resources, and gives us a rich set of tools to send to the client only the Javascript that is minimally necessary to enable interactivity. This is called "partial hydration" because only the islands of interactivity, those widgets that you mark as needing to change, get "hydrated" by loading the client-side version of their components. Astro components The way this is all done is with a new syntax for HTML templating that allows you to include components from your framework of choice with annotations that decide whether they should hydrate, as well as Javascript, to execute during build-time. The following is an astro component extracted from a project I am currently working on, and only lightly edited, showing most major features: ` The section between the --- is "frontmatter" (a concept borrowed from Markdown-based site generators), but as opposed to Markdown frontmatter, it is not restricted to just declaring data. Any JavaScript code can be imported or run in frontmatter, and it will be executed whenever the template is rendered during build time. This makes it very convenient and powerful for fetching and processing data. The rest of the file is a JSX template, which hopefully looks fairly familiar. This isn't full React — no reactive state or event handlers — just a way to produce static HTML from a syntax that requires less specialized syntax knowledge than something like Handlebars because you can just use .map for loops and && for conditional rendering. You can include any HTML tag, any component in the framework of your choice, and one or more tags, which will be replaced with the inner HTML — or "children" in React parlance —that the component is rendered with. The code above is for a main layout component, so our will contain the page content. The final special of feature of Astro components is client: directives. You can see an example on the MobileNav component above. Client directives can be placed on any component authored in a framework that has a client runtime (so, currently, Vue, React or Svelte) and when the conditions met by the directive are met, Astro will load the framework runtime and that component's code, and hydrate it to make it interactive. There are a number of directives for different conditions: - client:load hydrates on page load. This mirrors how SPAs are usually loaded. - client:idle hydrates as soon as the main thread is free. This should theoretically get you interactivity as soon as possible at the cost of potentially delaying loading, but I haven't experimented with it. - client:media hydrates when the browser matches a media query. This is great for content that will only be shown to certain devices, like our mobile nav! - client:visible hydrates when the component becomes visible. This is great for content that might be below the fold. You can load the page as fast as possible, and only download Javascript if the user scrolls. - client:only doesn't output anything at build time and instead of hydrating does from-scratch client rendering on load. It's almost always better to use client:load and provide a placeholder, but there can be cases where a component simply cannot be made to run outside a browser. The result of the above is that on desktop we have a fully-functional site with no Javascript at all — Sidebar is a React component, but it just renders a static menu with tags for navigation — and on mobile, we download React and only what is needed to make the MobileNav component work. This allows us to still use Javascript and Javascript UI frameworks, but our users only pay the price in performance for the features that they actually see, without an extra tax just to allow us to have a unified developer experience! I hope you now understand why Astro is exciting, and why we jumped to try it out even though it's still in its early days. If you want to learn more about it, check out their documentation and their extensive repository of examples....

Jan 6, 2022

6 mins

AstroStatic Site Generators

Building a Stripe App: A Step-by-Step Guide to QR Code Generation

Building a Stripe App: A Step-by-Step Guide to QR Code Generation Why Build a Stripe App? I recently participated in an audio space with the Stripe team, and something they said really stuck with me: the Stripe app store is a growing area that isn't overly saturated yet. There's a lot of potential for new apps, and companies can use this opportunity to grow. I work at a company called This Dot Labs, and we've created several Stripe apps and even own one. After looking at the data, I can confirm that the Stripe team was right! Creating a QR Code Generator App For this tutorial, we'll build a QR code app that can take a URL and generate a code for it. This is a good use case to help you understand the ins and outs of Stripe's developer tools. Why QR Codes? QR codes are useful tools that have become common in e-commerce, restaurants, and other industries. While Stripe already has a QR code tool, we'll make our own to familiarize ourselves with their syntax and problem-solving approaches. Project Structure Before we dive into the implementation, let's look at the structure of our Stripe App QR Code project: * .vscode: Contains settings for Visual Studio Code * source/views: Holds the main application views * .gitignore: Specifies files to ignore in version control * stripe-app.json: Defines the Stripe app configuration * ui-extensions.d.ts: TypeScript declaration file for UI extensions * .build: this is where the built Stripe app gets placed. Step-by-Step Implementation 1\. Install Stripe Locally First, you need to install Stripe on your local machine. The documentation provides great instructions for this: * For Mac users: Use Brew to install * For Windows users: Download the package and add it to your environment variables You can find the details here in the stripe docs to install the Stripe CLI https://docs.stripe.com/stripe-cli When using Windows, you must do stripe login from Powershell, NOT from Git bash or any other tool. After the server is up, then you can continue using git bash for everything else. After stripe login, you need to enter stripe apps start. Once you do that, the server is up and running and you can go back to using git bash or any other tool. 2\. Install Dependencies We'll be using an extra package for QR code generation. Install it using npm: ` 3\. Set Up the Main Component Let's look at the home.tsx file, where we'll use Stripe's UI components: ` These components are similar to other UI libraries like Bootstrap or Tailwind CSS. 4\. Create the UI Structure Our app will have: * An input field for the URL * Validation using a regex pattern * Error handling for invalid URLs * QR code generation and display Here is the Home.tsx file that is located in the src/views folder ` * ContextView` is at the top level of the app where we see the Title and the link to the Stripe Docs that we placed in our Context View. * Box is how you use Divs. * Banners can be used to show notification errors or any other item you wish to display. * Textfields are input fields. * Everything else is pretty self-explanatory. 5\. Handle Content Security Policy One problem I personally ran into was when I tried to redirect users, the Stripe policies would block it since I did not express that I knew what it was doing. I had to go into the stripe-app.json file and mention the specific security policies. For this particular exercise, I kept these as null. This is my stripe-app.json file. ` 6\. Configure App Views As you can see here, the stripe-app.json file shows the views for each file I have. The Home.tsx file and the Invoice.tsx are also included This is our way of saying that for each view we have, show the app functionality on that page. Our stripe-app.json file will show it but also, the manifest.js file in our .build folder will also show the same. Any view that doesn't have a file will not show the application's functionality. So, if I were to go to transactions, the app would not show the same logic as the home or invoices page. By following these steps, you'll have a fully functional QR code generator app for Stripe. This is just a simple example, but the potential for Stripe apps is massive, especially for businesses serving e-commerce customers. If you need help or get stuck, don't hesitate to reach out, danny.thompson@thisdot.co. The Stripe team is also very active in answering questions, so leverage them as a resource. Happy coding!...

Dec 18, 2024

4 mins

stripe

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.

What's new in Next.js 12

Stable: Performance improvements

Faster compiler

Smaller images

Beta: Middleware

Experimental: React 18

Experimental: URL imports

Conclusion

Jae Anne Bach Hardie

You might also like

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

Tim Neutkens, Co-Author of Next.js on the State of Next

Building Web Applications using Astro - What makes it special?

Building a Stripe App: A Step-by-Step Guide to QR Code Generation

Let's innovate together!

You might also like

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

Tim Neutkens, Co-Author of Next.js on the State of Next

Building Web Applications using Astro - What makes it special?

Building a Stripe App: A Step-by-Step Guide to QR Code Generation