VueJS

Getting Started with Tailwind in Vue

Published Jul 19, 2021

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.

Introduction

Tailwind CSS has taken the front end development world by storm. If you haven't heard of it yet, Tailwind describes itself as, "a utility-first CSS framework packed with classes like flex, pt-4, text-center, and rotate-90, that can be composed to build any design, directly in your markup." Rather than using semantic class names (like "button" or "title"), you utilize these smaller utility classes to build your components.

There are many ways to integrate Tailwind within a Vue application. In this article, we'll be talking about a few of the best practices for installing and utilizing Tailwind in a Vue application.

Vue CLI

Installing Tailwind in a Vue CLI app is probably the easiest experience available. There is a CLI plugin that does everything we need, including installing Tailwind, and configuring PostCSS for us. Even better, it works for both Vue 2 and 3!

In your terminal, at the root of your application, run the following command:

vue add tailwind

The CLI will then install the plugin. You will be asked how complete a Tailwind configuration file you want (none, minimal, or full). Choose "minimal" for now - it will create the file, but will not populate it with any custom values. Once the terminal has finished, you're done!

There are a couple considerations to keep in mind when using this approach:

As of this writing, the CLI plugin has not been updated in a few months. It is currently installing Tailwind version 2.0.2 (the current latest is 2.2.4). This is easy enough to adjust manually, but you need to be aware of it to make the change yourself.
The plugin is also providing the PostCSS 7 compatible build. For the most part, this doesn't make a huge difference. The Tailwind docs notes that the compatibility build is identical with the main build, so you won't be missing out on any features. For now, this should be fine, but it could lead to issues down the road if you want to use PostCSS 8 plugins (or if Tailwind decides to stop providing backwards-compatible builds). If you're using Vue 3.0.6 or greater, you should be able to upgrade to the main builds. However, your should make sure to update all your PostCSS plugins to the latest main builds, not just Tailwind.

Vite

The Tailwind Docs include instructions on installing Tailwind with Vite. While it isn't as straightforward as the Vue CLI plugin, it's still pretty simple to get started in Vite.

First, install Tailwind, PostCSS 8, and Autoprefixer in your repository:

npm install -D tailwindcss@latest postcss@latest autoprefixer@latest

Then, run the Tailwind CLI command to create a default configuration file for both Tailwind and PostCSS:

npx tailwindcss init -p

This will create two files:

tailwind.config.js
postcss.config.js

Unless you want to make a change to either Tailwind or PostCSS, you won't have to touch these files. The docs recommend that you configure the purge option, which is used by Tailwind to purge its unused styles. With this change, your tailwind.config.js file should look like this:

// tailwind.config.js
module.exports = {
  mode: 'jit',
  purge: ['./index.html', './src/**/*.{vue,js,ts,jsx,tsx}'],
  darkMode: false, // or 'media' or 'class'
  theme: {
    extend: {},
  },
  variants: {
    extend: {},
  },
  plugins: [],
}

Note that we also added the mode: 'jit' key to the configuration. This enables Tailwind's Just-In-Time mode, which is a more performant experience, and enables a number of other Tailwind features. Read the documentation to learn more, and better understand what you're getting out of this.

Now, let's create a base CSS file to import Tailwind's classes into. The Tailwind docs suggest using ./src/index.css, but I would recommend creating a separate CSS file just for Tailwind. Let's call it tailwind.css. In that file, put the following:

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

This uses PostCSS to import the various classes and utilities that Tailwind uses. Then, we just need to import this file in our main.js file like this:

// ./src/main.js
import { createApp } from 'vue'
import App from './App.vue'
import './index.css'
import './tailwind.css'

createApp(App).mount('#app')

And we're done! Tailwind is now available in your Vite application. Make sure to clear out the index.css file of any styles you do not want. In practice, that file will probably be much smaller than you may be used to, but it's still useful to keep your custom styles separate from Tailwind.

Nuxt

