DEV Community: Aditya Mathur

Introducing Hono OpenAPI: Simplifying API Documentation for HonoJS

Aditya Mathur — Sat, 07 Dec 2024 15:18:47 +0000

First things first: why create another OpenAPI library for Hono when one already exists?

This is a question many have asked. Yes, there is Zod OpenAPI, created by Yusuke. While it’s a great package, it has some significant limitations that led to the creation of a new solution.

The Challenges with `@hono/zod-openapi`

Let’s break down why hono-openapi was built by comparing the two approaches.

1. Syntax and Workflow Differences

Here’s an example using @hono/zod-openapi:

// Using @hono/zod-openapi 
import { OpenAPIHono, createRoute, z } from '@hono/zod-openapi';

const ParamsSchema = z.object({
  id: z
    .string()
    .min(3)
    .openapi({
      param: {
        name: 'id',
        in: 'path',
      },
      example: '1212121',
    }),
});

const route = createRoute({
  method: 'get',
  path: '/users/{id}',
  request: {
    params: ParamsSchema,
  },
});

const app = new OpenAPIHono();

app.openapi(route, (c) => {
  const { id } = c.req.valid('param');
  return c.json({ id, age: 20, name: 'Ultra-man' });
});

// The OpenAPI documentation will be available at /doc
app.doc('/doc', {
  openapi: '3.0.0',
  info: {
    version: '1.0.0',
    title: 'My API',
  },
});

Now compare this to the same application written with hono-openapi:

// Using Hono-OpenAPI
import z from 'zod';
import { Hono } from 'hono';
import { describeRoute } from 'hono-openapi';
import { resolver, validator as zValidator } from 'hono-openapi/zod';

// Extending the Zod schema with OpenAPI properties
import 'zod-openapi/extend';

const paramSchema = z.object({
  id: z.string().min(3).openapi({ example: '1212121' }),
});

const app = new Hono();

app.get(
  '/',
  zValidator('param', paramSchema),
  (c) => {
    const param = c.req.valid('param');
    return c.text(`Hello ${param?.id}!`);
  }
);

app.get(
  '/openapi',
  openAPISpecs(app, {
    documentation: {
      info: {
        title: 'Hono',
        version: '1.0.0',
        description: 'API for greeting users',
      },
      servers: [
        { url: 'http://localhost:3000', description: 'Local server' },
      ],
    },
  })
);

The difference is clear: hono-openapi lets you work directly within the standard HonoJS workflow. This eliminates the steep learning curve and ensures that the syntax aligns with HonoJS documentation and conventions.

2. Challenges with Opting In

With @hono/zod-openapi, retrofitting an existing HonoJS application to generate OpenAPI specs is a significant challenge. Rewriting routes for a large application can be time-consuming and error-prone. hono-openapi solves this by working as middleware, so you can add it to existing apps without major changes.

3. Limited Validator Support

The original library only supports Zod. While Zod is excellent, many developers use alternatives like Valibot, ArkType, and TypeBox. hono-openapi is validator-agnostic, offering first-class support for multiple libraries.

Why OpenAPI Specs Matter

Some might wonder, “Why bother with OpenAPI specs at all? My app works fine without them.”

Here’s why generating OpenAPI specs is a game-changer:

API Client Generation: Use the specs to auto-generate clients for various programming languages, saving development time.
Developer Collaboration: Keep your team in sync with up-to-date API documentation, reducing miscommunication and bugs.
Streamlined Debugging: Eliminate guesswork when APIs fail by providing clear, accurate documentation for all endpoints.
Best Practices: Automatically generate documentation that evolves with your codebase, ensuring consistency across branches and versions.

Here is an example of Generate Docs from OpenAPI Specs using Scalar -

And this is how you use Scalar with Hono -

import { apiReference } from '@scalar/hono-api-reference'

app.get(
  "/docs",
  apiReference({
    theme: "saturn",
    spec: {
      url: "/openapi",
    },
  })
);

If you’ve ever worked on a team where frontend and backend developers had to manually sync API details, you’ll know how painful it can be. OpenAPI specs solve this by providing a single source of truth.

Why Choose `hono-openapi`?

To address these challenges and promote best practices, hono-openapi was built with the following goals in mind:

Validator-Agnostic: Use your preferred validation library — Zod, Typebox, ArkType, Valibot, or others.
Seamless Integration: Add it to any HonoJS project as middleware, with minimal changes.
Automatic OpenAPI Generation: Define schemas once and let the library handle the rest.
Type-Safe: Built with TypeScript for reliable and consistent type validation.
Customizable: Tailor the generated OpenAPI specs to meet your project’s requirements.

Ready to Get Started?

If this sounds like the solution you’ve been waiting for, check out the library and join the conversation:

GitHub Repository: hono-openapi
Documentation: GitHub README | Hono Examples

I hope this article convinces you to try hono-openapi and see how it simplifies building and documenting APIs. Your feedback matters! Let’s build a stronger HonoJS community together.

Hono for Express Developers: A Modern Alternative for Edge Computing

Aditya Mathur — Wed, 11 Sep 2024 13:44:47 +0000

