![React 19 what's new image](https://rllxjlzphibjetvbhsgr.supabase.co/storage/v1/object/public/articles/react-19-new-improved.jpg)

As a software developer, staying on top of React’s evolution is both a necessity and a joy. React 19 has been officially released, and as always, it brings exciting changes to the framework we rely on for building modern web applications. Here, I’ll dive into some of the key updates and share my perspective on how these enhancements might shape our development workflow.

### A Shift Toward Framework-Driven Development
One of the most significant themes in React 19 is the continued push towards integrating React more deeply with frameworks like Next.js. This isn’t just a nudge, the React team is clearly encouraging developers to adopt frameworks for better performance and scalability out of the box. From my point of view, this shift simplifies many pain points, especially around server-side rendering (SSR) and static site generation (SSG). The new APIs and improved compatibility with frameworks mean less boilerplate and more focus on building features.

### Major Improvements to Server Components
Server Components have officially moved out of the experimental phase. If you’ve been exploring them in React 18, you’ll notice that React 19 refines their usability and provides a more robust ecosystem around them. Server Components allow us to offload rendering logic to the server, reducing client-side JavaScript bloat. With React 19, the performance gains feel more tangible, and the developer experience has been polished.

I’ve already started refactoring parts of my applications to take advantage of this. While there’s a bit of a learning curve the benefits, especially in terms of load times, are well worth it.

### Enhanced Concurrent Features
React’s concurrent rendering capabilities get another boost in version 19. This release builds on the foundations laid in React 18, providing more fine-tuned control over transitions and suspense boundaries. For instance, React now makes it easier to handle complex loading states across nested components. This is a game-changer for improving perceived performance without over-complicating state management.

In my own projects, I’ve found that these updates reduce the need for custom loading indicators or convoluted error-handling logic. It’s a small change with a big impact, especially for applications where user experience is paramount.

### New Hooks and Updates to Existing Ones
React 19 introduces a few new hooks, but what’s most exciting is the update to `useEffect`. The new approach to cleanup and dependency tracking minimizes the potential for bugs related to stale closures. Additionally, `useTransition` and `useDeferredValue` have been enhanced to better support concurrent features. These updates are subtle but impactful. They’ve already made my code more predictable and maintainable.

One new hook, `useServerAction`, caught my attention. It allows us to seamlessly trigger server-side actions from the client, which is especially useful in server-centric architectures. I’m looking forward to exploring its potential in real-world scenarios.

### Improved DevTools
The React DevTools have also received a noteworthy upgrade. Debugging concurrent and server-rendered applications has always been a bit tricky, but the new DevTools make it easier to visualize how and where rendering occurs. Features like timeline enhancements and better support for profiling server components have already streamlined my debugging sessions.

### A Few Words on Backward Compatibility
For those of us maintaining legacy codebases, backward compatibility is always a concern. React 19 continues the tradition of providing a relatively smooth upgrade path. However, some deprecated APIs and patterns (like legacy context) are now fully removed. While this might require some refactoring, the benefits in terms of performance and maintainability are undeniable.

### In a nutshell
React 19 is a milestone release that reflects the framework’s maturity and its role in the modern web development landscape. The shift towards framework-driven development and the continued emphasis on server-centric features are clear signs of where React is headed.

If you’re already familiar with React 18, the upgrade is straightforward and well-documented. For new projects, pairing React 19 with a framework like Next.js feels like the best way to leverage its full potential. As I continue to experiment with the new features, I’m excited about how they’ll shape the applications I build—both in terms of performance and developer experience.

Have you started exploring React 19? What are your favorite updates? I’d love to hear how you’re integrating these changes into your projects.

React 19:  What's New and Improved

![Streetfighter platform with logos at the characters](https://rllxjlzphibjetvbhsgr.supabase.co/storage/v1/object/public/articles/aq-vs-cp-vs-ja.jpg)

As a software developer, I’m always curious about tools that promise to make my life easier. AI-powered coding assistants have been one of those exciting yet slightly skeptical areas for me—cool in theory, but will they actually deliver? Over the past few months, I’ve had the chance to explore **Amazon Q**, **JetBrains AI**, and **GitHub Copilot**, and I’d love to share my experience with these tools.

Each one brings something different to the table, and the right choice really depends on your workflow, the tools you’re already using, and how deep you want the integration to go.

### Amazon Q: The AWS Ecosystem’s Brainy Assistant

When I first tried **Amazon Q**, I’ll admit, I wasn’t sure what to expect. Amazon has a knack for building things that are incredibly powerful but sometimes overwhelming for everyday developers. But Amazon Q surprised me in a good way. It’s a coding assistant that integrates seamlessly with AWS services and various IDEs, including JetBrains IDEs, Visual Studio Code, and Eclipse.

Here’s what stood out to me:
- **AWS-Centric Integration**: If your projects live and breathe in the AWS ecosystem (mine often do), Amazon Q feels like an extension of your AWS workflow. It’s great at understanding AWS-specific setups and suggesting improvements.
- **Natural Language Queries**: The chat interface is incredibly intuitive. Instead of writing convoluted SQL queries, I could just type, “Show me the EC2 instances with the highest CPU usage last month,” and it pulled up exactly what I needed. This felt less like using a tool and more like having a really smart colleague on call.
- **Feature-Rich Plugins**: Amazon Q’s plugins for JetBrains IDEs and Visual Studio Code bring a lot of power directly into your coding environment. It’s not just about autocompletion; it can help you refactor code, generate unit tests, and even document your work.

But here’s the catch: If you’re not fully embedded in the AWS ecosystem, you might not feel the full value of Amazon Q. It really shines when it’s working with AWS data and services.

### JetBrains AI: Purpose-Built for JetBrains Users

I’ve been a long-time JetBrains user, so naturally, I was curious to see how their **AI assistant** stacks up. What I loved about JetBrains AI is how deeply it integrates with their IDEs like IntelliJ IDEA, PyCharm, and WebStorm.

Here’s my take:
- **Seamless Experience**: Because JetBrains AI is built by JetBrains for JetBrains, the integration feels effortless. It’s like the assistant already knows what you’re working on and how you like to work.
- **Context-Aware Suggestions**: I noticed that JetBrains AI was particularly good at understanding the context of my code and making precise recommendations. Whether I was refactoring a messy function or debugging a tricky issue, it felt like having a second brain.
- **Focused Language Support**: For now, JetBrains AI works best with Java, Python, and a few other core languages. If you’re in that wheelhouse, it’s fantastic. If you’re not, it might feel limiting.

The downside? It’s very JetBrains-centric. If you’re hopping between multiple IDEs or working with a variety of tools, it doesn’t have the broad compatibility that Amazon Q or GitHub Copilot offers.

### GitHub Copilot: The Generalist

GitHub Copilot is probably the most well-known AI coding assistant out there, and for good reason. It works with pretty much every IDE I’ve ever used: Visual Studio Code, JetBrains IDEs, Neovim, and more.

Here’s why Copilot is so appealing:
- **Wide Language Support**: No matter what language I’m using—Python, JavaScript, Go, Rust—Copilot just works. This makes it incredibly versatile for someone like me, who’s constantly switching between projects.
- **Fast and Fluid**: Copilot excels at inline code suggestions and completions. If you’re writing boilerplate or working on repetitive tasks, it’s a huge time-saver.
- **Simple Integration**: Setting up Copilot is ridiculously easy. A couple of clicks, and you’re good to go.

However, Copilot sometimes feels like it’s trying to be helpful when it’s not. Its suggestions can be a bit off when working on complex or highly customised codebases. And while it’s great for general use, it doesn’t have the same level of AWS-specific or JetBrains-focused integration as the other two.

### So, Which One Do I Prefer?

Honestly, it depends on the project. If I’m doing something heavily tied to AWS, **Amazon Q** wins hands down. Its ability to understand AWS services and work seamlessly within that ecosystem is unbeatable. When I’m in my JetBrains IDEs working on something like a Python backend or a JS/Web app, **JetBrains AI** feels like the natural choice—it’s like the IDE and assistant are one.

But if I’m working on a side project or jumping between different tools, **GitHub Copilot** is my go-to. Its flexibility and broad language support make it invaluable for those “jack-of-all-trades” moments.

### Final Thoughts

These tools aren’t just gimmicks—they’re genuinely useful assistants that can make a real difference in how we code. Each one has its strengths and weaknesses, and the right choice ultimately depends on your workflow. For me, having access to all three has been a game-changer, and I’m excited to see how they evolve in the coming years.

Have you tried any of these tools? I’d love to hear your experiences—what’s worked for you, and what hasn’t? Let’s compare notes!

Amazon Q vs. JetBrains AI vs. GitHub Copilot


Tailwind CSS has been my go-to for building clean, responsive UIs quickly, so when the announcement for Tailwind CSS 4.0 Alpha dropped, I couldn’t wait to dig in. This isn’t just another incremental update—it feels like a leap forward for the framework. I’ve spent the last few days exploring what’s new, and I want to share my thoughts as a developer who uses Tailwind in pretty much everything I build.

  
  

#### First Impressions: Why the Alpha Release Got Me Excited

  

When I read that Tailwind 4.0 is dropping support for older Node.js versions (12 and 14), my initial thought was: "Finally!" It’s a bold move, but it means they’re leaning into modern tooling, which makes the framework lighter and more future-proof. If you’re still on an older Node version, this update might nudge you to modernise your stack—a win in my book.

  

What stood out most immediately, though, is how polished this alpha release feels. It’s not just a laundry list of new features but a thoughtful evolution of the framework.

  
  

#### CSS Nesting: Finally Built-In

  

This one hit home for me. Like many developers, I’ve been using tools like Sass for years to organise my styles with nesting. Now, it’s baked directly into Tailwind! Seeing this feature in action feels so natural:

  

```css
.card {
	@apply bg-white shadow-md;

	& .card-header {
	@apply text-lg font-bold;
	}

	& .card-body {
	@apply text-gray-700;
	}
} 
```

  

I can already tell this is going to make my Tailwind codebases so much cleaner. Nesting is such an intuitive way to structure styles, and having it native to Tailwind means one less dependency to manage.

  
  

#### Performance Boosts I Can Feel

  

The speed improvements in Tailwind 4.0 aren’t just marketing fluff—you can actually feel the difference. The JIT (Just-in-Time) engine now processes utility classes even faster, which means less time waiting during builds and smaller CSS files. On a few test projects, I noticed significantly shorter build times, which makes iterative design so much smoother.

  

For someone like me who’s often experimenting with designs in real-time, this improvement feels huge. It’s one of those changes you don’t realise you needed until it’s there.

  
  

#### Breaking Changes: A Chance to Rethink

  

I’ll admit, breaking changes can be a bit of a headache. Tailwind 4.0 introduces updates to naming conventions and removes some older utilities. When I saw this, my first reaction was mild panic (we’ve all been there). But after reviewing the [migration guide](https://tailwindcss.com/docs/v4-beta), I realised this is a chance to clean up my codebase.

  

Refactoring can feel daunting, but I’ve found it to be a great way to revisit decisions I made months ago and implement better practices. Plus, the improvements in this release more than justify the effort.

  

#### Why This Feels Different

  

This update feels personal to me because Tailwind has been a tool I’ve relied on to build fast and iterate quickly. Each new feature in Tailwind 4.0—whether it’s CSS nesting, enhanced `@layer` capabilities, or improved performance—feels like a direct response to the kind of problems I encounter day-to-day.

  

It’s clear the team is listening to developers and staying ahead of the curve. Tailwind isn’t just keeping up with trends; it’s helping set them.

  

#### Looking Ahead

While this is still an alpha release, I can already see myself adopting Tailwind 4.0 for future projects as soon as it’s stable. There’s a lot to love here, and I’m excited to see how these features evolve before the final release. If you haven’t tried it yet, I’d recommend giving it a shot—you might find yourself falling in love with Tailwind all over again.

Exploring Tailwind CSS 4.0 Alpha

As a developer who’s been working with Astro for a while, I was excited when the Astro 5.0 Beta dropped. I’ve always admired how Astro prioritizes performance and simplicity, so diving into the latest beta was a no-brainer. After tinkering with it, I have to say: Astro 5.0 is shaping up to be a game-changer. Here’s a breakdown of my experience and what you can expect.


## The Content Layer: A Unified Way to Manage Content
Managing content in Astro has always been pretty straightforward, but the new **Content Layer** takes it to the next level. This update introduces a type-safe, unified API for fetching and using content, regardless of where it comes from.

For example, I tested integrating content from Notion using a loader. With the `notion-astro-loader` package, I could pull data directly into my project without jumping through hoops. It’s seamless, and more importantly, it’s type-safe. No more guessing if your content structure is correct—it just works.

This is a huge win for developers building content-heavy sites or dealing with multiple data sources.

----------

## Server Islands: Dynamic Meets Static

If you’re familiar with Astro’s islands architecture, you know how brilliant it is for optimizing performance. With **Server Islands**, they’ve gone a step further by letting you defer dynamic content rendering until after the initial page load.

Here’s an example: I have a site that includes personalized user recommendations. By wrapping the recommendation component in the `server:defer` directive, I could serve the rest of the page as a static file while fetching user-specific content later.

The result? Lightning-fast initial load times without sacrificing interactivity. It feels like having the best of both worlds—static performance with dynamic flexibility.

## 3. Static and Hybrid Outputs in Harmony

Previously, balancing static and dynamic output in Astro required a bit of tinkering. In 5.0, the process is now unified and, frankly, a lot simpler. The new merged static and hybrid output modes mean you can combine both approaches in a single project with minimal setup.

For example, my default `output: 'static'` configuration handled most of my site perfectly. But I needed a few routes to generate dynamically on the server. With a quick adapter setup and the use of the `prerender` constant for specific pages, it was done.

No extra configuration, no hassle—it just works out of the box.


## 4. The `astro:env` Module: Type-Safe Environment Variables

One of the less flashy but equally valuable additions is the new **`astro:env` module**. It makes managing environment variables type-safe and clear.

I can’t tell you how many times I’ve second-guessed myself when accessing env variables in other frameworks. With `astro:env`, I could define my variables in the Astro config, and they’re immediately available with type safety. It’s a small thing, but it makes a big difference when you’re deep in the weeds of a project.


## Getting Started with Astro 5.0 Beta

Upgrading my project was painless. The Astro team has a CLI tool called `@astrojs/upgrade` that handles the heavy lifting:

```bash
npx @astrojs/upgrade beta

```

Alternatively, you can install it manually:

```bash
npm install astro@beta

```

And if you’re starting fresh, the beta version is just a command away:

```bash
npm create astro@latest -- --ref next

```

Pro tip: Check out the [Upgrade Guide](https://5-0-0-beta.docs.astro.build/). It’s super detailed and walks you through all the changes.

----------

## My Takeaway

Astro 5.0 Beta is a thoughtful evolution of the framework. From the enhanced content management with the Content Layer to the smarter handling of dynamic content with Server Islands, it’s clear that the Astro team listens to their developer community.

If you’re already using Astro, this upgrade is worth exploring. And if you’re new to the framework, now’s the perfect time to dive in. Astro 5.0 is fast, flexible, and makes building modern websites genuinely enjoyable.

Time to build something awesome! 🚀

Exploring Astro 5.0 Beta

As a developer who’s worked with Next.js for years, I’m always excited when a new major release drops. Next.js 15, released recently, brings a lot to the table, focusing on developer experience, performance, and compatibility. After diving into it, I wanted to share my thoughts on the updates and how they might impact the way we build apps.

## The Upgrade Process: Smoother Than Ever

One thing I’ve always appreciated about the Next.js team is their effort to make upgrades as painless as possible. With Next.js 15, they’ve introduced the `@next/codemod` CLI, which automates a lot of the heavy lifting during the transition. I gave it a go, and it felt like having a safety net—cleaning up outdated code, updating dependencies, and flagging areas needing attention. It’s a tool I’d recommend using even if you think you’ve got everything under control.

## A Big Shift to Async APIs

Here’s a major change: APIs like `headers`, `cookies`, and `params` are now asynchronous. This might feel like a pain at first, especially if you’re used to synchronous access, but it’s actually a smart move. By making request-specific APIs async, they’re setting the stage for better rendering and caching. 

In my projects, I’ve started adapting to this, and while the initial tweaks required some refactoring, it’s clear this change is aimed at long-term benefits like faster server responses. Pro tip: use their codemod to make the migration easier.

## Caching: Default Behaviors Are Changing

Caching in Next.js 15 is more nuanced. Fetch requests and `GET` route handlers are no longer cached by default. This caught me off guard initially, but it makes sense—fresh data should always be the priority unless you explicitly opt into caching.

I’ve started experimenting with this in my projects, and while it requires a slight mindset shift, the control it gives you is worth it. You can now set the cache behavior that fits your app’s needs rather than relying on defaults that might not.

## React 19 Is Here

This release aligns Next.js with React 19, bringing in some exciting features like the React Compiler and better hydration error handling. If you’re using the App Router, you’ll get these out of the box. For those of you still on the Pages Router (and I’ve got a few legacy projects in that camp), it’s nice that React 18 compatibility is still there. No pressure to switch, but it’s worth considering for newer projects.

## Turbopack Is Fast (and Stable!)

Turbopack is officially stable in dev mode, and wow, is it fast. I’ve tested it on a few projects, and the local server startup and code updates with Fast Refresh are lightning quick. If you’re used to waiting on builds, this is a game-changer. It makes the whole development experience feel less like work and more like fun.

## Other Cool Stuff

Here are a few smaller (but still awesome) features I’ve been exploring:

- **Static Route Indicator**: A simple but effective addition that shows whether a route is static or dynamic. It’s like having a little helper keeping tabs on your rendering methods.
  
- **`next/form`**: A great update for handling forms with client-side navigation. It’s a small detail, but these are the things that make a big difference to user experience.

- **TypeScript Support in `next.config.ts`**: Finally! Writing configuration in TypeScript feels so much more natural.

## Breaking Changes: Worth It in the Long Run

Yes, there are breaking changes—async APIs, caching defaults—but these aren’t arbitrary. They’re laying the groundwork for more efficient, scalable apps. My advice? Take the time to understand the "why" behind these changes. Once you do, you’ll appreciate the benefits they bring.

## Final Thoughts

Next.js 15 is all about giving developers more control and setting us up for the future. Sure, some updates require a bit of a learning curve, but the payoff is faster apps, better workflows, and fewer headaches down the line. If you haven’t upgraded yet, I’d say dive in—it’s worth it.

Next.js 15 has landed

Vite has been with us for around 3 years. It was created by in Evan You 2021. He's also the creator of Vue, and whilst you might not want to use Vue yourself, Vite can be used with React, Preact, Lit, Svelte or Vanilla JS.

Vite is a bundler, similar to Webpack, Parcel and Rollup. It acutally uses Rollup under the hood. But Vite is faster and has much less bloat that Webpack.

Another one of the advantages of Vite over other dev tools is its use of Hot Module Replacement (HMR) to give that fast feedback loop when you're speeding ahead with your code dev. It speeds up Typescript as it skips type-checking and uses ESBuild to transpile your dev code.

# Vite 5 new features
## Switching away from commonJS to ESM
If you're using libraries like Jest, Tailwind or any other package that has a CommonJS export configurations  then you'll have to update your config files to work with the ESM format. Everything is moving to ESM so this is a good chance to get onboard with the new ESM movement

## Rollup 4
Vite had used Rollup in the background since the start, and Vite 5 is using Rollup 4 which is going to improve performance. That's also going to offer new options to improve your dev server performance profile.

# What it takes to upgrade to Vite 5
- Vite 5 supports Node 18+ which is where we all need to be. 
- config files with module.export need to be converted over to ESM standards. This it going to be a great move as previously CommonJS standards were great, but personally I experienced issue with some conflicts using more specialist packages that would be incompatible with other requests.

# Who's embracing Vite now?
Astro, Nuxt SvelteKit and Solid Start have supported Vite for a while, but recently Remix and RedwoodJS have switched to Vite, and this paves the way for more React based ecosystems to follow this trend.

# What about Vitest?
When I started using Vitest, there was a certain amount of disappointment that I couldn't use Testing Library alongside it. But Vitest is now an option alongside Jest for Vue Testing Library. And I'm enjoying the speed that Vite is helping to process my unit tests. Previously I'd get to a point where I'd have to switch to testing changes only to run a decent feedback loop without my IDE stalling, but with Vitest I can just run it in real-time and pick up any issue as I'm writing new code.

# Is Vite just for Node?
The discussion about which runtime is best is something for another article, but Vite is supported by Node, Deno and Bun. So whatever you choose, it's going to work.

# What's the future for Vite?
At ViteConf, Evan You unveiled Vite's long-term plan to work on Rolldown a Rust-port of Rollup with compatible APIs. The plan is to use Rolldown in Vite Core to take on the tasks of both Rollup and esbuild. This will mean a boost in build performance.  Rust is becoming the go to for tooling with NextJs already using it with their TurboPack bundler.

Vite 5.0 is here

TypeScript 5.0 Beta has been released and is available for download. You'll have to update your dependencies in your
`package.json'.

```js
  "devDependencies" : {
    ...
    "typescript" : "^5.0.0-beta"
    }
```

## `const` Type Parameters

When you're inferring the object type, TypeScript will give you a general type.

```js
type HasNames = { readonly names: string[] };

function getNamesExactly<T extends HasNames>(arg: T): T["names"] {
    return arg.names;
}

// Inferred type: string[]
const names = getNamesExactly({names: ["Alice", "Bob", "Eve"]});
```

but now you can add a `const` modifier to a type parameter declaration to cause `const`-like inference to be the
default.

```js
type HasNames = { names: readonly string[] };
function getNamesExactly<const T extends HasNames>(arg: T): T["names"] {
//                       ^^^^^
    return arg.names;
}

// Inferred type: readonly ["Alice", "Bob", "Eve"]
// Note: Didn't need to write 'as const' here
const names = getNamesExactly({ names: ["Alice", "Bob", "Eve"] });
```

## Decorators

One of the most interesting additions for me is Decorators. These are an upcoming ECMAScript feature that allows the
customisation of classes and members in a reusable way.

```js
export class ProductService {
    public getProducts() {
        return fetch('/api/getProducts');
    };
}
```

If we wanted to trace this in development we could start adding in logger calls or the really dirty `console.log()`
method. But with decorators we can create a decorator to wrap methods with the extra functionality.

```js
function log(originalMethod: any, _context: any) {

    function replacementMethod(this: any, ...args: any[]) {
        console.log("LOG: Entering method.")
        const result = originalMethod.call(this, ...args);
        console.log("LOG: Exiting method.")
        return result;
    }

    return replacementMethod;
}
```

```js
export class ProductService {
    @log
    public getProducts() {
        return fetch('/api/getProducts');
    };
}
```

So when we are now working in our project, we can flag a method with the decorator without added piles of extra code
that you might want to remove later, or just making the code less readable. You can go further with this by extending
the decorator further to match what you are trying to do.

## Enums

Enums have been something that I find quite helpful in TypeScript. In TypeScript 5.0 there are now some improvements to
how enums can be used. Previously you could pass thing in to an enum argument and TypeScript wouldn't raise an error.
Now you will be a warning represented as you pass it in. However, I'd still use `LogLevel.DEBUG` instead of `0`.

```js
enum LogLevel {
    DEBUG,
    ERROR,
    WARNING,
}

const log = (level: LogLevel, message: string) => {
};

// Valid
log(2, "Error message");

log(LogLevel.WARNING, "Warning message");

// Invalid
log(1234, 'Invalid message')
```

## Speed, Memory, and Package Size Optimisations

Taken straight from Microsoft's own blog, here are the improvements for installing and running TypeScript:

| Scenario	               | Time or Size Relative to TS 4.9 |
|-------------------------|---------------------------------|
| material-ui build time  | 90%                             |
| Playwright build time   | 89%                             |
| tsc startup time        | 89%                             |
| tsc build time          | 86%                             |
| Outlook Web build time  | 83%                             |
| VS Code build time      | 81%                             |
| typescript Package Size | 58%                             |

Microsoft are keeping quiet on how they made these improvements, but it's also mentioned that they've moved from
namespaces to modules, probably inline with ESM plans. This would be extra useful with using Microsoft's Monaco package
which had issues related to namespacing vs ESM.

Also, the TypeScript package is about 33% smaller now. This comes with some slim-lining some object types and adding
uniformity.

This is all exciting to see, but it's still in Beta, so maybe roll back that beta dependency and wait on what Microsoft
are going to hand out in the general release!


TypeScript 5.0 Beta is available

Tailwind CSS is a very popular framework, and you might be already using it yourself, but whilst the tailwind site
has instructions for installing it on NextJS, Vue, Nuxt, Vite and 12 other JS frameworks you won't find any instructions
for Astro.

So I went ahead and did a bit of trial and error to get Tailwind working with Astro.

## Installing Tailwind

First thing is to install the Astro helpers and Tailwind CSS package. I use pnpm but you can do this with npm or yarn as
well.

```typescript jsx
pnpm
install
@astrojs/
tailwind
tailwindcss
```

Then, apply this integration to your astro.config.* file using the integrations property:

```typescript jsx
import {defineConfig} from 'astro/config';
import tailwind from '@astrojs/tailwind';

export default defineConfig({
    // ...
    integrations: [tailwind()],
});

```

And it's as easy as that. Maybe Tailwind need to copy/paste this article onto their website? Anyway, now you can get
into your layouts first and get them all styled with Tailwind utilities and then move onto the rest of the pages.

Using Tailwind with AstroJS

There has certainly been a large interest in Astro recently, and with v2.0 now out a lot of devs
have been excited about the performance benefits of Astro over other frameworks like NextJS. So with
that in mind I took to comparing both these frameworks and seeing which one is best.

### What exactly is Astro and NextJS?

Astro 2.0 and NextJS 13 are two popular web development frameworks that have their unique features and performance
capabilities. Both allow Server-Side Rendering (SSR) and Client-Side Rendering (CSR). NextJS is built around React,
Astro is defined by on its own framework but allows you to include components from any JS framework.

### Server-Side Rendering (SSR)

Both Astro 2.0 and NextJS 13 provide server-side rendering out of the box, allowing faster page loads and better search
engine optimization (SEO) capabilities. Astro has a much faster response time when comparing the two deployed to the
same cloud provider on the same app slot setup.

## Client-Side Rendering (CSR) and Static-Site Generation (SSG)

NextJS can now perform CSR by using the `use-client` flag at the top of any component file. Astro can do this by
flagging a component inside a page with `<Component client:load />` but this has to be used every time the component is
referenced in a page, unlike NextJS. Astro can also perform SSG which means the render of static content is done on
build. The disadvantage of this is that if you want to change anything that is static then you will need to rebuild and
deploy the application to do this.

### Build Time

Astro 2.0 has a faster build time than NextJS 13, thanks to its use of pre-built static HTML and CSS - the SSG mentioned
above. This can be particularly useful for large-scale projects with many pages, where build time can be a significant
bottleneck. Astro will only rebuild changes so the first build might take longer than any

### Size

NextJS 13 is larger Astro 2.0, due to its bundled features such as automatic code splitting, prefetching,
and optimized images. However, these features can significantly improve page load times, particularly for larger web
applications.

### Customization

Astro 2.0 offers greater customization options than NextJS 13, with the ability to add and remove features as needed.
This can be particularly useful for developers who want more control over their web application's functionality and
design.

### Community and Ecosystem

NextJS 13 has a larger and more established community than Astro 2.0, with more third-party packages and plugins
available. This is going to change over time. Visual Studio already has an extension to support highlighting for Astro
and JetBrains are working on supporting Astro in there 2023.\*.* versions of WebStorm.

In summary, both Astro 2.0 and NextJS 13 are capable frameworks with their unique strengths and weaknesses. Astro 2.0
provides faster build times and greater customization options, while NextJS 13 offers a more extensive community and
ecosystem and more advanced features. Ultimately, the choice between these two frameworks will depend on the specific
needs and requirements of a particular web development project. But the future looks great for these two to
compete with each other and improve the experience for developer and end-users alike.


NextJS vs Astro - Performance comparison

If you were looking to start writing with React today and visited the React website,
the [Create a new React App](https://reactjs.org/docs/create-a-new-react-app.html) page would give you a few options for
getting started. The React team recommends [NextJS](https://nextjs.org/) for a server side rendered
app, [Gatsby](https://www.gatsbyjs.com/)
for a static site, and Create React App for a client side rendered SPA. But is Create React App really the option that
should be recommended for CSR and new users?

## What is Create React App?

Create React App (CRA) is a templated project for getting started with React. A `react-scripts` package will install a
set of other packages to compliment it. You can be up and running in minutes and writing code. But on the downside
you'll have a large amount of node packages installed that are not needed if you'd set it up manually.

## Why should you use CRA?

CRA is a Client Side Rendering library, which means that everything renders in the browser. This can be great for a
simple Single Page Application but isn't good for SEO, metadata or first load performance. If you want to share content
from your side on social media, use SEO to get customers in or have standalone pages that render fast then NextJS is
a better option.

## What's the issue with CRA?

One of the biggest issues with CRA is that it doesn't work correctly with all other packages. This is obviously
something that can happen with other libraries, but CRA what the whole project relies upon. If you want to get around
this, then you have to eject the app and manage everything yourself. With CRA's `react-scripts` defining a lot of
package requirements with specific versions this means that you can't use the latest versions of libraries and if you're
going to eject the app then you're going to have to manually manage all those packages. It's a massive time drain.

## What's the alternative to CRA?

As mentioned above, CRA is a Client Side Rendering (CSR) based library. If you wanted an alternative CSR then I'd
recommend [Vite](https://vitejs.dev/). Vite is lean CSR which serves with native EcmaScript Modules. It does not involve
bundling with tools like Webpack, so it's fast to start. It supports Hot Module Replacement so as you write your app
you'll see the browser you'll see it update without a full reload, and it'll only update what has changed.

## Is CRA actually dead?

The simple answer to this is no. The team behind CRA is working to catch up to all the other frameworks and libraries
that have progressed at lightening speeds whilst CRA has be gathering dust on the shelf. But if others are offering a
managed solution why don't Facebook leave it to others to offer a starting point? Well I think it is because they want
something simple to offer starters who can then progress onwards, but in reality devs are picking up React with CRA,
building full projects with it and then realising that there were better options to choose and then having to claw back
time to migrate to frameworks like NextJS, Astro or Vite. So may Facebook can add a warning next to CRA whilst it's
still the CRAp option?



Is Create React App dead?

Unless you've been hiding under a rock you'll know that when it comes to creating your next React project CreateReactApp
isn't what you want to be using for your base. NextJS is definitely the front runner of the React Frameworks, and it's
just had a major update in the form of v13.

## Routing
The first thing that stuck out was the change in the folder layout. Everything now runs from the `/app` folder. This is
functionality that is still in **beta** and can be rolled back, but looking at the file tree below we can see that
the `/app` folder has all our pages and styles in whilst the `/pages` folder still has the `/api` folder for all the
endpoint files. I'm thinking that this will move to an `/api` folder in the root alongside `/app` in future.

``` 
├── app
│   ├── globals.css
│   ├── head.tsx
│   ├── layout.tsx
│   ├── page.module.css
│   └── page.tsx
├── pages
│   └── api
│       └── hello.ts
├── next-env.d.ts
├── next.config.js
├── node_modules
├── package.json
├── pnpm-lock.yaml
├── public
│   ├── favicon.ico
│   ├── next.svg
│   ├── thirteen.svg
│   └── vercel.svg
├── README.md
└── tsconfig.json
```

You'll also notice the absence of the `index.tsx` file. Now the `page.tsx` serves as the root file for the folder so
anything calling for the root will be served with `page.tsx`. There is also now the `page.module.css` instead
of `home.module.css` and I guess that's to suit the naming of the file that have changed?

Now when we want to have `/products/` we have to have a folder called products with a `page.tsx` in it. Routes are now
folder based instead of the previous file and folder solution in NextJS 12.

## Turbopack
For quite a long time we've been using Webpack to bundle or code up. Now Webpack creator Tobias Koppers has joined
Vercel (the makers of NextJS) and brought along the successor to Webpack called Turbopack.

Turbopack's main selling point is that it is significantly faster that Webpack. It does this by monitoring the state of
the framework and only running changes. It's also faster due to it being written in Rust.

To switch to Turbopack in NextJS add the `--turbo` flag to your scripts config in `packages.json`
```typescript jsx
  "scripts": {
    "dev": "next dev --turbo",
        "build": "next build",
        "start": "next start",
        "lint": "next lint"
}
```

Future plans are for everything NextJS to be run with Turbopack instead of Webpack. How this new tool will benefit
NextJS users is yet to be felt in its infancy, but the bigger the app the greater the difference according to the team
at Vercel.

## Link upgraded
In NextJS 12 the Link object was a bit odd. With ReactRouter you could easily create a link
using `<Link to="/Products">Products</Link>` but NextJS wanted to you to also include an anchor tag:

```jsx 
import Link from 'next/link';

<Link href="/Products">
    <a>Products</a>
</Link>
```

So now in NextJS we get something more link ReactRouter:

```jsx
<Link href="/about">
    About
</Link>
```

Definitely a welcomed update as it's much simpler to write and inline with what we'd expect.

## Font integration
NextJS now as a new font system that can optimise your font collection including custom fonts.
This is a big help because it reduces your dependancy on external sources to store your font files and therefore
removing those external file requests.

Fonts can be self-hosted with any font type, and NextJS will handle all the scaling of the fonts for you if you choose
to use them on standard elements.

```typescript  jsx
import {Inter} from '@next/font/google';

const inter = Inter();

<html className={inter.className}>
```

Personally I use Tailwind CSS for most of my work unless we have a dedicated UI design team to supply our styles, so
this code above is from the official NextJS docs.

## Loading UI
With the routing changes in NextJS there was also the file convention change which I spoke a little about up above. But
something that NextJS didn't do that you could
do in a CSR app was loading components. Users want to see the UI rendered fast, and the longer they wait the less
interested they will be on staying on your site or returning in future.
NextJS's changes to the file system mean that you can specify a `loading.tsx` file alongside the component you want to
render and NextJS will handle the state rendering. This is useful if
you are loading larger items like images or backend data that takes a little longer than the rest of the page to render.

``` 
├── app
   ├── layout.tsx
   ├── page.tsx
   └── products
     ├── layout.tsx
     ├── loading.tsx
     └── page.tsx
```

Inside the loading.tsx you can use you own custom compnents just like you usually would

```typescript jsx
export default function Loading() {
    return <LoadingComponent/>
}
```

## Client Side Rendering
Previously in NextJS 12 everything was SSR. But with the NextJS 13 we can make a component Client Side Render by
adding `use client` at the top of the file

```typescript jsx
"use client"

export default LinkedItems()
{
    return <div className="linked-items">
        ...
    </div>
}

```

This is a great improvement for any dynamic rendering we want to do in dashboard or other situations where you want a
quick load and then populate other sections of the page post-render.

## No more getServerSideProps
This was something that I found annoying. Every time a server side call was required, the getServerSideProps function had to be used. 
It's still available to use if you want to but now there is a much simpler way to do it, and something that those who write CSR apps will be used to.

```typescript jsx
async function getProducts() {
    const res = await fetch('https://localhost:3000/getProducts');
    const data = await res.json();

    return data?.items as Product[];
}

export default async function Products() {
    const products = await getProducts();

    return <div>
        {products?.map(product => <div>{product.name}</div>)}
        ...
    </div>
}
```
There's so much more to talk about on this, so check out the docs on the NextJS site to read more and get your next project 
started with it: [https://beta.nextjs.org/docs/](https://beta.nextjs.org/docs/)

Welcome to NextJS 13

When the React team released hooks in early 2019, many developers were scratching their heads. The reason behind hooks was hard for some to understand. At that time I was working on a project with a Microsoft backend and a TypeScript/React front-end and we were using Redux to handle all the state management.

Hooks weren't really accepted in the team I was in. We already had most of the project complete and to add a new dimension into it which some didn't really want wasn't going to go down well. Thankfully it wasn't long till I picked up my new project and I was there to start the frontend from scratch.

That's where I could do what I like, but one of the biggest headaches was how the rendering would affect hooks and especially useEffect. Relying on the observed dependancies meant that we would have quite a few issues with multiple calls at times we didn't even want them to happen. But the biggest issue came when another developer made a crucial error with the useEffect hook.

That error was that they were making a call to an endpoint, but when they wrote up the code for it, they followed their IDEs suggestion to remove the dependancies array as it was empty and wasn't being used. This caused the call to happen repeatedly, and they weren't aware it was happening. About 30 minutes later we got a call from the DevOps team to say that there were hundreds of thousands of calls happening. 

	    useEffect(() ->{
		    const data = useProductList(categoryId);
		    setProducts(data);
	    });

We quickly found the issue, and fixed it but it still felt like the way we were using useEffect for our API calls was archaic. That's when we found ReactQuery (now TanStack Query so we'll call it that from now on).

TanStack Query is a library dedicated to state management, server-state management and data fetching. The reason it's now TanStack Query is because not only supports React but also SolidJS, Vue and Svelte. The benefit to using it over useEffect for us was that it not only allowed a really readable code trace, but it also allowed us a really granular way to manage all those requests with the cache options.

So how do we get started with TanStack Query? Well the first thing to do is to get the QueryClientProvider setup. It sits at the top of the app stack and it manages all the calls and the cache for the whole app. 

	    <QueryClientProvider client={queryClient}>
	    	<Component {...pageProps} />
	    </QueryClientProvider>

When you make a query it records it and tracks it's status. When you change something, it can manage the cache and recall any query that has been modified. When a cache times out it will call it again if it's in scope.

To make a basic query is very simple.

    const {data} = useQuery('product-list', getProducts);
 
This will save the data call with the key 'product-list' in the cache and assign it a default timeout. If the call happens again before the cache expires, it'll come straight from the cache, saving you a call to the backend and speeding up your application.

You can specify this in more detail using the options variable, and get more back from the query.

    const {data:products, isLoading, error} = useQuery({
										    queryKey: 'product-list',
										    queryFn: getProducts
									    });
From there you can now have some control over your UI when the fetch is happening. With the isLoading you can show your users that the data is being fetched, and when `isLoading` is false you can show your data or act on errors returned.

TanStack Query is also great for CRUD operations. Using the `mutate` operator you can add a record to your backend.

    const mutation = useMutate({
	    mutationFn: (newProduct) => {
		    return fetch('/api/addProduct/', product);
	    },
	    onSuccess: (data:addedProduct) => {
		    queryClient.setQueryData(['product-', addedProduct.id], addedProduct);
		    navigate(`/product/${addedProduct.id}`};
	    }
    });

Here we add a new product, and the `onSuccess` returns the data we passed. We then add this product to our cache before we navigate to the individual product page. When we get to the product page TanStack populates the data from the cache that we just added and we save a call to the backend.

So reading and writing with TanStack is a very refreshing experience. Everything is managed for you, your app is speedy and you're not going to be trying to explain to your client/boss why there were half a million calls to the API in a short space or time. 

There are also lots of other functionalities in the TanStack library. I'll write more about them in the future but until then you should checkout TanStack and see what it's all about. [https://tanstack.com/query/](https://tanstack.com/query/)
 

Why I put useEffect in the bin

In React, there are times when we need to perform some expensive computations or function calls, especially when rendering complex components. This can lead to performance issues, as the computation has to be re-executed every time the component is re-rendered, even if the input parameters remain the same. To solve this problem, React provides a hook called useMemo.

useMemo is a hook that allows you to memoize the results of an expensive function call, and only recompute the result if the input parameters have changed. The basic syntax for useMemo is as follows:

```jsx
const memoizedValue = useMemo(() => {
// expensive function call or computation
return result;
}, [input1, input2]);
```
The first argument to useMemo is a function that computes the value that needs to be memoized. The second argument is an array of input values that the function depends on. If any of the input values change, the memoized value will be recomputed.
Let's take an example to understand how useMemo works in practice. Consider a component that renders a list of numbers and their squares:

```jsx
function NumberList({ numbers }) {
return (
    <ul>
    {numbers.map((num) => (
        <li key={num}>
            {num} squared is {num * num}
        </li>
    ))}
    </ul>
    );
}
```

This component works fine for small lists, but can become slow for large lists as the computation of squares is done every time the component is rendered. To solve this, we can use useMemo to memoize the computation of squares:

```jsx
function NumberList({ numbers }) {
    const squares = useMemo(() => {
        return numbers.map((num) => num * num);
    }, [numbers]);

    return (
        <ul>
            {numbers.map((num, index) => (
                <li key={num}>
                    {num} squared is {squares[index]}
                </li>
            ))}
        </ul>
    );
}
```

In this example, we use useMemo to memoize the computation of squares. The squares array is only recomputed when the numbers array changes. As a result, the component renders faster and performs better.

In summary, useMemo is a useful hook for optimizing the performance of your React components. It allows you to memoize expensive computations and function calls, and only recompute the result if the input parameters have changed. By using useMemo, you can ensure that your components render quickly and efficiently, even for large or complex data sets.


When to use useMemo

Redux has been something that I've seen on job descriptions for a long time. Some developers tell me it's the only
acceptable option, other tell me it's not an option at all. Is it a Marmite state management tool?

Well we are going to look into what Redux is and what it's advantages and disadvantages are.

## Why Redux?

Redux is a JavaScript library for managing and centralising an application's state. It was
created in 2015 by Dan Abramov and Andrew Clark. Abramov himself worked at Facebook, so when
discovered this library I was tempted to it by the fact it was coming from Facebook employees themselves.

There are alternatives like MobX and Recoil that provide a similar state management. But Redux get a fair amount of
coverage. So when you are looking for examples of how to implement and use Redux, you're going to be able to find a lot
of examples on StackOverflow, Medium and other article sites.

## Redux setup

With Redux, there is quite a bit of code setup required. First is your store. This is where you'll be putting all the
state.

```typescript jsx
//app.tsx
import React from 'react';
import {render} from 'react-dom';
import {Provider} from 'react-redux';
import {createStore} from 'redux';
import rootReducer from './reducers';
import App from './components/App';

const store = createStore(rootReducer);

render(
    <Provider store={store}>
        <App/>
    </Provider>,
    document.getElementById('root')
);
```

In the code example above the store is created and supplied to a `<Provider />` element from `react-redux`
that wraps round the whole `<App />`.

Next you're going to need some middleware to deal with handling store access asynchronously. Redux
suggests `redux-thunk`.
To implement this middleware is going to be a lot of code for something you will rarely change. You're also going to be
refining your `rootReducer` here which handles all the calls to alter the store state.

```typescript jsx
//configureStore.ts
import {applyMiddleware, compose, createStore} from 'redux';
import thunkMiddleware from 'redux-thunk';

import monitorReducersEnhancer from './enhancers/monitorReducers';
import loggerMiddleware from './middleware/logger';
import rootReducer from './reducers';

export default function configureStore(preloadedState) {
    const middlewares = [loggerMiddleware, thunkMiddleware];
    const middlewareEnhancer = applyMiddleware(...middlewares);

    const enhancers = [middlewareEnhancer, monitorReducersEnhancer];
    const composedEnhancers = compose(...enhancers);

    const store = createStore(rootReducer, preloadedState, composedEnhancers);

    return store;
}
```

## Action Creators

To make changes to your state, you're going to need Actions (or Action Creators here). When you
dispatch a request the state management will be looking for your type to work out what you want to do.

```typescript jsx
{
    type: 'ADD_PRODUCT', product
:
    {...
    }
}
{
    type: 'REMOVE_PRODUCT', productId
:
    1
}
```

## Reducers

The Actions will then be inspected by the Reducers. You have one rootReducer for your whole state, where you can then
bring in your specific reducers. You could put it all in one but the code base is getting big enough already to be
confusing.

```typescript jsx
// rootReducer.ts
export const rootReducer: Reducer<IStoreState, Actions> = combineReducers({
    cartState: reduceCartState,
});
```

And then you have your specific reducers. Here it's my standard cart example.

```typescript jsx
// cartReducer.ts
import {Reducer} from "react";

const initialState: CartState = {
    items: []
};

export const reduceCartState: Reducer<CartState, CartActions>
createReducer({}, {
    [ActionTypes.ADD_PRODUCT]: (state, action) => {
        const cart = addProduct(action);
        return {...state, items: cart};
    },
    [ActionTypes.REMOVE_PRODUCT]: (state, action) => {
        const cart = removeItem(action)
        return {...state, items: cart};
    }
})
```

So in this cartReducer it's looking for the two action types and then acting on what is passed through. Functions
defined to take the current state and add or remove a product. Those functions are omitted here but easy to implement.

## Conclusion

The code above it a simple example of setting up a state with a simple add remove. It's a lot of code to get started
with. It's not particularly readable because you're going to be jumping from actions to reducers to state files. If you
try out the devtools that come with Redux it can show you the state, the history of the state, and what actions are
being called, but it is quite a pain when you want to change things, and with TypeScript you'd hope that there would be
some helpful errors to point out your errors, but not with Redux (at the time of writing this).

Other newer libraries like ReactQuery can manage these types of state management with simple calls. Viewing the state is
as easy and Redux using the devtools supplied, and mutating the state is much easier. It also has type safety (like
Redux) and supports Vue, Solid and Svelte.

But on the positives of Redux, it will hold you to doing things the way you've set them up. You're not going to find
yourself with state in the wrong place. You're not going to be fixing bugs for missing data that you end up wasting
hours trying to figure out. If you set up your test library using the full mocked state ,you're also going to find a
good trace of problems when the runner is doing its job.

If a project had Redux on it, I'd be happy to use it. But if a project needed state management I'd recommend an
alternative.


React 19: What's New and Improved