Nuxt has an amazing plugin ecosystem, and there is a Tailwind plugin available for us to use here as well. Unlike with Vue CLI, there's a bit more manual work involved to install a Nuxt plugin, so let's get started!

First, make sure your Nuxt application is at least version 2.15.3. This is the release of Nuxt that supports PostCSS 8. Unlike Vue CLI, this plugin provides the main build of Tailwind, not the compatibility build for PostCSS 7. You can upgrade Nuxt by running npm update nuxt.

Once you have confirmed that your Nuxt app is ready, run the following command in your terminal:

npm install --save-dev @nuxtjs/tailwindcss postcss@latest

This will install Tailwind and its required plugins for you. Then, in your nuxt.config.js, add the plugin to your buildModules:

export default {
  buildModules: ['@nuxtjs/tailwindcss']
}

Finally, run npx tailwindcss init to create the Tailwind configuration file. And that's it! Tailwind is now ready to go in your Nuxt application.

You may notice that there's a lot less work here than in Vite (and a lot fewer files being created than in Vue CLI). With the Nuxt plugin, if you do not have a tailwind.css file where styles are being injected, Nuxt will create it for you (the same is true for the tailwind.config.js file, but typically you'll want that anyway to enable JIT mode, or other custom configurations).

Tailwind Viewer

One benefit of the Nuxt plugin is the Tailwind Viewer. This allows you to previous the styles currently enabled in your Tailwind configuration, and copy/paste the classes into your UI. By itself this is a great feature, but when you start working with custom colors or other features, it can be invaluable to preview them before adding the classes to your template.

Conclusion

We've walked through adding Tailwind to a Vue application in three of the most common tools to build Vue applications. In general, the process is the same:

Install Tailwind, PostCSS, and Autoprefixer
Configure Tailwind and PostCSS
Import a CSS file that includes the Tailwind classes to your application

If you are using a custom setup for your Vue site, you should be able to apply these steps to your own setup in order to get Tailwind up and running. There are also a number of resources available if you run into any problems, including a Discord server and GitHub Discussions, where you can ask for help from other Tailwind users.

A note on utility-first CSS

As I'm writing this, I'm aware that utility-first CSS is not for everyone. If that sounds like you, and you made it this far, one thing about Tailwind that isn't highlighted as much as it should be is how the configuration allows for building a coherent design system. How often do you see multiple configuration files for Sass that are nothing but variables ($primary, $red, etc.)? All of this can be handled within Tailwind's configuration file, with the added benefit of generating classes for text, backgrounds, borders, and more to utilize those colors. Also, Tailwind already comes built-in with a number of great design decisions for padding and margin, flexbox, and more, making the work of building a design system that much easier.

Also, Tailwind provides a special directive, @apply, that lets you utilize Tailwind classes in standard CSS. This means that, rather than using the utility classes Tailwind provides in your template, you can build out custom classes (like .card or .button) while still benefitting from Tailwind's other features. Even better, using a plugin like PostCSS Nested, you can get nested CSS, just like in Sass or other CSS preprocessors.

Conisder the following component:

<template>
  <button class="bg-red-100 px-4 py-3 hover:bg-red-300">
    Tailwind Button
  </button>
</template>

This is a fairly simple button, with a background color, padding on width and height, and a hover attribute. Already, we can see a number of other changes to make (add some drop shadow, transitions, different styles for disabled state, and so on). Using purely Tailwind, that could lead to a large number of classes on the button element.

Let's say you don't like having those large class attributes, but you still want the other benefits of Tailwind. Here's the same example, using @apply to build a custom .button class:

<template>
  <button class="button">
    Class Button
  </button>
</template>

<style lang="postcss">
  .button {
    @apply bg-red-100 px-4 py-3;

    &:hover {
      @apply bg-red-300;
    }
  }
</style>