Express.js has long been the go-to choice for many developers when it comes to building web servers. With over 30 Million weekly installs, it's clear that Express has cemented itself as an industry standard. But as time has passed, so have the requirements of modern web applications. Developers are now seeking frameworks that are not only simple but also more robust, type-safe, and better suited for edge computing and serverless environments.

Over the years, frameworks like NestJS, Next.js, and Nuxt.js have tried to evolve and improve the developer experience. While these frameworks are powerful, they often come with significant complexity or a heavy setup process, which can feel overwhelming, especially for simpler use cases. Sometimes, developers need something that's just as simple and lightweight as Express but with modern features.

This is where Hono steps in.

Hono offers the simplicity of Express with the added benefits of higher performance, modern web standards, and better support for TypeScript. In this article, We’ll compare their core concepts, highlight differences, and show how Hono can boost your development experience, especially for edge and serverless deployments.

1. Setting Up: Simplicity at Its Core

Setting up a basic server with Express is straightforward, and Hono shares that simplicity. Here’s a quick look at initializing both frameworks:

Express -

const express = require('express');
const app = express();

app.get('/', (req, res) => {
  res.send('Hello from Express!');
});

app.listen(3000, () => {
  console.log('Server is running on http://localhost:3000');
});

Hono -

import { serve } from '@hono/node-server'
import { Hono } from 'hono';
const app = new Hono();

app.get('/', (c) => c.text('Hello from Hono!'));

serve(app);

As you can see, the code structure is similar. The key differences here are -

An extra package @hono/node-server, which is used to serve the Hono app. This package is necessary to run Hono apps in Node.js environments. This is also what makes Hono different from Express, as you can have the same codebase for all the environments.

Hono Supports multiple environments like Node.js, Deno, and even the browser. This makes it a great choice for developers who want to build applications that can run on multiple platforms. You can see the full list of all the supported runtimes on the Hono docs

And also in place of req and res, Hono uses a single context object c which contains all the information about the request and response. This makes it easier to work with the request and response objects. That's why we have c.text instead of res.send.

2. Routing: Chainable and Efficient

Just like Express, Hono also has an excellent routing system. Here’s how you can define routes in both frameworks:

Express -

app.get('/user', (req, res) => {
  res.send('User page');
});

Hono -

app.get('/user', (c) => c.text('User page'));

Other than having a single variable c (context) instead of req and res, the routing system in Hono is similar to Express. You can define routes using app.get, app.post, app.put, app.delete, etc.

Additionally, since Hono is optimized for performance, you can expect faster request handling compared to Express.

3. Middleware: Flexibility Meets Minimalism

Express is well-known for its middleware system, and Hono provides similar functionality. Here’s how you can use middleware in both frameworks:

Express -

app.use((req, res, next) => {
  console.log('Middleware in Express');
  next();
});

Hono -

app.use((c, next) => {
  console.log('Middleware in Hono');
  next();
});

4. Request and Response Handling: Web Standards at the Core

Express uses Node-specific APIs like req and res, which are well-known to most developers:

Express -

app.get('/data', (req, res) => {
  res.json({ message: 'Express response' });
});

Hono, in contrast, builds on top of Web APIs like the Fetch API, making it more future-proof and easier to adapt for edge environments.

Hono -

app.get('/data', (c) => c.json({ message: 'Hono response' }));

This difference might seem minor, but it highlights Hono’s commitment to leveraging modern web standards, which can result in more maintainable and portable code.

5. Error Handling: A Simple, Efficient System

Both frameworks offer straightforward ways to handle errors. In Express, you typically define an error-handling middleware:

Express -

app.use((err, req, res, next) => {
  res.status(500).send('Something went wrong');
});

Hono offers a similar approach, keeping things clean and lightweight:

Hono -

app.onError((err, c) => {
  return c.text('Something went wrong', 500);
});

In Hono, error handling is just as easy but comes with the added benefit of cleaner syntax and better performance.

6. Performance Comparison: The Edge Advantage

Performance is where Hono truly outshines Express. Built with speed and edge deployments in mind, Hono’s lightweight framework outperforms Express in most benchmarks. Here’s why:

Hono uses modern Web APIs and doesn’t rely on Node.js specifics.
Its minimalist design makes it faster, with fewer dependencies to manage.
Hono can easily take advantage of edge computing environments, like Cloudflare's workers and pages or Deno.

In performance-critical applications, this makes Hono a compelling choice.

7. Deployments: Edge and Serverless First

Hono is designed from the ground up for edge and serverless environments. It seamlessly integrates with platforms like Cloudflare Workers, Vercel, and Deno Deploy. While Express is more traditional and often paired with Node.js servers, Hono thrives in modern, distributed environments.

If you’re building applications that need to run closer to the user, Hono APIs can easily run on the edge and will offer significant benefits over Express.

8. Ecosystem and Community: Growing Rapidly

Express boasts one of the largest ecosystems in the Node.js world. With thousands of middleware packages and a huge community, it's a familiar and reliable option. However, Hono’s ecosystem is growing fast. Its middleware collection is expanding, and with its focus on performance and modern web standards, more developers are adopting it for edge-first applications.

