This might change how we build UI forever
Table of contents
- Unlock the future of app development with our new CLI—install anything, from anywhere, effortlessly.
- The new CLI for Shad CN makes it super easy to add AI-generated components to your codebase, supporting all major React frameworks and even Laravel, while ensuring seamless integration with existing Tailwind configs.
- Effortlessly generate and integrate complex components into your projects with a single command—coding just got a whole lot easier!
- Imagine replacing complex setup docs with a single command that instantly integrates and shows you the changes—game changer for developers!
Unlock the future of app development with our new CLI—install anything, from anywhere, effortlessly.
Introducing the new CLI, Install Anything from Anywhere. This tool allows you to add components, themes, hooks, functions, animations, and generated code to your apps. This marks a major step forward in distributing code that both you and your LLMS can access and use. Let's take a look—oh boy, am I excited to take a look!
If you don't already know, Shad CN is something I've talked about quite a bit and used even more. It's the perfect combination. If you've seen my old video about how to think about UI libraries, Shad CN almost feels like the natural conclusion of all the things I discussed there. It provides useful components without compromising on ownership because, with Shad CN, it's not a library you're installing; it is components that you're adding to your project, and that code lives in the project.
You might already know about all this, but just in case for those who don't, if I hop into Pi Thing, the service I actually just released today, believe it or not, we can hop into components SLUI. All of these are the buttons that were generated for me by Shad CN—the dialogue box, the drop-down menu. I have the source code here, so if I want to change things, maintain things, or update things, it is all code I own, and there is no compromise there.
That's why I like Shad CN so much—not because it's a beautifully designed library, not because it works really well in TypeScript. I love it because it is writing the right code and putting it in your code base without compromising ownership. That doesn't mean it doesn't use packages; it still uses packages for things that make sense. For example, the React dialogue, the React drop-down menu slot, and switch are all provided by Radix, which is a headless UI library. These provide behaviors, not ways things look, and then Shad integrates, gives it styles, adds Tailwind, and all of that to make it look and interoperate with your code base really well.
It's just a set of really well-designed components, but adding them to your code base has been a weird thing because it required that you had all the right dependencies, all the right versions of things, Tailwind already set up and configured, and then you put it in the right place so it could interface with other things. For instance, if the accordion needed to use the caret, which was a different component that they provided, getting all of that to interface together was not easy. This is why Shad CN created the CLI, where you can run the command to add something directly.
Over time, the stuff you could do with Shad CN grew. V0, created by Vercel and Chad, who works at Vercel now, was built to make it easier to generate UIs. When you generate a UI with this, it is actually using a lot of Shad CN components in the process. For example, if I have a gallery of pictures with a drop-down menu on top to select a tag, it will now generate different UIs based on the prompt that I gave it. So now we have this fake UI with profile images in the filter by tag, and I can click and drop down.
But if we look at the code, this is where things get interesting. The code they gave me is importing drop-down menu, drop-down menu trigger, and all these things from @component UI drop-down menu. I could just copy this code and drop it into my code base, but if I don't have all of these components already in my code base, it's not going to work because it's expecting those. So what they added is the ability to run the CLI command npx v0 add
and then the hash for this specific instance. Not only will it create this particular component, but it will also grab the Shad CN components that it depends on, making it as simple and reliable as possible to grab this AI-generated code and drop it into your code base.
The new CLI for Shad CN makes it super easy to add AI-generated components to your codebase, supporting all major React frameworks and even Laravel, while ensuring seamless integration with existing Tailwind configs.
This is why the CLI is so interesting. The first version of Shaden involved copying and pasting the code into your codebase and ensuring the right dependencies were installed. V1 introduced the CLI, and V2, humorously named "V0," brought in AI generation with a special CLI to add specific generated versions. Now, we are on VOR, the Shaden overhaul, which makes it much easier to add anything to your codebase.
The CLI now supports all major React frameworks out of the box, including Next, Remix, Vite, and even Laravel. Yes, if you're using Laravel with Inertia, you can now use the Shad CN CLI to initialize Shad CN's components in your PHP apps. This shows that at least someone in the PHP world cares about user experience—though that's a joke, as they are actually quite good about that, which is why Inertia exists.
When you initialize a new app, the CLI updates your existing Tailwind files instead of overriding them. This is significant because, as someone who spends a lot of time customizing Tailwind configs, having Shaden init override those settings was frustrating. Fixing this is a huge improvement. A component can now ship its own dependencies. For example, the accordion component can define its own Tailwind keyframes. This means if the accordion has its own animations and uses Tailwind for them, it no longer has to ship custom CSS; it can simply add that to the Tailwind config. This is the magic of what they're doing here.
The Shaden template no longer just runs a pnpm install
and adds files to your codebase. It can now introspect and modify specific files based on specific needs. This is exciting because it suggests a future where you could run npx Shad CN add upload thing
, and it will add the upload functionality to your codebase, placing the right files in the right places and adding the correct layers using the CLI. I almost created this CLI myself, having snagged the T3 npm package with the original plan to build something similar to make it easier to add things to your codebase. I might still do it, as I have to use that package for something cool, but seeing them achieve this goal is really impressive.
As Shad mentioned, this means we can now install hooks, utils, themes, animations, routes, and complex blocks with multi-file components, all added right where you need them. This is a huge unlock for code distribution. For example, running npx Shaden login1
grabs it from the registry, creates the necessary components, and the new login page just exists in your codebase. How cool is that? You can run a command, and it creates new routes and experiences in your app based on their syntax for defining it. Additionally, you can install remote components using URLs. If we have a VZ block, something we discussed with VZ, you can add it that way. Someone even dropped an example in chat, which, although empty, could point to a JSON file and parse the correct things from it if formatted correctly, adding it to your codebase.
They also improved the init command, which is significant because it was not reliable before. It's a small thing, but I personally dislike the @/
syntax. I prefer the tilde (~/
) syntax, although there's something else better that exists natively in JS. I have a thing saved about it that someone shared, but it's just a personal preference.
Effortlessly generate and integrate complex components into your projects with a single command—coding just got a whole lot easier!
So, this example, they init a Shaden project, sidebar 01, login 01, so it's adding those as well. You can create a new Next project with this, pick your theme, and now just running the npx Shad init command with a couple of those things you want to add, you just created a new Next project that has the login page and the other route, the dashboard, all just by running that one command. That's really cool. The ability to use this to add something that you quickly generated to your existing project or even to start something new—if I was one of those startups trying to do prompt-based generation of apps, I'd be shaking in my boots right now.
We created a new schema that you can use to ship your own component registry, and since it supports URLs, you can use it to distribute private components. That's actually really cool. If you had a URL that's only accessible on a VPN, you could use this to hit that as a way to, like, if you're spinning up a new project and you need your company's design library, this will let you hit that on a private network and get it directly. That's so cool. There's a whole changelog for us to dig into as well here.
Okay, so components.json will now exist in your project. Apparently, you can use different import aliases by specifying it there. That's really cool. Shall we init one? I'm curious enough. Let's do it—start a new Next project and GUI this double nested whatever. Now we have this. Why did it use bun if I did pnpm? Is it defaulting to bun when you run pnpm? Whatever, small thing. I remember this happening in the past with the create T3 app template, funny enough.
Let's go to the dashboard. Yeah, that just worked. Am I running my project locally? Is that why the CSS is wrong? No, it's not. Okay, seems like there are some issues with the CSS and the coloring here because a lot of that is not following contrast rules. It's possible it's using the dark mode because of my computer. Yeah, this looks like the dark mode is being handled properly. This looks like it's not. They have the separate dark rules here, all applied as variables, by the way, which makes it a lot easier to change these things and have them persist everywhere. Heavy use of CSS variables to make life a lot better.
But the really cool thing is it's giving you the code. It's not like it's generating this code or grabbing it from somewhere else where you never get to touch it. The login form is a file in my codebase that is using all of these components from Shad CN, and I can go in here and change it and use it however I want. That's really cool.
Imagine replacing complex setup docs with a single command that instantly integrates and shows you the changes—game changer for developers!
The ability to use it however I want is really cool, and the exciting future that I see here is the ability to have this be your onboarding flow. Imagine if instead of a login form being this generic thing with no functionality, you could add a Clerk login form, Stack login form, or Lucia login form. This would add the necessary code, logic, package, and endpoints. The thing I'm excited about here is that this isn't just about making Shaden easier to adopt for UI tasks; it's a step forward in how these initialization processes work. The classic docs page, which everyone has had to write at some point detailing all the steps to add something to your project, could be replaced with a single command. You could then just read the diff, which, as silly as it sounds, is one of the things I'm most excited about. You could run the command, see the thing working, and then understand it afterward.
Currently, the order of events is the opposite: I have to go through the upload thing docs, understand what each piece is, add them all to my code base, and then see if it works for me. What if I could run one command, see the thing quickly, determine if it's for me, and then read the diff afterward? Being able to use this to add things to existing code bases in that way is genuinely exciting. For that reason, I am hyped to see what it will look like to just read the diff. Even here, since it initialized a normal Next project first, we can still read the diff. Here we see it adding the CSS because it didn't already have it. We see all the packages that were added with the command we ran because that command needs all the Radx UI stuff for all those different pieces. We can see how it changed the config for our Tailwind config and all the things it added there. We can see these new components, such as the app sidebar component, and all the things importing from Luced, which is a ton but is using all those icons for things like the nav menu and nav pieces from our component library. The sidebar is so easy to dig through and see what actually changed. Now, if I put it up for code review, others can see it too.
Being able to understand a thing not through the docs, not through the getting started guides, but by running a command to try it and then looking at how it affected your code base is something I've advocated for a while. If you want to learn a code base, like how Upload Thing works, the intuition might be to start by reading every line of code. However, if your goal is to deeply understand Upload Thing and contribute to it, you don't get there by starting at the top of the code tab. Instead, you should start with the pull request tab. Here, you'll start to really learn and understand how the codebase works, especially if you look at the closed PRs that merged. You'll see what code is actually changing, how it's changing, and why it changed. You'll get a lot more out of this tab, and that's why I'm excited because this makes it easier to get to that part where you can really understand how these things work.
On the topic of diffs, every once in a while, someone smart like Gear Mar Ro or my CTO gives you a piece of useful info. For example, using git config
to set up undo reset D-soft
now gives you a git undo that works for the most part. Also, using on push Auto setup remote true
is a lifesaver—I wish I had that years ago. Now, theoretically, you can run git diff
and have syntax highlighting when diffing locally. This significantly changes how I do code reviews locally. You can also add line numbers, although it makes copy-pasting break, but since it's a diff, who cares? In my new CLI tools video, I also mention LG, which is similarly dope but doesn't have syntax highlighting. Now that I've seen it, I need to find a way to add syntax highlighting here or even just change the diff VI init. More for me to deal with later, but I hope this is good info for you guys.
The future of installing things is bright. Anything Shaden does is magical. For instance, someone is using VZ and the Shad CLI to create Minecraft, writing as little code as possible because all this supports 3D stuff now too, which is nuts. Here's just a VZero chat that resulted in a Minecraft clone in the browser, written primarily by AI. This kind of advancement can meaningfully improve our workflows, and that's very exciting. Speaking of which, if this stuff interests you, a cursor video is coming soon as well. That's all for now. Until next time, peace nerds.