Nice! Our template is a lot simpler, and the styles are contained in our style block. That said, most Tailwind users will probably want to go without using @apply (Adam Wathan, the creator of Tailwind, has said that he almost never uses @apply). That doesn't make this any less valid, and is a perfect way to balance to strengths of Tailwind with traditional methodologies of writing CSS like BEM. If you're hesitant to try Tailwind because of its large number of classes, give this a try and see how you like it!

And remember, the goal of using Tailwind or any other CSS framework or methodology is to build a stellar experience for your application's users. Don't lose focus of that while deciding whether to adopt Tailwind in your latest Vue application. Try it out, see if it works for you, and decide for yourself whether it fits your project or style of writing CSS.

Until next time!

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)

Lindsay Wardell
Lindsay is a software engineer at This Dot Labs, and a host on the podcast Views on Vue. She loves learning about new languages and tools, and sharing that knowledge with the community.
@lindsaykwardell @lindsaykwardell

How Nuxt Studio is Redefining Developer & User Experience with Baptiste Leproux & Ferdinand Coumau

In this episode of the Modern Web Podcast, Danny Thompson sits down with Ferdinand Como and Baptiste Leproux from Nuxt Labs to uncover the story behind Nuxt Studio, a tool that's transforming how developers and non-technical users interact with Nuxt applications. Ferdinand and Baptiste share how Nuxt Studio bridges the gap between developer customization and user-friendly content management. Built to empower agencies, freelancers, and their clients, Nuxt Studio combines powerful features like live previews, Vue component integration, and schema-driven forms to make managing content seamless. The conversation also explores the broader mission of Nuxt Labs—building sustainable open-source tools that enhance developer experience and meet real-world needs. With insights into the future of Nuxt Studio and its potential to scale for larger organizations, this episode is a must-listen for anyone passionate about innovation in web development. Chapters 1. Introduction and Setting the Stage (00:00:00) 2. The Vision Behind Nuxt Studio (00:03:10) 3. Nuxt Studio’s Core Features (00:08:45) 4. Challenges in Building Nuxt Studio (00:16:20) 5. Target Audience and Use Cases (00:22:35) 6. Sustainability in Open Source (00:29:00) 7. The Future of Nuxt Studio (00:35:10) 8. Nuxt Studio’s Role in the Nuxt Ecosystem (00:42:30) 9. Closing Thoughts and What’s Next (00:48:00) 10. Sponsor Shoutout and Wrap-Up (00:53:20) Follow Baptiste Leproux and Ferdinand Coumau Baptiste Twitter: https://x.com/_larbish Ferdinand Twitter: https://x.com/CoumauFerdinand Baptiste Linkedin: https://www.linkedin.com/in/baptiste-leproux-618842b0/ Ferdinand Linkedin: https://www.linkedin.com/in/ferdinand-coumau-nuxt/ Sponsored by This Dot: thisdot.co...

Nov 20, 2024

2 mins

VueNuxtJS

Understanding Vue.js's <Suspense> and Async Components