While you might miss some Express packages, the Hono community is active and building new tools every day.

You can find more about the Hono community and ecosystem on the Hono website.

9. Learning Curve: Express Devs Will Feel Right at Home

Hono’s API is designed to be intuitive, especially for developers coming from Express. With a similar routing and middleware pattern, the learning curve is minimal. Moreover, Hono builds on top of Web APIs like Fetch, which means that the skills you gain are portable beyond just server-side development, making it easier to work with modern platforms and environments.

Conclusion: Why You Should Try Hono

Hono brings a fresh approach to web development with its performance-first mindset and focus on edge computing. While Express has been a reliable framework for years, the web is changing, and tools like Hono are leading the way for the next generation of applications.

If you're an Express developer looking to explore edge computing and serverless architectures, or want a faster, more modern framework, try Hono. You’ll find that many concepts are familiar, but the performance gains and deployment flexibility will leave you impressed.

Ready to Get Started?

Try building your next project with Hono and experience the difference for yourself. You can find resources and starter templates to help you easily switch from Express.

npm create hono@latest my-app

That's it! You're ready to go. Happy coding with Hono! Do share with me your experience with Hono in the comments below, on Twitter or Github. I'd be glad to hear your thoughts!

Deploying Hono Js App on Vercel

Aditya Mathur — Wed, 17 Apr 2024 06:14:13 +0000

Hono is an ultrafast web framework for the edge and it's amazing. It's simple as express and the DX is mind-blowing. And now you can also serve JSX with it 🤯. Anyone in the industry for long enough knows that a setup like this can be quite tedious to manage and maintain. I might sound biased for Hono, and that's true, I love it ❤️.

While working on a project using Hono, I saw the need for a rate limiter, which was not present in the ecosystem. So I build one, hono-rate-limiter

GitHub - github.com/rhinobase/hono-rate-limiter
NPM - npmjs.com/package/hono-rate-limiter

As with every good project, you need a website that hosts examples to better understand your project. And I did make one, which you can check out here - hono-rate-limiter.vercel.app

Building the application was easy, I built everything in just 3 days (including the library, tests, and the example) but deploying it took me more than 3 days. The main reasons were -

Lack of documentation for deploying on vercel.
Pitfalls for deploying Hono on vercel.
Problem with getting the correct config for my library (i.e. getting the IP address).

Lack of Documentation