In this blog post, we will delve into how and async components work, their benefits, and practical implementation strategies to make your Vue.js applications more efficient and user-friendly. Without further ado, let’s get started! Suspense Let's kick off by explaining what Suspense components are. They are a new component that helps manage how your application handles components that need to await for some async resource to resolve, like fetching data from a server, waiting for images to load, or any other task that might take some time to complete before they can be properly rendered. Imagine you're building a web page that needs to load data from a server, and you have 2 components that fetch the data you need as they will show different things. Typically, you might see a loading spinner or a skeleton while the data is being fetched. Suspense components make it easier to handle these scenarios. Instead of manually managing loading states and error messages for each component that needs to fetch data, Suspense components let you wrap all these components together. Inside this wrapper, you can define: 1. What to show while the data is loading (like a loading spinner). 2. The actual content that should be displayed once the data is successfully fetched. This way, Vue Suspense simplifies the process of handling asynchronous operations (like data fetching) and improves the user (and the developer) experience by providing a more seamless and integrated way to show loading states and handle errors. There are two types of async dependencies that can wait on: - Components with an async setup() hook. This includes components using with top-level await expressions. *Note: These can only be used within a component.* - Async Components. Async components Vue's asynchronous components are like a smart loading system for your web app. Imagine your app as a big puzzle. Normally, you'd put together all the pieces at once, which can take time. But what if some pieces aren't needed right away? Asynchronous components help with this. Here's how they work: - Load Only What's Needed: Just like only picking up puzzle pieces you need right now, asynchronous components let your app load only the parts that are immediately necessary. Other parts can be loaded later, as needed. - Faster Start: Your app starts up faster because it doesn't have to load everything at once. It's like quickly starting with the border of a puzzle and filling in the rest later. - Save Resources: It uses your web resources (like internet data) more wisely, only grabbing what’s essential when it's essential. In short, asynchronous components make your app quicker to start and more efficient, improving the overall experience for your users. Example: ` Combining Async Components and Suspense Let's explore how combining asynchronous components with Vue's Suspense feature can enhance your application. When asynchronous components are used with Vue's Suspense, they form a powerful combination. The key point is that async components are "suspensable" by default. This means they can be easily integrated with Suspense to improve how your app handles loading and rendering components. When used together, you can do the following things: - Centralized Loading and Error Handling: With Suspense, you don't have to handle loading and error states individually for each async component. Instead, you can define a single loading indicator or error message within the Suspense component. This unified approach simplifies your code and ensures consistency across different parts of your app. - Flexible and Clean Code Structure: By combining async components with Suspense, your code becomes more organized and easier to maintain. An asynchronous component has the flexibility to operate independently of Suspense's oversight. By setting suspensible: false in its options, the component takes charge of its own loading behavior. This means that instead of relying on Suspense to manage when it appears, the component itself dictates its loading state and presentation. This option is particularly useful for components that have specific loading logic or visuals they need to maintain, separate from the broader Suspense-driven loading strategy in the application. In practice, this combo allows you to create a user interface that feels responsive and cohesive. Users see a well-timed loading indicator while the necessary components are being fetched, and if something goes wrong, a single, well-crafted error message is displayed. It's like ensuring that the entire puzzle is either revealed in its completed form or not at all rather than showing disjointed parts at different times. How it works When a component inside the boundary is waiting for something asynchronous, shows fallback content. This fallback content can be anything you choose, such as a loading spinner or a message indicating that data is being loaded. Example Usage Let’s use a simple example: In the visual example provided, imagine we have two Vue components: one showcasing a selected Pokémon, Eevee, and a carousel showcasing a variety of other Pokémon. Both components are designed to fetch data asynchronously. Without , while the data is being fetched, we would typically see two separate loading indicators: one for the Eevee Pokemon that is selected and another for the carousel. This can make the page look disjointed and be a less-than-ideal user experience. We could display a single, cohesive loading indicator by wrapping both components inside a boundary. This unified loading state would persist until all the data for both components—the single Pokémon display and the carousel—has been fetched and is ready to be rendered. Here's how you might structure the code for such a scenario: ` Here, is the component that's performing asynchronous operations. While loading, the text 'Loading...' is displayed to the user. Great! But what about when things don't go as planned and an error occurs? Currently, Vue's doesn't directly handle errors within its boundary. However, there's a neat workaround. You can use the onErrorCaptured() hook in the parent component of to catch and manage errors. Here's how it works: ` If we run this code, and let’s say that we had an error selecting our Pokemon, this is how it is going to display to the user: The error message is specifically tied to the component where the issue occurred, ensuring that it's the only part of your application that shows an error notification. Meanwhile, the rest of your components will continue to operate and display as intended, maintaining the overall user experience without widespread disruption. This targeted error handling keeps the application's functionality intact while indicating where the problem lies. Conclusion stands out as a formidable feature in Vue.js, transforming the management of asynchronous operations into a more streamlined and user-centric process. It not only elevates the user experience by ensuring smoother interactions during data loading phases but also enhances code maintainability and application performance. I hope you found this blog post enlightening and that it adds value to your Vue.js projects. As always, happy coding and continue to explore the vast possibilities Vue.js offers to make your applications more efficient and engaging!...

Apr 24, 2024

6 mins

VueWeb PerformanceUXJavaScript

TC39 - How Changes are Made to JavaScript

Introduction The JavaScript ecosystem is constantly changing. As developers, we are very familiar with the ever-shifting landscape of frameworks, libraries, and tooling required to write our applications. In addition, there are other runtimes for Javascript beyond the browser, including Node, Deno, Cloudflare Workers, with more being released all the time. All of this - the tooling, the frameworks, the runtimes, even the language - are based on standards developed by a group of individuals and companies know as TC39. TC39 (Technical Committee 39) is a committee organized by Ecma International, a nonprofit standards organization for information and communication systems. In 1996, Netscape (the original creators of JavaScript) began meeting with Ecma to discuss standardizing the language. The first standard edition of JavaScript (called ECMAScript) was adopted in 1997, with further releases of the standard happening since then. The JavaScript we use today is an implementation of these standards, and each runtime of JavaScript works to implement them for use by developers. This standardization across runtimes was not always a guarantee, however. For a long time, the Node project tended to go its own way, implementing Node-specific APIs and methods of accomplishing development work. Many within Node originally felt that TC39 was forcing their standards on the Node project, despite Node havings its own needs and solutions. There are a number of examples where Node went one way, and the JavaScript standards went the other - Promises and imports are two good examples. However, the Node steering committee today is much more open to adopting standards, any many of its members participate in discussions with TC39 regarding new features and changes to JavaScript. This is in part because developers want the same language and APIs in both the browser and their Node environments, but also, because there are other runtimes to consider when developing JavaScript code. This standardization has brought about a number of changes to the language and the JS ecosystem, as more voices are coming together to work on new solution to existing problems. What does TC39 do? As I mentioned, TC39 is a committee focused on developing and ensuring the JavaScript standard. From their website, "Ecma International's TC39 is a group of JavaScript developers, implementers, academics, and more, collaborating with the community to maintain and evolve the definition of JavaScript." The committee takes proposals from the community, and determines which are going to be worked on to be implemented in the JavaScript standard. A number of major companies are directly involved with TC39, with members representing Microsoft, Google, Apple, Intel, Mozilla, eBay, and more. Some are connected to universities, while others participate as individuals. In addition to voting members, many people participate in discussions regarding the various proposals that have been submitted. While the committee itself only meets every two months, these discussions on the proposals and specifications are taking place publicly, and anyone can participate in the conversation. Proposals are hosted on GitHub, and so discussions are as simple as creating an issue or pull request. A TC39 Discourse page is another way for the JavaScript community to discuss any current proposals or new ideas that haven't been formalized yet. When the committee votes to approve a new standard, this change is then implemented in the runtime authors (such as Google's V8). But how does a new standard get added to JavaScript? The Stages of Proposal There are 5 stages to adding a new standard to JavaScript, starting at Stage 0. Each of these stages has different requirements for completion. There is no time limit on moving a proposal from one stage to the next, and no guarantee that a given proposal will be completed. TC39's website hosts a process document that explains in detail what a given stage means, and how a proposal advances to the next stage. Let's walk through the stages, and look at some of the proposals currently at each stage. Stage 0 The first stage for any proposal is stage 0. This stage is the first step in adding a feature to JavaScript. Anyone can make a proposal. You don't have to be a member of TC39. A detailed document outlines the process for submitting a new proposal into stage 0. The pain purpose of this stage is to start a conversation and begin formalizing the proposal in order for future work to be done with it. The first thing that needs to be done when a proposal is stage 0 is to find a champion. A champion is someone from TC39 who will take the lead on moving a proposal forward. In addition, work will need to go into the documentation for the proposal, such as an outline of the problem that is being addressed and a high-level API design. Once these requirements are met, the committee can vote to move the proposal to Stage 1. An interesting Stage 0 proposal is to add a deprecated global or directive to the language, so that it's easier to alert a developer when a given API has been deprecated. Example: ` Stage 1 The purpose of Stage 1 is to make the case for changing the JavaScript standard, describing the proposed solution, and any potential problems that it could cause or could be impacted by. The main goal of the committee for a Stage 1 proposal is to devote time to examining the problem, and ensuring the proposal resolves it. Typically, browser/runtimes won't make any changes to implement a Stage 1 proposal, because the API could still change pretty drastically. However, polyfills or demos may be created in order to get additional feedback on a given API. These features should not be considered production ready. Once the initial spec has been developed, the committee can vote to move the proposal to Stage 2. The pipeline operator is a great example of a Stage 1 proposal. Its goal is to add a pipeline operator (|>) to JavaScript, in order to pipe function returns or values from one function to the next. There has been some discussion around how it should pass arguments into the second function ` Another Stage 1 proposal is the compartments proposal, which helps resolve a number of issues regarding global scope of a JS file or application. Check it out! Stage 2 When a proposal reaches Stage 2, the committee is focused on writing a precise syntax using formal language. This still doesn't mean that a feature is going to make it to JavaScript, but some experimental implementations will start appearing. This process to create a defined syntax could take from months to a year, with some proposals sitting in Stage 2 for much longer than that. However, when a feature leaves Stage 2, it typically means that the proposal will eventually make it to the final spec. Changes may still happen, but typically only limited changes will happen once a proposal moves out of Stage 2. There are a number of interesting proposals in Stage 2 at the moment, including decorators and iterator helpers. Often, proposals may get stalled in Stage 2. Decorators are a good example of that. According to the TC39 proposals repository, Decorators haven't been presented since September 2020, and were originally discussed back in 2018. Sometimes, the problem being solved has multiple solutions, or there are multiple competing solutions that could be adopted. Other times, the problem turns out to be less urgent or important than previously thought. While it can be frustrating to have a proposal stall out, it's important to remember that any change to JavaScript is permanent - no standardized feature in JavaScript is removed from the spec. Better to move slowly than to end up with half-finished APIs that don't actually solve anything. Stage 3 Stage 3 is the final stage for changes to be made to the specification. Spec compliant implementations will start to roll out, typically behind feature flags, in order to get developers to start using the feature and provide feedback. Changes are still possible, but they are expected to be limited in nature. The new Temporal object is a Stage 3 proposal that's pretty exciting for the JS ecosystem. Temporal will act as an upgrade from the Date object and support additional feature such as time zones. A prototype polyfill can be found on NPM, although keep in mind that it doesn't create a global Temporal object like the finished spec would do. And again, remember that this is still a proposal, and should not be treated as production ready. Another great example of a Stage 3 proposal is Realms, which provides a way to create distinct global environments. Stage 4 When a proposal reaches Stage 4, it is considered complete and ready for implementation by the different runtime vendors. Browsers will start to ship the feature, and other runtimes like Node and Deno will also work to include it in upcoming versions. A features is ready for Stage 4 when it passes all the agreed upon tests, and there has been sufficient testing by developers to ensure that the API is sound. Once a feature is in Stage 4, its spec is not intended to be changed. This is to ensure that the web platform is stable into the future - it's important to not break the web with changes to JavaScript. Two good examples of recent Stage 4 proposals are nullish coalescing and Promise.any. These features have been released into major browsers, and are available to be used today in modern JavaScript applications. Conclusion It's pretty amazing that the JavaScript language is developed in the open like this, for all interested parties to add a voice to the discussion. Not every standard or programming language is developed like this. However, this level of openness can also be difficult, especially if a specific feature gets stalled or a proposed API ends up not being accepted. If you submit your own proposal to TC39, remember that you are trying to solve a specific problem, not simply create a feature in JavaScript. Your proposal may be adjusted or replaced as other voices are added to the discussion. Also, keep in mind that it could take a long time for a proposal to make it into the language, if ever (looking at you, decorators). Also, while I've highlighted mostly good things about this process, it's also possible for a single member to hold back a feature from advancing into the next stage. This can be frustrating, but as noted above, it's important for JavaScript to be developed methodically. Having multiple standards or multiple interpretations of those standards wouldn't benefit anyone, after all. At the end of the day, remember that TC39 is made up of indivduals who are invested in the JavaScript ecosystem, and want to work together with developers to improve the language. They have a lot of context and understanding for how features are implemented that developers may not have. Proposals that don't make it into the language may not make it for valid reasons. Does any of this interest you? Do you want to contribute to the discussion? You can find ways to participate on TC39's website, including links to their Github and Discourse....