Hono does have a template application for Vercel, but in my case, my requirements were different (aren't they always 😅). I was working in a monorepo (using nx) because I wanted to manage my libs, tests, and examples all together in a single place, instead of having different repos.

For this, as there was no guide to do it, I had to set up a JS project and then add Hono and Vercel stuff from scratch in my monorepo. Hono was simple as there was not that much to configure but figuring out Vercel was tedious. Vercel as of right now doesn't have a template to deploy your Hono Js project, so you will need to set up all the things from scratch. Such a thing was the root dir of the project, which I needed to set up as the root of the example folder /apps/sandbox.

In my example, I was having a home page built using Hono's JSX so in place of hosting it on /api, I wanted to host it on /.

So to overcome this, you need some understanding of how Vercel deploys your application when using the vercel.json file.

This was my Vercel config file to host it on / instead of /api.

// vercel.json
{
  "rewrites": [
    {
      "source": "/(.*)",
      "destination": "/api"
    }
  ]
}

Pitfalls

Vercel doesn't have a template to deploy your Hono app, so there are some hops you have to go through.

For example, setting up env variables in your Vercel project NODEJS_HELPERS=0, I came to this from this conversation on Github. I am still not sure, why setting this up makes the difference, if anyone of you reading this does, do let us know in the comments.

My Config Issues

So after all these issues, I was able to deploy my application on Vercel 👍🏼. Everything was working, I double-checked it and finally deployed it. I tweeted about it on X

// Detect dark theme var iframe = document.getElementById('tweet-1771943040891945404-177'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1771943040891945404&theme=dark" }

And then something weird happened, people who were coming on the weren't getting uniquely identified from their IP. I checked and figured that I was not getting their IP. So I branched out and checked the example again, It was working perfectly as intended.

After hours of debugging, it turned out that the headers I was getting on the branch deployment were different from the ones on the production. I corrected the header variable name, and it started working.

After the tweet it took me 4 - 5 hours to release, there was an issue and around 2 hours to resolve it. So I did lose the peak traffic time on the app when everyone wanted to try it out. And the package didn't receive the attention it was capable of.

Conclusion

I learned a lot and it was stressful and fun, especially contributing to something I love working with. If you are interested try out hono-rate-limiter and let me know if you find any bugs or have any feature requests. I will be more than happy to connect with you.

Hopefully, this might help someone, who wants to deploy a Honojs app on Vercel.

If you want to check out my lib from which I got all my learnings, here are the links -

hono-rate-limiter

GitHub - github.com/rhinobase/hono-rate-limiter
NPM - npmjs.com/package/hono-rate-limiter

Do let me know what you think about it and how we can boost the community in the future. Do show us your support by giving us a star and for more content like this in the future.

Things I learned while building projects with NX

Aditya Mathur — Mon, 18 Mar 2024 03:28:25 +0000

Lately, I have fallen in love with these monorepo tools, especially the Nx library ❤️. Initially, I just used vite or next for building applications, but for the past 2 years, I have been using these for my projects, and it's amazing. Now I can't even imagine my projects without them. For building a website or a dashboard, you are good without these tools. But as soon as your scope of work expands beyond that, you should start using these tools.

Many of you might not have heard about the concept of Monorepos, or many of you might know about it but don't understand its benefits and issues of using something like this.

Some of the monorepo tools out there are -

Nx
Lerna currently maintained by Nx team
Turbo Repo by Vercel
Bazel by Google
Buck 2 by Facebook

You can also use workspaces but these are specialized tools to help you with your day-to-day tasks. Right now Nx and Turbo repo are the most popular monorepo tools (according to me).

So first of all, let's talk about why you even need this tooling.

So the majority of you might not need this, you should be more than fine with your create-next-app or vite commands to get a starter template and build on top of it. But when we are talking about applications like ERPs, CRMs, or any application that may have more than one portal and multiple small helper packages, that's when you need a monorepo.

Building large-scale applications is easy but maintaining them and adding new features from time to time, can be quite hectic if you haven't used the correct tools from the start. You need tools for -

Building
Testing
Deploying

And all of this can easily be done with a monorepo tool. And they provide even more functionality out of the box. The list of features includes -

Running Concurrent Builds - Multiple packages or apps can be built concurrently.
Task Dependencies - It creates a dependency graph through which it can identify package interdependencies. Helping it to place the tasks in order so that nothing breaks while still being concurrent.
Caching - Once a package is built, you don't need to build it again if there are no changes. These tools can also store this on the cloud, calling it Remote Caching, resulting in faster CI.

Resulting in a great DX ❤️

When building an app, you tend to build it again and again. Being stuck for like 5 minutes every time you are building it, ah the worst feeling 😵‍💫. Even if you are using rust-based compilers, these builds tend to increase in size as you add more and more features. Nextjs alone can take up to 2 minutes to build a single app. And imagine these things happening in sync.

I guess now you are also starting to understand why these tools are important. And the best part is these features that I just told you about are just the beginning, they provide a ton of more features.

Nx provides out-of-the-box tooling for setting up your Apps and Libraries in React, Nextjs, Vue, Angular, Express, and many more. You can check out the list here - Nx Api

They also have internal tooling to move, rename, lint, build, and test all your packages. You can add custom commands too if you want, but for the majority part, Nx does have all the tooling.

And If you are a good developer you must have already seen it coming that, if the library is doing most of the work it will be harder to extend the behavior when needed. Honestly, I also thought that, and sometimes it does look like that, but every time it was because of a config issue by one of the build tools.

Because Nx is not in the driver's seat, you are. It is just providing you with the utilities to do your day-to-day operations. Cause at the end of the day, it is just a folder manager 😂

There were times when Nx had some problems in their internal tooling but their team is quite fast and efficient in helping you out and resolve these errors.

By now you must be thinking, I am being biased for Nx and not giving attention to Turbo Repo. And yes, it is true. Compared to Nx, Turbo is quite new in the market and they are still working on their tooling. Nx has a more mature base and a thriving community. Then too, I initially started with Turbo Repo only, but because of the lack of tooling and helper functions it was quite hard to navigate. Because of the building helpers in Nx, it is much easier to get started. Because there will be a huge learning curve ahead of you when you are starting to work with either of them. Having things to get you started, can make it much easier.

Even with these tools, there will be quite a lot to learn, about the configs and packages to build a library. I have explained this in more detail in this article, Things I learned while building my JS library

Hope this provides you with some good insight into, why these tools are needed and what benefits you will get from using tools like this. Do give it a shot and let me know what do you think about it. Which one did you like, Nx or Turbo?

Conclusion

I learned a lot. Tools like create-next-app and vite take away all the heavy lifting stuff and give us an abstract layer to work upon, but these are great till you have a single project to build or not many dependencies are there. As things start to grow the need for tools like this increases.

If you want to check out my lib from which I got all my learnings, here are the links -

@rafty/ui

GitHub - github.com/rhinobase/raftyui
Docs - rafty.rhinobase.io

@fibr/react (Under Development)

GitHub - github.com/rhinobase/fibr
Docs - fibr.rhinobase.io

Do let me know what you think about it and how we can boost the community in the future. Do show us your support by giving us a star and for more content like this in the future.

Things I learned while building my JS library

Aditya Mathur — Sun, 10 Mar 2024 06:41:26 +0000

If you call yourself a developer, and you haven't created any library or thought about building one, my friend you haven't scratched the surface of being a developer.

While working on a personal project or in your company, you must have thought about making a library around those functions or components you are building repeatedly. And it makes sense too, according to the DRY (Don't Repeat Yourself) principle. But a lot of effort goes into making something that is useful and others also can use.

And building a library is not just about, bundling some functions or components together which are flexible and dynamic. There is a lot of thought goes into it like

API - Simple and easy-to-use functions, with IntelliSense in the editor
Bundling - Getting everything together into a single package or multiple packages, which can be easily used by you and your team.
Versioning - Tools to release and version your packages
Testing - Checking if there are any breaking changes and the application is working correctly. Maybe you can have a test app, where you deploy the changes to check if everything is working before releasing a new version. Or simply a jest or playwright test to check them in a CI/CD workflow through automation.

And then in the JS world, you also have to figure out things like

tree-shaking
side effects
ESM or CJS
code splitting
bundling dependencies
dev dependencies
peer dependencies
exports
modules
types (.d.ts files)
JS Docs or TS Docs
and many more...

These might look overwhelming to you but knowing these things is crucial for your career and in general as a developer. I will not go in-depth about what these things are in this article, maybe in the future but there are plenty of amazing articles about these on the internet.

However, all of these problems can be resolved with a bundling tool like, Rollup, Vite, and Webpack. Knowing what configuration will be required and how things will be working is the hard part. As that is the main thing, Nextjs uses Webpack, pre-configured to handle all of the bundling of their application, so that you won't have to.

Lately, they are also working on a new bundling tool, Turbopack which is written in Rust and I think they are claiming that it's backward compatible with Webpack but still, it's in alpha, so we will have to see. Vite is also working on Rolldown, a Rust-based version of Rollup. These updates and changes will not make sense to you as long as you are in the ecosystem.

As a JS Developer or any developer, you should know how to an environment without the need for any setup tools. As these tools are great for starting a new project but as soon as you will require something outside of this ecosystem, you are stuck.

Solving leet code questions, or any sort of competitive questions helps you to understand the core coding concepts. But building a library, and iterating over it helps you understand the concepts of your programming language, because different languages may have the same keywords or functions like while loop, for loop, variable declarations, and others. But their inner workings and performance will differ and this is how you become an expert in that language, by knowing these things. So that you can already see where your functions or applications might suffer in speed or performance.

This is true for any programming language, not just JS. The best part is, that you start to get familiar with all the tools and are more comfortable while using them. Making you faster and more efficient in building applications.

Building a production application or library is not easy. And the learning you get while building them on your own is far more than just watching it on Youtube or following a tutorial.

And I also, as an experienced developer have messed up a lot. Sometimes there were config errors and bugs in general, proper testing was not done before deployment, documentation website was not working properly. If the library has integration capabilities then, that might not be working properly, and the list goes on and on.

The thing is mistake happens, and that is what the learning is so that next time it doesn't happen. If you are using tools like nextjs or nuxtjs, then you need to build things like this. Because these tools are built to help developers build applications rather than stuck in setting things up, like Rollup or Webpack configs. Yes, these tools are amazing and do most of the stuff for you but big production applications are not just nextjs or nuxtjs, they comprise a lot of small/medium-sized libraries and applications built on Python (for AI maybe) and just React (Admin Panel). Then the need for a monorepo arises but you might not know what a monorepo is, because you have never come out of these ecosystems.

You can refer to this article, Things I Learned While Building My Component Library, where I have gone into more detail about the tools and libraries that my team and I use to build applications.

Conclusion

I learned a lot. From building better APIs and functions to libraries and publishing them on npm. It took me 6 months to complete all of this. And yes I know this sounds like a lot of time, but I had my fun. Building this gave me insight into what goes into building a library which others can also use and cherish.

I would say that if you haven't ever built a library, you should at least try to. The community is a great help, if you are stuck somewhere, some people can help you or also have fallen into the same problems, on which you can build.

Github, StackOverflow, and other online forms are great places to seek help and guidance related to your problems.

If you want to check out my lib from which I got all my learnings, here are the links -

@rafty/ui

GitHub - github.com/rhinobase/raftyui
Docs - rafty.rhinobase.io

Do let me know what you think about it and how we can boost the community in the future. Do show us your support by giving us a star and for more content like this in the future.

Things I learned while building my Component Library

Aditya Mathur — Sun, 03 Mar 2024 19:43:34 +0000

Component libraries have changed how we build applications. It gives us the essential building blocks to develop an application's UI while hiding all the complicated logic from us to achieve that behavior. And the funny part is, the majority of the developers don't understand what is happening behind the scenes. This is a good thing, as it tells us that the library that you are using is quite good, and flexible to achieve your goals. So overall component libraries are great, they are flexible, customizable, and correctly documented and most of them work out of the box.

But if you are a front-end developer, you must understand and know what is happening behind the scenes. This can make a ton of difference when you are building a component on your own without any help from a component library. Because at the end of the day, the component library can be framework-specific, while this knowledge is transferable.

Let's take an example, to help you understand why you should know about this. Have you ever visited a website,

Where the link is just on the text instead of the whole button
Keyboard navigation doesn't work, inside a menu or something similar
Tabbing and focus are not working properly, for example, in case of an alert dialog, the default focus should be on the less destructive button, like a cancel button.
and many more...

You can easily find these types of problems on old, or even on some new websites.

In 2024, building a website is not just about putting some divs and adding the content. It's about accessibility, user-friendliness, theming, and consistency across the whole application.

A component library takes into account all of these problems and on top of it, provides a thoughtful and easy-to-use API.

Tho these problems might seem like minor issues that can be easily solved, and yes they can be. But it's about the thought process when you are building stuff. Many of us don't think about these issues, but once you start to, things change. You start to notice these things in your interfaces, and other's interfaces and you will find gaps. And this is what marks the difference between a senior and a junior developer or a good and a bad app.

And you will also tend to realize that using native components is far better than making custom ones, like a date picker. Because all the aspects of this component are managed by the browser, or the OS and if you make yours then you will need to handle this on your own. You can use a library, but if it has a bug then you are stuck until it is resolved.

Let's now dive a bit deeper, and let me tell you about the libraries that I used to build my component library.

1. Radix Primitives

You might have heard about it and maybe also used it. These are like the barebone components for React which you can use directly also to build applications. It includes most of the commonly used components like Dialog, Slider, Menu, Popover, etc.

And you might be thinking, If I am already using this why am I even building one in the first place?

So basically, these are primitives, and as the name suggests these are just barebone components that handle the working logic and API. There are no styling and theme options available.

You can make your components from scratch, all you need to do is achieve all the accessibility features and make these components as per the WAI-ARIA design patterns, it should be consistent between all browsers too, and keep it up to date with the web standards.

I don't know about you but I am happy to pass all this work on to a library. 😂

It is not impossible to make all these components from scratch, and you will have to make custom components. Because the radix components set is small, it will manage to help you with most of the interfaces. But for some advanced and more complex ones like resizable windows and command palettes, you might need to find another library or make it yourself.

2. Tailwind

Now for styling, we are going to use TailwindCSS. I think I don't need to tell you why this is the best choice. You can already find plenty of articles, regarding why TailwindCSS is so great and better than runtime CSS.

3. NX

Building and managing multiple and heavy apps can be quite cumbersome. You will require a tool to manage your mono repo so that you can store your docs, storybook, and library code in a single folder. And NX is great for this sort of work. it's blazingly fast in building your app and caching it, which makes consecutive builds fast.

I can not emphasize this more if you are building a large project like building a component library, you should use a tool like nx to manage it. It will make your life so much easier.

You can also use turbo repo, which is another project which tries to achieve the same thing. It's just that NX worked for me and also it was in the market way before Turbo.

4. Rollup

This is so much better than webpacks. It's simple, easy to use and the important this is, it's easy to understand. Because webpacks are verbose, you have to tell it all the things, and a lot of configuration goes into it. When you are building a library these configs can slow you down.

Rollup provides a simple API that is easy to understand. And it does most of the heavy lifting for you. If you are building something complex and want control over it, then you should go for webpacks, but still, 90% of the scenarios rollup should be enough.

You can also use Vite, at the time of building the component library, the support for library mode was not stable. I did ask the team about this at the time, and they told me they were not sure if they were going to work on it. I am also a Vite fanboy like most of the other developers, thanks to its outstanding performance. I do use it for my storybook setup, but for building the library, I use rollup.

5. Storybook

You need to test all your components. You can create a react app to test them or use the tool that the industry uses, Storybook. You can easily create an isolated environment to test your components and test them. It comes with a ton of features to help you with your work.

It can do a lot of testing for you. If you can automate the testing of the components, you can check Cypress or PlayWright. They can even provide you with screenshots of when the error occurred.

6. Docs

Documentation is important! You should most definitely write about your components on how to use them. You just need a simple website or even just use MD files to write about them.

It doesn't need to be perfect but just enough so that others can understand. Add property tables, examples, and other things so that people can start using them.

Conclusion

I learned a lot. From building better components to libraries and publishing them on npm. It took me 6 months to complete all of this. And yes I know this sounds like a lot of time, but I had my fun. Building this gave me insight into what goes into building a library which others can also use and cherish.

The thing I love most about JS is that there are a ton of tools to choose from. These tools which I have listed here are the ones, which worked for me and my team. And there are plenty of more options out there which work for you. So don't be shy and do tell us about some of the alternatives that worked for you.

If you want to check out my component lib, here are the links -

@rafty/ui

GitHub - github.com/rhinobase/raftyui
Docs - rafty.rhinobase.io

Do let me know what you think about it and how we can boost the community in the future. Do show us your support by giving us a star and for more content like this in the future.

Squeezing more performance out of your Nextjs App

Aditya Mathur — Mon, 05 Feb 2024 09:43:44 +0000

Presenting the Page Speed score for a recent project undertaken for a client.

A bit about the website and all the requirements we had while making it -

More than 100 pages (This doesn't include the dynamic pages) 😳
Multiple data endpoints for fetching the content 🫠
Tons of High Res Images (Static and Dynamic) 👀
Live Preview when editing articles and events
and Low Latency (Of course! 😭)

Typical client requirements for websites these days. 🫣

Now some of you might already know that Next JS fits perfectly for making projects like these and does most of the heavy lifting for you. So honestly, these things can be easily achieved using Nextjs features like Draft Mode, Image, ISR, and others. But in this article, we will not be going into details of these.

Being a developer your job is to build and integrate ideas and requirements faster. And build an app that is easy to use for your client and also for you to build upon it. And for this, it's not just the framework that we need to correctly choose but also the tools we use.

List of tools

These are the tools we use daily to improve our DX when building any application.

1. React Hook Forms 🔥

The best package for building forms and managing their states. we have used a couple of the form builders in the past but we always land on this as the final choice for building robust and interactive forms.

With their dev tools, your life is 10x better when debugging your forms.

https://react-hook-form.com

2. Zod 🔮

Validation === zod

It is simple, small, and powerful!

https://zod.dev

3. TailwindCSS 🪄

Believe me, when I say this, don't use css-in-js. Just use Tailwind for building your app, it will be 3x more performant automatically. And the best thing about this is, there is no magic happening under the hood, It is what it is.

https://tailwindcss.com

4. Rafty UI ✨

If you want to build fast, you need a component library and it should support Tailwind. There are a ton of libraries out there but in the end, they lack a ton of features compared to other Non TailwindCSS libraries.

So we created our component library for this, it is open source and has a ton of features out of the box. Go check it out and let us know what you think.

https://rafty.rhinobase.io

5. TanStack Query 🎆

Hands down the best library for helping you manage data fetching and data re-validation. Use it with axios for fetching data, it is an amazing combination.

https://tanstack.com/query/latest

6. React Icons 💖

Need icons for your design, just use react-icons. It does the job. It's more than just a package full of icons. You can use these builtin providers to improve your DX more.

https://react-icons.github.io/react-icons

Conclusion

These are just our opinions on tools that we love using when building an application. You might have a different stack or set of libraries that you use, comment them down below and we can give feedback on them.

Tools to build lightweight React Apps

Aditya Mathur — Sat, 04 Nov 2023 05:44:33 +0000

TLDR;

@rafty/ui - Rafty UI for UI components
zustand - Zustand for managing states
tailwindcss - TailwindCSS for styling your components
dndkit - DNDKit for working with DND stuff
lodash - Lodash for utility functions

React is a great tool for building applications, thanks to its extensive ecosystem and welcoming community. You can create both simple and complex applications easily with React, whether you choose to use frameworks like Next.js and Remix or not. However, these applications can quickly become quite large if you haven’t planned ahead. This is where tools like:

Chakra, MUI for UI,
Redux, React Context for state management,
and many others come into play.

These libraries are undoubtedly valuable and can alleviate many development challenges, but incorporating them into your app can significantly increase its size. You might wonder why this is a problem, so let’s first explore that.

The Problem

We can summarize the problem in 4 key points -

Big bundle size - This means your app requires more bandwidth and time to render on the client, even if you employ code splitting or frameworks to separate the code into pages. Your overall build size remains substantial.
Time to compile - Larger bundles necessitate more time for compilation, and Hot Module Reload (HMR) will also take more time to reflect changes in the app, leading to a less favorable Developer Experience (DX).
Slow Apps - In a production environment, your app will perform slowly when delivering changes to clients. This slowness can also affect your development experience.
Device Support - Since your application demands a significant amount of memory and processing power to render all components, it might not work well on lightweight laptops or older machines.

It’s essential to keep in mind that these issues primarily arise when building large-scale applications involving elements such as graphs, drag-and-drop functionality, data streams, multiple API requests, and other complex processing tasks. For your portfolio website, though, it should work just fine 😁.

These problems can significantly impact the app you’re building, and unfortunately, you can’t entirely solve them, as the issue lies not in your code but in the libraries themselves.

The Solution

The solution is quite simple, migrate to these libs -

@rafty/ui - Rafty UI for UI components
zustand - Zustand for managing states
tailwindcss - TailwindCSS for styling your components
dndkit - DNDKit for working with DND stuff
lodash - Lodash for utility functions

These are my favorite libs to build applications in 2023, and there might be more. If you know any, tell us about it down in the comments.

How React Component Libraries are Changing

Aditya Mathur — Tue, 31 Oct 2023 11:33:54 +0000

Quick Overview of SSR

Lately, you may have heard about the rise of Server-Side Rendering (SSR) components in React, particularly if you are coming from the Next.js ecosystem. This change is reshaping how we use and interact with React Component Libraries.

If you’re transitioning from the Page Router or the core React application, you’re likely accustomed to rendering applications on the client side. This implies that all the calculations, processing, and data fetching occur on the client. However, things are evolving rapidly, primarily due to React Server Components.

While there are numerous articles and videos available for a more in-depth understanding of React Server Components, here’s a brief overview: it allows us to render components on the server, encompassing all calculations, processing, and data fetching on the server side. The client only receives HTML and CSS, which should result in faster page loading speeds and an improved user experience for your customers.

The Problem

However, there’s a catch: if you’re using hooks in a component, that component must be designated as a client component. React hooks cannot be rendered on the server since the API is unavailable there. To address this, you’ll need to annotate these components with the “use client” keyword. Once you’ve marked a parent component with this keyword, all its child components will be rendered as Client Components, even if they aren’t utilizing hooks.

But how is all this affecting the React Component Libs?

Check out this example on Chakra-UI docs -

// app/page.tsx
'use client'
import { Link } from '@chakra-ui/next-js'

export default function Page() {
  return (
    <Link href='/about' color='blue.400' _hover={{ color: 'blue.500' }}>
      About
    </Link>
  )
}

As you can see, even for just a simple link, we must use the “use client” keyword. This is also required in the page.tsx, which implies that all components within this file will be client-rendered, potentially negating the advantages of the Next.js 13 App Router.

One might argue that you could create a separate component for this Link Component to eliminate the need for using the “use client” keyword in the main page file. However, this approach could lead to creating numerous components solely to avoid using the “use client” keyword, which may not be practical in the long run.

This is not a solution, This is a hack!

The crux of the issue lies in the necessity of adding the “use client” keyword to all components. However, the challenge is exacerbated by the bloat that some libraries exhibit due to their architecture and underlying foundations. Notably, libraries like Chakra UI, MUI, and Ant Design handle this challenge with varying degrees of success.

A substantial portion of this bloat can be attributed to the libraries’ use of providers, such as ThemeProvider. Over time, these providers have grown in size and weight. As a result, building large applications with these libraries becomes increasingly complex and resource-intensive, particularly in cases like creating a data-rich dashboard or a substantial form with more than 50 fields, essentially a sizeable component on a single page.

The Solution - Micro Context Components

By simplifying the context of components to their core functionality, we can reduce this overhead and develop lightweight applications. This transformation is made possible by libraries and tools like TailwindCSS, Radix UI, Adobe Aria, and many others.

Instead of relying on a ThemeProvider to handle light and dark modes, we can leverage TailwindCSS. When it comes to creating components, Radix UI allows us to build accessible UI components. Additionally, we can establish micro-contexts on top of them to manage props related to sizing and color schemes.

By adopting these approaches, we can cut our application’s size in half, enhance accessibility, and improve speed, all without any compromises.

There are tons of lib that are built to solve these problems and you can start using them right away -

Rafty UI (Created by Me 😁)
Radix Themes
Daisy UI

and many more.

Conclusion

React is a fantastic framework for building applications due to its extensive ecosystem and the high demand from companies seeking React developers. However, things can quickly get out of hand if not managed properly. These libraries can help prevent you from making common mistakes by offering lightweight components.

Rafty UI effectively addresses this issue by leveraging readily available tools like TailwindCSS and Radix UI, resulting in a very shallow learning curve. In fact, you can get started with it in just a few hours and create impressive applications. I’ve been using it for a while now, and it’s truly remarkable how compact and lightning-fast my applications have become.

Do let me know what you guys think about Rafty UI!

If you have any questions, do let me know and I will be happy to answer.

Disclaimer - As of right now, this is the scene as per best of my knowledge, but with the ever-changing world, these Libs might come up with some amazing solutions but nothing like that seems to be happening soon. Right now things seem to be moving towards the Micro Context based React Component Libs.

Let me know what you all think, in the comments.

DEV Community: Aditya Mathur

Introducing Hono OpenAPI: Simplifying API Documentation for HonoJS

The Challenges with @hono/zod-openapi

1. Syntax and Workflow Differences

2. Challenges with Opting In

3. Limited Validator Support

Why OpenAPI Specs Matter

Why Choose hono-openapi?

Ready to Get Started?

Hono for Express Developers: A Modern Alternative for Edge Computing

1. Setting Up: Simplicity at Its Core

2. Routing: Chainable and Efficient

3. Middleware: Flexibility Meets Minimalism

4. Request and Response Handling: Web Standards at the Core

5. Error Handling: A Simple, Efficient System

6. Performance Comparison: The Edge Advantage

7. Deployments: Edge and Serverless First

8. Ecosystem and Community: Growing Rapidly

9. Learning Curve: Express Devs Will Feel Right at Home

Conclusion: Why You Should Try Hono

Ready to Get Started?

Deploying Hono Js App on Vercel

Lack of Documentation

Pitfalls

My Config Issues

Conclusion

hono-rate-limiter

Things I learned while building projects with NX

Conclusion

@rafty/ui

@fibr/react (Under Development)

Things I learned while building my JS library

Conclusion

@rafty/ui

Things I learned while building my Component Library

1. Radix Primitives

2. Tailwind

3. NX

4. Rollup

5. Storybook

6. Docs

Conclusion

@rafty/ui

Squeezing more performance out of your Nextjs App

List of tools

1. React Hook Forms 🔥

2. Zod 🔮

3. TailwindCSS 🪄

4. Rafty UI ✨

5. TanStack Query 🎆

6. React Icons 💖

Conclusion

Tools to build lightweight React Apps

The Problem

The Solution

How React Component Libraries are Changing

Quick Overview of SSR

The Problem

This is not a solution, This is a hack!

The Solution - Micro Context Components

Conclusion

The Challenges with `@hono/zod-openapi`

Why Choose `hono-openapi`?