Aug 18, 2021

8 mins

JavaScript

Build Facial Recognition and Chatbot AIs using TypeScript with Jack Herrington

In this JS Drop, Danny Thompson is joined by YouTuber Jack Herrington to explore a unique TypeScript and AI project that lets you recognize TV show characters in real time. Just point your camera at a character, and instantly get their details or even chat with them as if they were real! Jack walks through the tech, explaining how client-side face recognition and server-side AI work together to make this possible using the Versal AI library. They discuss prompt engineering, building efficient APIs, and ensuring smooth, interactive AI responses. Jack also shares potential real-world applications, from entertainment to security. Chapters - 0:32 Project Overview – Jack explains the AI-powered character recognition project - 2:17 Setting Up the Project – Overview of how the application is structured and initial setup - 3:04 Client-Side AI – How face detection and character recognition work on the client side - 5:12 Switching to Server Side – Jack demonstrates server-side AI and setting up API endpoints - 8:20 Explaining AI Tooling – How tools and prompts are used to give context to the AI - 10:01 Detailed Prompt Structure – Breaking down the prompt and character context for AI responses - 12:40 Client-Server Interaction – Using the Versal AI library to manage streaming responses - 15:09 Handling Character Data – Training the AI on specific character images and details - 18:15 Practical Use Cases – Discussing potential real-world applications for the face recognition tool - 21:34 Challenges and Lessons Learned – Jack shares obstacles he faced and how he overcame them - 25:45 Building the API – Tips and considerations for creating reliable API endpoints - 28:40 Handling User Inputs – Testing unexpected questions and how the AI responds - 32:00 Using Advanced AI Models – Jack talks about choosing GPT-4 and issues with smaller models - 35:47 Introducing ProNextJS.dev – Jack discusses his new Next.js course, covering advanced topics - 37:20 Closing Thoughts – Danny and Jack wrap up with final thoughts and a link to the GitHub repo Follow Jack Herrington on Social Media Twitter: https://x.com/jherr Linkedin: https://www.linkedin.com/in/jherr/ YouTube: https://www.youtube.com/@jherr Sponsored by This Dot: thisdot.co...

Nov 11, 2024

2 mins

AIArtificial Intelligence

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 Tailwind in Vue

Introduction

Vue CLI

Vite

Nuxt

Tailwind Viewer

Conclusion

A note on utility-first CSS

Lindsay Wardell

You might also like

How Nuxt Studio is Redefining Developer & User Experience with Baptiste Leproux & Ferdinand Coumau

Understanding Vue.js's <Suspense> and Async Components

TC39 - How Changes are Made to JavaScript

Build Facial Recognition and Chatbot AIs using TypeScript with Jack Herrington

Let's innovate together!

You might also like

How Nuxt Studio is Redefining Developer & User Experience with Baptiste Leproux & Ferdinand Coumau

Understanding Vue.js's <Suspense> and Async Components

TC39 - How Changes are Made to JavaScript

Build Facial Recognition and Chatbot AIs using TypeScript with Jack Herrington